KnightMiner
Assigned
Reported
MC-90861
Dirt and coarse dirt do not properly use their "snowy" states
Won't Fix
MC-82351
Fire overlay appears as missing if not referenced in a model
Fixed
MC-64754
Blocks with different damage values stack when obtained as items if there are no default variants of the block
Works As Intended
MC-62583
Destroying the last block model in a chunk causes ghost blocks
Fixed
MC-62582
Chests, signs, and ender chests do not render in empty chunks
Fixed
MC-61216
/setblock gives an unknown error when a block does not have 0 as a damage value
Fixed
MC-57935
Upside-down stairs have wrong texture on top
Works As Intended
MC-55206
World border texture jumps eight pixels when moving
Cannot Reproduce
MC-53950
Chests, Signs and Mob Heads do not render through semi-transparent entities
Duplicate
MC-50769
Mooshrooms incorrectly display custom mushroom models
Fixed
MC-50130
Semi-Transparent blocks render parts out of order from certain locations
Duplicate
MC-50129
Parts of semi-transparent models (slime blocks, stained glass) are rendered in the wrong order when in third person or in hand
Duplicate
MC-50073
It is possible to change the missing block model
Fixed
MC-48539
Vines briefly display missing model when breaking Supporting Block
Fixed
MC-48512
Vines no longer have a back face texture
Fixed
MC-47811
The bottom texture of non-full blocks is flipped vertically
Fixed
MC-46459
Block Dependent Blocks Render Incorrectly on Barriers, Slime Blocks, and End Portal Frames
Works As Intended
MC-45160
When holding a map you have two right arms
Fixed
MC-44373
Slime Blocks render incorrectly in third person or in hand
Duplicate
Comments
The 1.19.4-pre1 changelog mentioned something about making enchantment glints more visible on items, does this mean that this issue is even more pronounced?
While this bug does not impact vanilla much, it does make usable items difficult in mods in a few ways. Fix seems to be pretty simple, just a patch in both LocalPlayer#drop(boolean) and ServerPlayer#drop(boolean) as those are the last place with access to the use item before it shrinks. See https://github.com/MinecraftForge/MinecraftForge/pull/9344 for a Forge PR implementing the fix.
Did some testing, and the one vanilla gameplay impact I found with the fix is if both the main hand and offhand are usable items, then dropping the main hand item lets you immediately start using the offhand item. I doubt that is ever beneficial in vanilla as you can get the same effect using the scroll wheel, but it is more desirable behavior.
This bug was recently fixed in Minecraft Forge, PR #7718. Assuming the MCP decompilation was correct, Mojang's code had the fix for this bug in there already, it was just one line too late.
Yep, still in 16w50a and 1.11
Yep, still in 16w50a and 1.11
Yep, still in 1.11 and 16w50a
This issue has been resolved as a duplicate, so head over there for confirming it still exists.
The end portal issue was actually MC-51113, which was fixed for end portal frames in 15w46a.
The rest of the issues still exist in 15w46a. Properly set cullfaces fixes the darkening on most blocks on fast lighting, but they are not fixed on smooth lighting.
Fixed on end portal frames in 15w46a, along with stairs it seems. Slime blocks are still affected.
As in the snowy blockstate will no longer exist on dirt and coarse dirt in 1.10?
@@unknown Because there is a snowy podzol state, and dirt and podzol use the same block ID
I can confirm the fix
Apparently this was fixed, likey around the time of cullface's addition (14w25a). All you need to do is set the cullface property to the side you want it to be lighted via (eg, if you have an inset face on the north side, set all parts of the inset face to cullface to the north)
It still doesn't work on smooth lightning, so I suggest changing the issue to state only on smooth lighting
This is completely works as intended. Floating gravel is suppose to fall upon any block update (as its a falling block). That includes placing a torch on it.
Jeb says there is a fix in the next snapshot for this
https://www.reddit.com/r/Minecraft/comments/3j7ld2/next_target_for_19_combat_rebalance_armor/
I wouldn't conciser this issue "Works as intended" as that feature shouldn't even do anything in the overworld. Rather it seems more likely it is blocked by a future change (can you add the "blocked" status without an issue blocking it?)
Edit: meant "the overworld", not "single player"...
I updated the debug pack version number, so it does not complain of incompatibility.
I added a new resource pack for 1.9, which basically is just so there is no error
Did a bit of testing and managed to reproduce this issue on 1.19.3. Seems the problem is the client side stops using the item, but the serverside still thinks its using a now empty item. Easier way to reproduce the issue is to put a nearly broken shield in the main hand, and the other item in the offhand. Holding right click with the shield will cause the offhand item to visually be used (e.g. eating or blocking animation plays), but the server still thinks the mainhand is being used.
All the cases of "this bug does not happen if" boil down to switching items causes you to stop using items, putting the server and client back in sync. e.g. if you break a shield in the main hand then try using an item in another hotbar slot.