Irony
- Irony
- irony
- America/Toronto
- Yes
- No
![[Mojang] Cory Scheviak](../../../data/avatars/users/92893.png){kind=small}
![[Mojang] eowyn36](../../../data/avatars/users/18935.svg){kind=small}
![[Mojang] Panda](../../../data/avatars/users/41658.png){kind=small}
MC-175986MC-176008
LowMC-226875
Piglin & Zombified Piglin left leg/arm texture is not mirrored similar to its original counterpart.
A small thing I noticed and was probably overlooked but the original zombie pigman had its leg/arm texture mirrored but as of the latest snapshot neither the piglin nor the zombified piglins left leg/arm textures are mirrored.
The new texture:
The original texture:
Unlike other ores in the game nether gold ore doesn't reward the player with any experience when mined with a pickaxe, this could be intentional considering the ore can be collected using silk touch in order to receive experience by smelting it as a trade off.
After defeating the ender dragon or just leaving the end dimension through an end portal and respawning within the nether at the player's set spawn the respawn anchor does not play a respawn anchor deplete sound although glowstone is consumed.
Repeatedly mounting a strider while sneakinggenerates block lagRepeatedly mounting a strider while sneaking causes odd behavior
Lodestone compasses that are stored inside a container like a chest for example or stored inside of an item frame do not update if their connected lodestone is mined causing them to be continuously pointed towards the same coordinates until it has been re-added to the player's inventory.
Lodestone compass does not get converted back to normal compass afterassociated lodestone is brokenLodestone compass does not get converted back to normal compass after linked lodestone is broken
Saddled strider cannot be mounted if there is a baby strider alreadysitting on itSaddled strider cannot be mounted if there is a baby strider already riding on it
Spawn eggs with entity tag for item frames and glow item frames entities are summoned 1 block lower than expected
Spawn eggs with entity tag for item framesand glow item framesentities are summoned 1 block lower than expected
Spawn eggs with custom entity tag for either item frame or glow item frame will be summoned 1 block lower than expected. In this case all item frames that are fixed will pop off immediately upon spawning in the block below.
Steps to recreate:
- Give yourself spawn egg with custom EntityTag for item frame or glow item frame (/give @s minecraft:pig_spawn_egg{EntityTag:{id:"minecraft:item_frame",Facing:3b}})
- Use spawn egg to summon item frame/glow item frame in the world
Tested on latest 1.17 snapshot version 21w17a and latest release version 1.16.5.
Spawn eggs with custom entity tag for either item frame or glow item frame will be summoned 1 block lower than expected. In this case all item frames that aren't fixed will pop off immediately upon spawning in the block below.
Steps to recreate:
- Give yourself spawn egg with custom EntityTag for item frame or glow item frame (/give @s minecraft:pig_spawn_egg{EntityTag:{id:"minecraft:item_frame",Facing:3b}})
- Use spawn egg to summon item frame/glow item frame in the world
Tested on latest 1.17 snapshot version 21w17a and latest release version 1.16.5.
Advancement trigger for "bee_nest_destroyed" has a block condition albeit not being able to specify any block that isn't a bee nest or beehive. This condition should either be removed for consistency and causing confusion or by adding compatibility for other block types.
The reason this was created is because "bee_nest_destroyed" can now use the new blocks predicate for the block field added in the latest 1.17 Pre-release 1 to specify both bee nest and beehive which currently isn't the case.
Steps to reproduce:
- Create an advancement using "bee_nest_destroyed" trigger.
- Try to grant advancement in-game via task.
Advancement trigger for "bee_nest_destroyed" has a block condition albeit not being able to specify any block that isn't a bee nest or beehive. This condition should either be removed for consistency and causing confusion or by adding compatibility for other block types.
The reason this was created is because "bee_nest_destroyed" can now use the new blocks predicate for the block field added in the latest 1.17 Pre-release 1 to specify both bee nest and beehive which currently isn't the case.
An example of an advancement that is affected by this includes "silk_touch_nest".
Steps to reproduce:
- Create an advancement using "bee_nest_destroyed" trigger.
- Try to grant advancement in-game via task.
Advancement trigger for "bee_nest_destroyed" has a block condition albeit not being able to specify any block that isn't a bee nest or beehive. This condition should either be removed for consistency and causing confusion or by adding compatibility for other block types.
The reason this was created is because "bee_nest_destroyed" can now use the new blocks predicate for the block field added in the latest 1.17 Pre-release 1 to specify both bee nest and beehive which currently isn't the case.
An example of an advancement that is affected by this includes "silk_touch_nest".
Steps to reproduce:
- Create an advancement using "bee_nest_destroyed" trigger using blocks predicate.
- Try to grant advancement in-game via task.
Yes, this issue was resolved in 20w14a. This needs to be closed.
Hi,
See demo video below regarding this issue, item frame should be summoned a block above as any item frame that doesn't have a fixed tag will immediately break as it's currently being placed in a full block.
https://streamable.com/azj22t