Draco Silverwing
- draco18s
- draco18s
- America/New_York
- Yes
- No
13 issues
Key
Summary
Status
Reporter
Assignee
Created
MC-10004
Low
Added Affects Versions: 1.5.2
Changed Description:
In the latest snapshot, I cannot move items around in the player inventory (including pulling stacks from the creative inventory).
How to reproduce:
Open the inventory
Click an itemstack
--> item not picked up
Added Attachments:
See
MC-12834for the code that causes this to happen and a fix.May be a duplicate, but it has more useful information on resolving this issue than any other report.
Tails, I will check this evening when I get home. If I don't update by Friday night, poke it again (I have a slippery memory, pun intended).
Downloaded the latest sourcecode via Forge and checked.
Line 143 is now the current line, and it still contains the premultiplication by 0.98
Louis: that rapid jumping behavior with trapdoors was fixed around 1.4 I think. I had a parkour type map that used it and had to update it to remove that particular jump.
I noticed this recently while playing with a mod that hasn't released for 1.5.2 (beta access, effectively) and it was hard to notice so I wasn't sure if I was seeing it correctly until sometime later when I was digging upwards (breaking logs, so good contrast between the particles and the breaking animation as well as the particles being comparatively large due to them falling towards the camera). Then I had to check if it was a vanilla problem (vs. Forge vs. the specific mod), then I did the right thing and searched the bug tracker.
Good to see that it's been reported.
If by "so long" you mean since snapshot 13w06a (mid February of this year)...
Fixed fast + devs don't care != must be more complicated.
Confirmed
All transparent blocks do this. Ice will also not show, nor water, nor other similarly transparent blocks.
Duplicate of
MC-73and several others.Duplicate of
MC-17414.Duplicate of
MC-17414.Duplicate of
MC-17414.John: That was already added like 4 hours ago.
12:40PM
Change By: zombie hunter
Affects Version/s: Snapshot 13w36a
Funny, I did search. All the issues I found were marked as "resolved" since 1.4.4
1) If vanilla wants the dimension ID to be a byte, then they can make it a byte, they chose not to, but they're downcasting anyway.
2) If vanilla wants to support mods (that whole API thing, yeah?) then they are going to have this problem eventually.
3) Just because it can't come up with the content vanilla supplies doesn't mean it's not a bug.
Apparently magic. It renders out what looks like noise, but this does not occur in dim255. Which leads me to believe that (not-empty) maps are treated specially in the nether. Which would not surprise me in the slightest.
(I did not attempt to locate the code that handles this, just verified that -1 != 255)
It's not a mod's bug. It's a bug in the vanilla item that makes the mod incompatible with Vanilla. Fixing it would require edits to Vanilla's ItemEmptyMap class, which is not the mod's responsibility.
Unknown if it still effects 1.7.2 as Forge hasn't updated for it, so I can't tell how slipperiness values are used.
Hey Talven. I got the notification that this was closed, I am not the reporter so I wasn't following this closely, but as it was closed I thought I'd take a look and see if it was still a valid bug on 1.7.2.
Turns out it is still a problem. But I do not appear to have the permissions to change the effected versions, nor reopen the bug.
Can I just quote myself?
I don't know. The deobfuscation process with Forge is no where near complete enough to check. Hell, Forge is still working with 1.7.2!
There is, but it's heavily obfuscated still. There are some material names that haven't even been renamed yet. Not to mention several common-use functions like world.setBlock().
I'm trying the latest Forge now, but the Gradle process is a little arcane. May be able to view enough, but not compile. At the moment it's unclear, just that Gradle had a problem attempting a recompile.
Edit: wasn't able to even get things to a point where the example mod wasn't throwing errors left and right. Something didn't setup properly.
As a side note, the link for the full crash report leads to blank page.
I'm not sure how to report that.
Still effects 14w08a, yes.
I can't update effected versions myself, however.
"Open" and "Closed: Won't Fix" aren't the same thing.
Gosh, if only I had deobfuscated source code for 14w11b to check.
Best I could get you is 1.7.2, and I haven't done any modding since 1.6.4
Would be nice if you'd add the full image, rather than the thumbnail.
What part of "please add the full size image" did you not understand?
Adding the thumbnail is pointless if people can't see what it's trying to show. The snow image you added is basically black with something highlighted in red. But I have no idea what without figuring out which other report the image came from, which after two days, will be really difficult.
Much better.
They are NOT caused by the same basic issue. This one is caused by the incorrect order of operations (floor, then -1, rather than -1, then ceil). That issue is caused by the use of a single point check rather than checking all four corners of the player's hitbox.
Still present in 1.10.2
So far I've only seen them spawn inside the world border, but I will keep an eye on it.
Villagers still attempt to path outside the border, though.
Oh, it totally makes sense that water can't flow into those blocks, but in the depicted situation the water SHOULD flow away through the opening. Placing a fully solid block instead of a fence causes that behavior, and if "water-capable" blocks can't be flowed into and treated as solid...
Sure, I edited that into the description. It's pretty simple. You want video, too?
Tryashtar: note that you need a place where water wants to "naturally flow downhill," ie, an air block no more than 5 blocks away and 1 down:
Torches being the stand-in for Fences/slabs/etc and the Lapis being where the water is.
Michael: no breaking of fences required. I'm talking about dropping a bucket down and expecting it to flow one way and having it not flow at all.
Bingo
Touchscreen mode is indeed the culprit. I did not even know this was a thing and having it be on by default is quite frustrating (especially as I don't have a touchscreen).
Hmm, it definitely happened, and it was fairly easy, but now I can't get it to either.
Possible
Ah ha, there was a duplicate. I tried to find it, but it eluded me.
Happened to notice today that this is still a problem. Fortunately this time around I knew where the problem was, due to having already been in the midst of debugging a recipe class.
I included the relevant code way back in 2013 (I have no reason to believe that it has substantially changed since). The code floors the player's position values to integers, then subtracts 1 from Y. This works fine if the player is standing anywhere within the XY bounds of the block, and directly on top of it, but as soon as the player is any amount above the block (including jumping and flying) the results change.
I at the time suggested subtracting 1/16th (instead of 1), then flooring, which will always result in the same block if the player is walking on top of a half slab or similar, and would also work for carpets (which are 1/16th thick). Using a smaller value (eg. epsilon) further minimizes the amount above the block could be and get the wrong block (although there are few blocks in Minecraft that do not have size deltas less than 1/16th, only a pressure plate (depressed) does, but it doesn't have collision).