haykam
- haykam
- haykam
- America/New_York
- Yes
- No
MC-169962![[Mojang] Panda](../../../data/avatars/users/41658.png){kind=small}
![[Mojang] Cory Scheviak](../../../data/avatars/users/92893.png){kind=small}
![[Mojang] Adrian Östergård](../../../data/assets/gravatar/nighter.jpeg){kind=small}
![[Mojang] Gegy](../../../data/avatars/users/10122.svg){kind=small}
![[Mojang] Brandon Pearce](../../../data/avatars/users/40932.png){kind=small}
Low
Normal![[Mojang] Felix Jones](../../../data/avatars/users/40484.png){kind=small}
![[Mojang] Georgii Gavrichev](../../../data/avatars/users/22428.png){kind=small}
Unlike all other tags in vanilla Minecraft, the block tag 'minecraft:beacon_base_blocks' and item tag 'minecraft:beacon_payment_items' are redundant, including the type in the name.
Possible alternate names:
- For beacon base blocks: 'minecraft:beacon_bases'
- For beacon payment items: 'minecraft:beacon_payments'
- For beacon payment items: 'minecraft:beacon_currencies'
- For beacon payment items: 'minecraft:beacon_activators'
- For beacon payment items: 'minecraft:beacon_fuels' (from[20w07a changelog|https://www.minecraft.net/en-us/article/minecraft-snapshot-20w07a])
Unlike all other tags in vanilla Minecraft, the block tag 'minecraft:beacon_base_blocks' and item tag 'minecraft:beacon_payment_items' are redundant, including the type in the name.
Possible alternate names:
- For beacon base blocks: 'minecraft:beacon_bases'
- For beacon payment items: 'minecraft:beacon_payments'
- For beacon payment items: 'minecraft:beacon_currencies'
- For beacon payment items: 'minecraft:beacon_activators'
- For beacon payment items: 'minecraft:beacon_fuels' (from
[20w07a changelog|https://www.minecraft.net/en-us/article/minecraft-snapshot-20w07a])Unlike all other tags in vanilla Minecraft, the block tag 'minecraft:beacon_base_blocks' and item tag 'minecraft:beacon_payment_items' are redundant, including the type in the name.
Possible alternate names:
- For beacon base blocks: 'minecraft:beacon_bases'
- For beacon payment items: 'minecraft:beacon_payments'
- For beacon payment items: 'minecraft:beacon_currencies'
- For beacon payment items: 'minecraft:beacon_activators'
- For beacon payment items: 'minecraft:beacon_fuels' (from 20w07a changelog)
Unlike all other tags in vanilla Minecraft, the block tag
'minecraft:beacon_base_blocks'and item tag 'minecraft:beacon_payment_items' are redundant, including the type in the name.Possible alternate names:
- For beacon base blocks: 'minecraft:beacon_bases'
- For beacon payment items: 'minecraft:beacon_payments'
- For beacon payment items: 'minecraft:beacon_currencies'
- For beacon payment items: 'minecraft:beacon_activators'
- For beacon payment items: 'minecraft:beacon_fuels' (from 20w07a changelog)
Unlike all other tags in vanilla Minecraft, the block tag `minecraft:beacon_base_blocks` and item tag 'minecraft:beacon_payment_items' are redundant, including the type in the name.
Possible alternate names:
- For beacon base blocks: 'minecraft:beacon_bases'
- For beacon payment items: 'minecraft:beacon_payments'
- For beacon payment items: 'minecraft:beacon_currencies'
- For beacon payment items: 'minecraft:beacon_activators'
- For beacon payment items: 'minecraft:beacon_fuels' (from 20w07a changelog)
Unlike all other tags in vanilla Minecraft, the block tag `minecraft:beacon_base_blocks` and item tag 'minecraft:beacon_payment_items' are redundant, including the type in the name.
Possible alternate names:
- For beacon base blocks: 'minecraft:beacon_bases'
- For beacon payment items: 'minecraft:beacon_payments'
- For beacon payment items: 'minecraft:beacon_currencies'
- For beacon payment items: 'minecraft:beacon_activators'
- For beacon payment items: 'minecraft:beacon_fuels' (from 20w07a changelog)
Unlike all other tags in vanilla Minecraft, the block tag minecraft:beacon_base_blocks and item tag minecraft:beacon_payment_items are redundant, including the type in the name.
Possible alternate names:
- For beacon base blocks: minecraft:beacon_bases
- For beacon payment items: minecraft:beacon_payments
- For beacon payment items: minecraft:beacon_currencies
- For beacon payment items: minecraft:beacon_activators
- For beacon payment items: minecraft:beacon_fuels (from 20w07a changelog)
Unlike all other tags in vanilla Minecraft, the block tag minecraft:beacon_base_blocks and
item tagminecraft:beacon_payment_items are redundant, including the type in the name.Possible alternate names:
- For
beaconbase blocks: minecraft:beacon_bases- For beacon payment items: minecraft:beacon_payments
- For beacon payment items: minecraft:beacon_currencies
- For beacon payment items: minecraft:beacon_activators
- For beacon payment items: minecraft:beacon_fuels (from 20w07a changelog)
Unlike all other tags in vanilla Minecraft, the block tags minecraft:beacon_base_blocks and minecraft:wither_summoning_base_blocks, and the item tag minecraft:beacon_payment_items are redundant, including the type in the name.
Possible alternate names:
- For beacon base blocks: minecraft:beacon_bases
- For Wither summoning base blocks: minecraft:wither_summoning_bases
- For beacon payment items: minecraft:beacon_payments
- For beacon payment items: minecraft:beacon_currencies
- For beacon payment items: minecraft:beacon_activators
- For beacon payment items: minecraft:beacon_fuels (from 20w07a changelog)
If you launch Minecraft, it shows the old
(bad) logo. It should show the new logo with Mojang Studios'slittle secrets.If you launch Minecraft, it shows the old Mojang logo with a white background. It should instead show the new logo with Mojang Studios's updating branding and red background
mojang (Mojang Studios)logois outdatedTitle screen logo uses old Mojang logo rather than new Mojang Studios logo
If a villager with no experience and
{PersistenceRequired: 1b}is struck by lightning and converted into a witch, the witch that replaces the villager will have
{PersistenceRequired: 0b}.
Code analysis (Yarn mappings)
LOGGER.info("Villager {} was struck by lightning {}.", this, lightning); WitchEntity witchEntity = (WitchEntity)EntityType.WITCH.create(this.world); witchEntity.refreshPositionAndAngles(this.getX(), this.getY(), this.getZ(), this.yaw, this.pitch); witchEntity.initialize(this.world, this.world.getLocalDifficulty(witchEntity.getBlockPos()), SpawnReason.CONVERSION, (EntityData)null, (CompoundTag)null); witchEntity.setAiDisabled(this.isAiDisabled()); if (this.hasCustomName()) { witchEntity.setCustomName(this.getCustomName()); witchEntity.setCustomNameVisible(this.isCustomNameVisible()); } // Unlike other conversion code, this does not check whether this.isPersistent() as well if (this.getExperience() > 0) { witchEntity.setPersistent(); } this.world.spawnEntity(witchEntity); this.remove();If a villager with no experience and
{PersistenceRequired: 1b}is struck by lightning and converted into a witch, the witch that replaces the villager will have
{PersistenceRequired: 0b}.
Code analysis (Yarn mappings)
LOGGER.info("Villager {} was struck by lightning {}.", this, lightning); WitchEntity witchEntity = (WitchEntity)EntityType.WITCH.create(this.world); witchEntity.refreshPositionAndAngles(this.getX(), this.getY(), this.getZ(), this.yaw, this.pitch); witchEntity.initialize(this.world, this.world.getLocalDifficulty(witchEntity.getBlockPos()), SpawnReason.CONVERSION, (EntityData)null, (CompoundTag)null); witchEntity.setAiDisabled(this.isAiDisabled()); if (this.hasCustomName()) { witchEntity.setCustomName(this.getCustomName()); witchEntity.setCustomNameVisible(this.isCustomNameVisible()); } // Unlike other conversion code, this does not check whether this.isPersistent() as well if (this.getExperience() > 0) { witchEntity.setPersistent(); } this.world.spawnEntity(witchEntity); this.remove();
Villagershitby a lightning strike can despawn if the villager has no experiencePersistent villagers without experience can despawn after converting to a witch
A ghost biome ring appears around the player's spawn when they first log in to a world. This can be seen as it effects the color of leaves, grasses, and other plants. Sometimes this ring will disappear once the world finishes loading, but other times, it persists until the player relogs or the chunk is updated.
The spelling in the fast graphics tooltip is incorrect. Rather than 'tree-leaves', it should be spelled 'tree leaves'
.The spelling in the fast graphics tooltip is incorrect. Rather than 'tree-leaves', it should be spelled 'tree leaves', or even simplified to 'leaves' (as this behavior applies to all leaves, not just on trees)
the file in file explorer.pngThe name for the configured feature patch_waterlilly
is incorrect. It either should bepatch_waterlily , patch_water_lily , or patch_lily_pad .The name for the configured feature patch_waterlilly (located in slicedlime/example s at worldgen/configured_feature/patch_waterlilly.json ) is incorrect. It either should be patch_waterlily , patch_water_lily , or patch_lily_pad .
The name for the configured feature patch_waterlilly (located in slicedlime/example
sat worldgen/configured_feature/patch_waterlilly.json ) is incorrect. It either should be patch_waterlily , patch_water_lily , or patch_lily_pad .The name for the configured feature patch_waterlilly (located in slicedlime/examples at worldgen/configured_feature/patch_waterlilly.json ) is incorrect. It either should be patch_waterlily , patch_water_lily , or patch_lily_pad .
The name for the configured feature patch_waterlilly (located in slicedlime/examples at worldgen/configured_feature/patch_waterlilly.json ) is incorrect. It either should be patch_waterlily , patch_water_lily , or patch_lily_pad .
The name for the configured feature patch_waterlilly (located in slicedlime/examples at worldgen/configured_feature/patch_waterlilly.json ) is incorrect. It either should be patch_waterlily
,patch_water_lily , orpatch_lily_pad.The name for the configured feature patch_waterlilly (located in slicedlime/examples at worldgen/configured_feature/patch_waterlilly.json ) is incorrect. It either should be patch_lily_pad to match the block lily_pad .
Steps to reproduce
1. Type /place feature minecraft:patch_waterlily .
2. Observe that this is an accepted feature name.
The name for the configured feature patch_waterlil
ly(located inslicedlime/examples at worldgen/configured_feature/patch_waterlilly.json) is incorrect. It either should be patch_lily_pad to match the block lily_pad.Steps to reproduce
1. Type /place feature minecraft:patch_waterlily.
2. Observe that this is an accepted feature name.
Incorrect name for configured feature 'patch_waterlilly'
In 1.16, the debug world chunk generator loads much earlier than before, causing unnecessary overhead for caching block states. In addition, this means blocks that are registered later are not generated in the debug world.
This bug is fixed in Palette Cleanser and Fabric API .
A merchant trade select packet sent from the client to the server is not checked for an index that is
within the available trades. Because of this, sending an invalidindex such as -1 will cause an ArrayIndexOutOfBoundsException to be thrown and logged to the console.A merchant trade select packet sent from the client to the server is not checked for an index that is less than 0, only less than the size of the trade offer list. Because of this, sending a negative index such as -1 will cause an ArrayIndexOutOfBoundsException to be thrown and logged to the console.
Merchant trade select packet (C2S) does not check forout-of-boundindicesMerchant trade select packet (C2S) does not check for negative indices
A merchant trade select packet sent from the client to the server is not checked for an index that is less than 0, only less than the size of the trade offer list. Because of this, sending a negative index such as -1 will cause an ArrayIndexOutOfBoundsException to be thrown and logged to the console.
[12:00:00] [Server thread/FATAL] (Minecraft) Error executing task on Server java.lang.ArrayIndexOutOfBoundsException: null
A merchant trade select packet sent from the client to the server is not checked for an index that is less than 0, only less than the size of the trade offer list. Because of this, sending a negative index such as -1 will cause an ArrayIndexOutOfBoundsException to be thrown and logged to the console.
[12:00:00] [Server thread/FATAL] (Minecraft) Error executing task on Server java.lang.ArrayIndexOutOfBoundsException: nullCode analysis (Yarn mappings):
public void onVillagerTradeSelect(SelectVillagerTradeC2SPacket packet) { NetworkThreadUtils.forceMainThread(packet, this, (ServerWorld)this.player.getServerWorld()); int i = packet.getTradeId(); ScreenHandler screenHandler = this.player.currentScreenHandler; if (screenHandler instanceof MerchantScreenHandler) { MerchantScreenHandler merchantScreenHandler = (MerchantScreenHandler)screenHandler; // Check for i >= 0 before calling the screen handler method(s) merchantScreenHandler.setRecipeIndex(i); merchantScreenHandler.switchTo(i); } }
A merchant trade select packet sent from the client to the server is not checked for an index that is less than 0, only less than the size of the trade offer list. Because of this, sending a negative index such as -1 will cause an ArrayIndexOutOfBoundsException to be thrown and logged to the console.
[12:00:00] [Server thread/FATAL] (Minecraft) Error executing task on Server java.lang.ArrayIndexOutOfBoundsException: nullCode analysis (Yarn mappings):
public void onVillagerTradeSelect(SelectVillagerTradeC2SPacket packet) {NetworkThreadUtils.forceMainThread(packet, this, (ServerWorld)this.player.getServerWorld());inti= packet.getTradeId();ScreenHandler screenHandler = this.player.currentScreenHandler;if (screenHandler instanceof MerchantScreenHandler) {MerchantScreenHandler merchantScreenHandler = (MerchantScreenHandler)screenHandler;// Check for i >= 0 before calling the screen handler method(s)merchantScreenHandler.setRecipeIndex(i);merchantScreenHandler.switchTo(i); }}A merchant trade select packet sent from the client to the server is not checked for an index that is less than 0, only less than the size of the trade offer list. Because of this, sending a negative index such as -1 will cause an ArrayIndexOutOfBoundsException to be thrown and logged to the console.
[12:00:00] [Server thread/FATAL] (Minecraft) Error executing task on Server java.lang.ArrayIndexOutOfBoundsException: nullCode analysis (Yarn mappings):
public void onMerchantTradeSelect(SelectMerchantTradeC2SPacket packet) { NetworkThreadUtils.forceMainThread(packet, this, (ServerWorld) this.player.getServerWorld()); int tradeId = packet.getTradeId(); ScreenHandler screenHandler = this.player.currentScreenHandler; if (screenHandler instanceof MerchantScreenHandler) { MerchantScreenHandler merchantScreenHandler = (MerchantScreenHandler) screenHandler; // Check for i >= 0 before calling the screen handler method(s) merchantScreenHandler.setRecipeIndex(tradeId); merchantScreenHandler.switchTo(tradeId); } }
The message for an exception thrown by the missing dimension datafixer has a typo (exptected) which should be changed to expected.
throw new IllegalStateException("List exptected");The message for an exception thrown by the missing dimension datafixer ({{
{MissingDimensionFix}}} in Yarn mappings) has a typo (exptected) which should be changed to expected.
throw new IllegalStateException("List exptected");
The message for an exception thrown by the missing dimension datafixer ({{
{MissingDimensionFix}
}}in Yarn mappings) has a typo (exptected) which should be changed to expected.throw new IllegalStateException("List exptected");The message for an exception thrown by the missing dimension datafixer (MissingDimensionFix in Yarn mappings) has a typo (exptected) which should be changed to expected.
throw new IllegalStateException("List exptected");
The translation key used for villager professions is of the form: entity.minecraft.villager.<profession>. Because of this, two villager professions with IDs of the same path but different namespaces (such as foo:developer and bar:developer) will have the same translation key, entity.minecraft.villager.developer.
This is inconsistent with other registries' translation keys in that it does not have a namespace, and less importantly, is not top-level (villager_profession.<namespace>.<path>).
Steps to reproduce
1. Execute the following command:: {{/tellraw @s
{"translate":"entity.minecraft.villager.librarian"}}}
2. Notice that the text is translated, despite the translation key not including a namespace for the minecraft:librarian identifier.
The translation key used for villager professions is of the form: entity.minecraft.villager.<profession>. Because of this, two villager professions with IDs of the same path but different namespaces (such as foo:developer and bar:developer) will have the same translation key, entity.minecraft.villager.developer.
This is inconsistent with other registries' translation keys in that it does not have a namespace, and less importantly, is not top-level (villager_profession.<namespace>.<path>).
Steps to reproduce
1. Execute the following command:: {{/tellraw @s
{"translate":"entity.minecraft.villager.librarian"}}
}
2. Notice that the text is translated, despite the translation key not including a namespace for the minecraft:librarian identifier.The translation key used for villager professions is of the form: entity.minecraft.villager.<profession>. Because of this, two villager professions with IDs of the same path but different namespaces (such as foo:developer and bar:developer) will have the same translation key, entity.minecraft.villager.developer.
This is inconsistent with other registries' translation keys in that it does not have a namespace, and less importantly, is not top-level (villager_profession.<namespace>.<path>).
Steps to reproduce
1. Execute the following command:: /tellraw @s {"translate":"entity.minecraft.villager.librarian"}
2. Notice that the text is translated, despite the translation key not including a namespace for the minecraft:librarian identifier.
The translation key used for villager professions is of the form: entity.minecraft.villager.<profession>. Because of this, two villager professions with IDs of the same path but different namespaces (such as foo:developer and bar:developer) will have the same translation key, entity.minecraft.villager.developer.
This is inconsistent with other registries' translation keys in that it does not have a namespace, and less importantly, is not top-level (villager_profession.<namespace>.<path>).
Steps to reproduce
1. Execute the following command:: /tellraw @s {"translate":"entity.minecraft.villager.librarian"}
2. Notice that the text is translated, despite the translation key not including a namespace for the minecraft:librarian identifier.
The translation key used for villager professions is of the form: entity.minecraft.villager.<profession>. Because of this, two villager professions with IDs of the same path but different namespaces (such as foo:developer and bar:developer) will have the same translation key, entity.minecraft.villager.developer.
This is inconsistent with other registries' translation keys in that it does not have a namespace, and less importantly, is not top-level (villager_profession.<namespace>.<path>).
Steps to reproduce
1. Execute the following command:
:/tellraw @s {"translate":"entity.minecraft.villager.librarian"}
2. Notice that the text is translated, despite the translation key not including a namespace for the minecraft:librarian identifier.
Revoking all advancements causeslots of lagRevoking all advancements causes client-side stutter
The "Is it a __?" series of advancements are still granted to players who look at invisible entities. This does not make sense, because the player shouldn't see anything.
To reproduce:
/give @s minecraft:spyglass /advancement revoke @s only minecraft:adventure/spyglass_at_parrot /summon minecraft:parrot ~5 ~ ~ {NoAI:1b,Size:3,Glowing:1b,active_effects:[{duration:-1,amplifier:0b,id:"minecraft:invisibility"}]}
The "Is it a __?" series of advancements are still granted to players who look at invisible entities. This does not make sense, because the player shouldn't see anything.
To reproduce:
/give @s minecraft:spyglass /advancement revoke @s only minecraft:adventure/spyglass_at_parrot /summon minecraft:parrot ~5 ~ ~ {NoAI:1b,Size:3,Glowing:1b,active_effects:[{duration:-1,amplifier:0b,id:"minecraft:invisibility"}]}
Rather than the correct spelling lapis_lazuli , the group used in smelting and blasting recipes for lapis lazuli ore is lapus_lazuli .
Using Yarn mappings, the following method is found in `ItemDispenserBehavior` and overridden unnecessarily in `BoatDispenserBehavior` (which extends the former):
protected void playSound(BlockPointer pointer) { pointer.getWorld().syncWorldEvent(WorldEvents.DISPENSER_DISPENSES, pointer.getPos(), 0); }Using Yarn mappings, the following method is found in ItemDispenserBehavior and overridden unnecessarily in BoatDispenserBehavior (which extends the former):
protected void playSound(BlockPointer pointer) { pointer.getWorld().syncWorldEvent(WorldEvents.DISPENSER_DISPENSES, pointer.getPos(), 0); }
Using Yarn mappings, the following method
is found inItemDispenserBehaviorand overridden unnecessarilyinBoatDispenserBehavior(which extends the former):protected void playSound(BlockPointer pointer) { pointer.getWorld().syncWorldEvent(WorldEvents.DISPENSER_DISPENSES, pointer.getPos(), 0); }Using Yarn mappings, the following method exists in the BoatDispenserBehavior class: following method is found in ItemDispenserBehavior and overridden unnecessarily in BoatDispenserBehavior (which extends the former):
protected void playSound(BlockPointer pointer) { pointer.world().syncWorldEvent(WorldEvents.DISPENSER_DISPENSES, pointer.pos(), 0); }The immediate superclass, ItemDispenserBehavior, implements the method in the same way, though through invoking a static method:
Since the two implementations have the same effect, the
Using Yarn mappings, the following method exists in the BoatDispenserBehavior class: following method is found in ItemDispenserBehavior and overridden unnecessarily in BoatDispenserBehavior (which extends the former):
protected void playSound(BlockPointer pointer) {pointer.world().syncWorldEvent(WorldEvents.DISPENSER_DISPENSES, pointer.pos(), 0); }The immediate superclass, ItemDispenserBehavior, implements the method in the same way, though through invoking a static method:
Since the two implementations have the same effect, the
Using Yarn mappings, the following method exists in the BoatDispenserBehavior class:
protected void playSound(BlockPointer pointer) { pointer.world().syncWorldEvent(WorldEvents.DISPENSER_DISPENSES, pointer.pos(), 0); }The immediate superclass, ItemDispenserBehavior, implements the method in the same way, though through invoking a static method:
protected void playSound(BlockPointer pointer) { syncDispensesEvent(pointer); } private static void syncDispensesEvent(BlockPointer pointer) { pointer.world().syncWorldEvent(WorldEvents.DISPENSER_DISPENSES, pointer.pos(), 0); }Since the two implementations have the same effect, the BoatDispenserBehavior#playSound override is unnecessary.
Using Yarn mappings, the following method exists in the BoatDispenserBehavior class:
protected void playSound(BlockPointer pointer) { pointer.world().syncWorldEvent(WorldEvents.DISPENSER_DISPENSES, pointer.pos(), 0); }The immediate superclass, ItemDispenserBehavior, implements the method in the same way, though through invoking a static method:
protected void playSound(BlockPointer pointer) { syncDispensesEvent(pointer); } private static void syncDispensesEvent(BlockPointer pointer) { pointer.world().syncWorldEvent(WorldEvents.DISPENSER_DISPENSES, pointer.pos(), 0); }Since the two implementations have the same effect, the BoatDispenserBehavior#playSound override is unnecessary.
Using Yarn mappings, the following method exists in the BoatDispenserBehavior class:
@Override protected void playSound(BlockPointer pointer) { pointer.world().syncWorldEvent(WorldEvents.DISPENSER_DISPENSES, pointer.pos(), 0); }The immediate superclass, ItemDispenserBehavior, implements the method in the same way, though through invoking a static method:
protected void playSound(BlockPointer pointer) { syncDispensesEvent(pointer); } private static void syncDispensesEvent(BlockPointer pointer) { pointer.world().syncWorldEvent(WorldEvents.DISPENSER_DISPENSES, pointer.pos(), 0); }Since the two implementations have the same effect, the BoatDispenserBehavior#playSound override is unnecessary.
Currently, the GUI Scale and Autosuggest Commands options have broken names.
In particular:
- GUI Scale only displays its value, rather than its name and value
- Autosuggest Commands displays its name but its name is not translated
Currently, the GUI Scale and
Autosuggest Commands options have broken names.In particular:
- GUI Scale only displays its value, rather than its name and value
Autosuggest Commands displays its name but its name is not translatedCurrently, the GUI Scale and Command Suggestions options have broken names.
In particular:
- GUI Scale only displays its value, rather than its name and value
- Command Suggestions displays its name but its name is not translated
Currently, the GUI Scale and Command Suggestions options have broken names.
In particular:
- GUI Scale only displays its value, rather than its name and value
- Command Suggestions displays its name but its name is not translated due to a translation key typo
- Realms Notifications displays its name but its name is not translated due to a translation key typo
Currently, the GUI Scale
andCommand Suggestions options have broken names.In particular:
- GUI Scale only displays its value, rather than its name and value
- Command Suggestions displays its name but its name is not translated due to a translation key typo
- Realms Notifications displays its name but its name is not translated due to a translation key typo
Currently, the GUI Scale, Command Suggestions, and Realms Notifications options have broken names.
In particular:
- GUI Scale only displays its value, rather than its name and value
- Command Suggestions displays its name but its name is not translated due to a translation key typo
- Realms Notifications displays its name but its name is not translated due to a translation key typo
In normal boats and minecarts, shulkers use a custom height offset so that they do not intersect the entity they are mounted on. This override is defined within Yarn mappings'
{ShulkerEntity#getHeightOffset}:
@Override public double getHeightOffset() { EntityType<?> entityType = this.getVehicle().getType(); if (entityType == EntityType.BOAT || entityType == EntityType.MINECART) { return 0.1875 - this.getVehicle().getMountedHeightOffset(); } return super.getHeightOffset(); }In case it isn't obvious, boats aren't boats with chests. That's actually not that obvious, but boats are the entity type
{minecraft:boat}, while boats with chests are the entity type
{minecraft:chest_boat}. As such, for boats with chests,
{entityType == EntityType.BOAT}is
{false}(and of course, in case it isn't obvious, boats aren't minecarts).
This problem would easily be fixed by checking for the entity type
{minecraft:chest_boat}, or just checking
{entityType instanceof BoatEntity}, which both boats and boats with chests satisfy. The latter is ideal since modded boats otherwise need to solve this same issue.
In normal boats and minecarts, shulkers use a custom height offset so that they do not intersect the entity they are mounted on. This override is defined within Yarn mappings' ShulkerEntity#getHeightOffset
@Override public double getHeightOffset() { EntityType<?> entityType = this.getVehicle().getType(); if (entityType == EntityType.BOAT || entityType == EntityType.MINECART) { return 0.1875 - this.getVehicle().getMountedHeightOffset(); } return super.getHeightOffset(); }In case it isn't obvious, boats aren't boats with chests. That's actually not that obvious, but boats are the entity type minecraft:boat, while boats with chests are the entity type minecraft:chest_boat. As such, for boats with chests, entityType == EntityType.BOAT is false (and of course, in case it isn't obvious, boats aren't minecarts).
This problem would easily be fixed by checking for the entity type minecraft:chest_boat, or just checking entityType instanceof BoatEntity, which both boats and boats with chests satisfy. The latter is ideal since modded boats otherwise need to solve this same issue.
In normal boats and minecarts, shulkers use a custom height offset so that they do not intersect the
entity they are mounted on. This override is defined within Yarn mappings' ShulkerEntity#getHeightOffset@Override public double getHeightOffset() { EntityType<?> entityType = this.getVehicle().getType(); if (entityType == EntityType.BOAT || entityType == EntityType.MINECART) { return 0.1875 - this.getVehicle().getMountedHeightOffset(); } return super.getHeightOffset(); }In case it isn't obvious, boats aren't boats with chests. That's actually not that obvious, but boats are the entity type minecraft:boat, while boats with chests are the entity type minecraft:chest_boat. As such, for boats with chests, entityType == EntityType.BOAT is false (and of course, in case it isn't obvious, boats aren't minecarts).
This problem would easily be fixed by checking for the entity type minecraft:chest_boat, or just checking entityType instanceof BoatEntity
, which both boats and boats with chests satisfy. The latteris ideal since modded boats otherwise need to solve this same issue.In normal boats and minecarts, shulkers use a custom height offset so that they do not intersect their vehicle. This override is defined within Yarn mappings' ShulkerEntity#getHeightOffset
@Override public double getHeightOffset() { EntityType<?> entityType = this.getVehicle().getType(); if (entityType == EntityType.BOAT || entityType == EntityType.MINECART) { return 0.1875 - this.getVehicle().getMountedHeightOffset(); } return super.getHeightOffset(); }In case it isn't obvious, boats aren't boats with chests. That's actually not that obvious, but boats are the entity type minecraft:boat, while boats with chests are the entity type minecraft:chest_boat. As such, for boats with chests, entityType == EntityType.BOAT is false (and of course, in case it isn't obvious, boats aren't minecarts).
This problem is easily fixed by expanding the vehicle check. For example:
- Checking for the entity type minecraft:chest_boat as well
- An entity type tag!
- Checking entityType instanceof BoatEntity, which both boats and boats with chests satisfy
The last proposed solution is ideal since modded boats otherwise need to solve this same issue.
In normal boats and minecarts, shulkers use a custom height offset so that they do not intersect their vehicle. This override is defined within Yarn mappings' ShulkerEntity#getHeightOffset:
@Override public double getHeightOffset() { EntityType<?> entityType = this.getVehicle().getType(); if (entityType == EntityType.BOAT || entityType == EntityType.MINECART) { return 0.1875 - this.getVehicle().getMountedHeightOffset(); } return super.getHeightOffset(); }In case it isn't obvious, boats aren't boats with chests. That's actually not that obvious, but boats are the entity type minecraft:boat, while boats with chests are the entity type minecraft:chest_boat. As such, for boats with chests, entityType == EntityType.BOAT is false (and of course, in case it isn't obvious, boats aren't minecarts).
This problem is easily fixed by expanding the vehicle check. For example:
- Checking for the entity type minecraft:chest_boat as well
- An entity type tag!
- Checking entityType instanceof BoatEntity, which both boats and boats with chests satisfy
The last proposed solution is ideal since modded boats otherwise need to solve this same issue.
Chat messages have two translations, one for display and one for narration:
{ "chat.type.text": "<%s> %s", "chat.type.text.narrate": "%s says %s" }Due to the text refactor in 22w16a, only the display text is used for both display and narration. In particular, the narrator says "author message" instead of "author says message".
This is caused by Minecraft checking whether the text itself is translatable, when due to the new class hierarchy, only the content can be translatable.
Chat messages have two translations, one for display and one for narration:
{ "chat.type.text": "<%s> %s", "chat.type.text.narrate": "%s says %s" }Due to the text refactor in 22w16a, only the display text is used for both display and narration. In particular, the narrator says "author message" instead of "author says message".
This is caused by Minecraft checking whether the text itself is translatable, when due to the new class hierarchy, only the content can be translatable. Specifically (Yarn mappings:
public static Text replaceTranslationKey(Text text, String old, String new) { if (text instanceof TranslatableTextContent && oldKey.equals(// ... } }
Chat messages have two translations, one for display and one for narration:
{ "chat.type.text": "<%s> %s", "chat.type.text.narrate": "%s says %s" }Due to the text refactor in 22w16a, only the display text is used for both display and narration. In particular, the narrator says "author message" instead of "author says message".
This is caused by Minecraft checking whether the text itself is translatable, when due to the new class hierarchy, only the content can be translatable. Specifically (Yarn mappings:
public static Text replaceTranslationKey(Text text, String old, Stringnew) { if (text instanceof TranslatableTextContent && oldKey.equals(// ... } }Chat messages have two translations, one for display and one for narration:
{ "chat.type.text": "<%s> %s", "chat.type.text.narrate": "%s says %s" }Due to the text refactor in 22w16a, only the display text is used for both display and narration. In particular, the narrator says "author message" instead of "author says message".
This is caused by Minecraft checking whether the text itself is translatable, when due to the new class hierarchy, only the content can be translatable. Specifically (Yarn mappings:
public static Text replaceTranslationKey(Text text, String oldKey, String newKey) { if (text instanceof TranslatableTextContent && oldKey.equals(// ... } }
Since boats and rafts share an entity type, rafts will be
named boats.Since boats and rafts share an entity type, rafts will be called boats in places where the entity name is used, such as their screen.
For example, the sound event for a bamboo door (note no 'wood') is minecraft:block.bamboo_wood_door.close instead of the expected minecraft:block.bamboo_door.close
.Note that regular wooden doors use minecraft:block.wooden_door.close and doors made of Nether wood use minecraft:block.nether_wood_door.close .For example, the sound event for a bamboo door (note no 'wood') is minecraft:block.bamboo_wood_door.close instead of the expected minecraft:block.bamboo_door.close .
Note that regular wooden doors use minecraft:block.wooden_door.close and doors made of Nether wood use minecraft:block.nether_wood_door.close .
For example, the sound event for a bamboo door (note no 'wood') is minecraft:block.bamboo_wood_door.close instead of the expected minecraft:block.bamboo_door.close.
Note that regular wooden doors use minecraft:block.wooden_door.close and doors made of Nether wood use minecraft:block.nether_wood_door.close.
For example, the sound event for a bamboo door (note no 'wood') is minecraft:block.bamboo_wood_door.close instead of the expected minecraft:block.bamboo_door.close.
The other sound events for doors, for reference:
- minecraft:block.wooden_door.close (regular wooden doors)
- minecraft:block.nether_wood_door.close (doors made of Nether wood)
Given that
MC-256466hasn't been marked as 'won't fix', I would consider rafts being counted as boats for the 'Whatever Floats Your Goat' advancement a bug as well. The description in particular references boats by name.Besides, this is just an opportunity for a follow-up advancement anyways
"Whatever Wafts [makes something travel smoothly across water] Your Calf [a baby cow]"?
![[Mod] Avoma](../../../data/avatars/users/86198.png){kind=small}
The Bug:
There are no shadows on text displayed within the action bar.
This is an issue because the text can be quite difficult to read, so having a shadow displayed on all text within the action bar would resolve this problem.
Steps to Reproduce:
- Display some text on the action bar and look at it closely.
/title @a actionbar {"text":"MC-72687","color":"white"}
- Take note as to whether or not there are any shadows on text displayed within the action bar.
Observed Behavior:
There are no shadows on text displayed within the action bar.
Expected Behavior:
There would be shadows on text displayed within the action bar.
Code Analysis:
Code analysis by haykam can be found in this comment.
![[Mod] tryashtar](../../../data/avatars/users/41963.png){kind=small}
The bug
The actionbar messages that appear when using /title actionbar do not obey the fadeIn, stay, and fadeOut parameters when specified with /title times like the normal titles and subtitles do.
How to reproduce
Run the following commands in order:
/title @a times 100 100 100
/title @a title {"text":"Hello world!"}
/title @a actionbar {"text":"Hello world!"}
Note: The large title fades in and out very slowly and stays plastered on the screen for the full duration, but the actionbar text instantly appears and fades out after a fixed time at a constant rate, disregarding the title times.
Code analysis
Code analysis by haykam can be found in this comment.
The bug
When you use the command /title @a reset or /title @a clear and you have a title in the actionbar slot, it does not reset/clear it.
Code analysis
Code analysis by haykam can be found in this comment.
The bug
When you simply click on input boxes in a certain order, the typing cursor shows for all the boxes. However, what you type will only go in the last box that you clicked.
Note: I get the impression that this happens when you first select a box "below" the next one.
How to reproduce
- Go to a place where there is more than one input box (for example in a structure block or in the "add multiplayer server" menu)
- Click on all the input boxes in several different orders
Examples
Here are some examples in videos:
- You can select multiple input boxes at the same time (1).mp4
- You can select multiple input boxes at the same time (2).mp4
Bug additions (Thanks Matolcsy Attila)
- The bug is only visual, you can still only edit one box a time
- Bug only appears when using mouse clicks, not while using Shift+Tab
- Bug only appears if Server Adress is selected first, not the other way
The Bug:
Drinking honey bottles increases "minecraft.used:minecraft.honey_bottle" by a value of two and runs the "minecraft:consume_item" advancement trigger twice.
Steps to Reproduce:
- Create a scoreboard objective for tracking the use of a honey bottle and set it to display on the sidebar by using the commands provided below.
/scoreboard objectives add UseHoneyBottle minecraft.used:minecraft.honey_bottle
/scoreboard objectives setdisplay sidebar UseHoneyBottle
- Obtain a honey bottle and drink it.
- Take note as to whether or not drinking honey bottles increases "minecraft.used:minecraft.honey_bottle" by a value of two and runs the "minecraft:consume_item" advancement trigger twice.
Observed Behavior:
"minecraft.used:minecraft.honey_bottle" increases by a value of two and the "minecraft:consume_item" advancement trigger runs twice.
Expected Behavior:
"minecraft.used:minecraft.honey_bottle" would be increased by a value of one and the "minecraft:consume_item" advancement trigger would only be run once.
Code Analysis:
Code analysis by haykam can be found in this comment.
Parrots are supposed to imitate piglin brutes, because they are hostile mobs. However, after testing, the parrots never made any piglin brute sounds.
What I expected to happen was...:
The parrots made high pitched piglin brute snorting, with the "Parrot snorts mightily" subtitle.
What actually happened was...:
The parrots did not imitate the piglin brute like they do to other hostile mobs.
Steps to Reproduce:
1. Have a piglin brute and some parrots
2. 
No parrots made any piglin brute sounds.
Code analysis
Code analysis by haykam can be found in this comment
![[Mod] j_p_smith](../../../data/avatars/users/92851.png){kind=small}
The bug
Horses being ridden by another player or entity can be saddled by right-clicking on them while holding a saddle. This is likely unintended as:
- opening/interacting with the inventory of a ridden horse is otherwise disabled for all players except the rider,
- this issue doesn't affect horse armour, and
- this issue doesn't affect llamas being equipped with carpets.
How to reproduce
- Summon a tamed horse ridden by an entity:
/summon horse ~ ~ ~ {Tame:1,Passengers:[{id:chicken}]} - Attempt to open the horse's inventory by right-clicking on it while sneaking
→
The horse's inventory cannot be accessed by you, as you are not the rider - Without sneaking, right-click on the horse while holding a saddle
→ The horse is equipped with the saddle
Code analysis
Code analysis by haykam can be found in this comment.
@haykam, this is about the packet ServerboundSelectTradePacket (1.16.3, Mojang name), correct?
And after the exception was logged by the server the connection is closed, right? Though the server-side validation of packets should probably be improved nonetheless.
The bug:
The entity is moved up ~0.05 blocks (established using carpets mod's tick freeze) and becomes stuck in the piston head. On versions 1.2.1-1.19.4, when the piston is retracted, the entity clips into the piston body and sinks through the cobweb.
Expected Result:
The piston to push the entity up a full block and the entity to sink through the cobweb.
Steps to Reproduce:
- Place piston, facing upwards
- Place rail on top of piston
- Place cobweb to the top and left of the piston
- Place minecraft on the rail and break the rail
- Nudge the minecart into the cobweb
- Ensure there are no block underneath the cobweb
- Power and de-power the piston (slowly)
See the video and photos for more information on how to setup this glitch.
Responses:
Now tested for all spawn egg mobs (in response to Marty Mcfly):
- Doesn't affect Spiders / Cave spiders, as these mobs are not slowed by cobwebs.
- Doesn't affect flying mobs (Bees, Bats, Ghasts, Phantoms) or mobs summoned with
/summon minecraft:creeper ~ ~ ~ {NoGravity:1b}
Now tested for short duration pulses (in response to Gnamf Jojo):
- Works for all pulses, down to 0-tick pulses (make sure there's no block under the cobweb)
Updates:
When a player is pushed within the cobweb, they are put into swim mode.
This glitch also affects Minecarts that are still on rails.
Code analysis
Code analysis by haykam can be found in this comment.
![[Mod] violine1101](../../../data/avatars/users/92858.png){kind=small}
@haykam: are you saying that you can't reproduce this anymore in 1.19.3-pre2? Or what do you mean otherwise?
The Bug:
Players can use water buckets and lava buckets on blocks that are out of reach.
Steps to Reproduce:
- Dig a hole that's three blocks deep.
- Obtain any block and a water bucket and switch to survival mode.
- Attempt to place the block at the very bottom of the hole and notice how you're unable to.
- Attempt to place the water bucket at the very bottom of the hole and notice how you're able to.
- Take note as to whether or not players can use water buckets and lava buckets on blocks that are out of reach.
Observed Behavior:
The reach distance of water/lava buckets is larger than the entity reach distance.
Expected Behavior:
The reach distance between blocks and water/lava buckets would be the same.
Code Analysis:
Code analysis by haykam can be found below.
The BucketItem#use method (Yarn mappings) calls the Item.raycast method, which raycasts a distance of 5 blocks, rather than the correct entity reach distance.
![[Mod] Jiingy](../../../data/avatars/users/91802.png){kind=small}
Sniffers digging into the ground does not account for the scale attribute, resulting in the sniffer being able to dig multiple blocks away from their own position, or dig far too close to their inner hitbox at larger scales.
Steps to Reproduce:
- Create a super flat world
- Summon/spawn a sniffer
- Scale it downward to 0.25
/attribute @e[type=minecraft:sniffer,limit=1] minecraft:scale base set 0.25
- Wait for it to sniff a block
Observed Behavior:
The sniffer will play the animation as expected, but the block they dig over (and the block that shows particles) will be upwards of 2-3 blocks away from themselves. The behavior when scaling the sniffer upwards will be that the sniffer digs central to it's hitbox, disregarding it's head position.
Expected Behavior:
The sniffer in all cases would dig where it's head enters the ground, underneath it's hitbox.
Screenshots/Videos:
Code Analysis:
(From haykam in this comment)
The SnifferEntity#getDigLocation method uses a constant value of 2.25 when calculating the magnitude of the vector from the entity's rotation and bottom-center position, which is proportional to the typical sniffer's dimensions. A scaled sniffer, however, does not scale this constant value. A proposed fix is to use the expression 2.25 * this.getScale() instead.
That's definitely fair haykam, just with the recent triage of other similar issues I decided to report this and see what Mojang thinks. If it's invalid or a feature request that's fine, and if not, the other behavior you've pointed out could also possibly be reported.
Scutes spawned from a baby turtle when they grow up will be positioned too high above the entity.
Steps to Reproduce:
- Tick freeze the game for observation:
/tick freeze
- Summon a turtle 1 tick away from growing up:
/summon minecraft:turtle ~ ~ ~ {NoAI:1b,Age:-1} - Advance the game by 1 tick
/tick step 1
Observed Behavior:
The scute will be positioned too high above the turtle entity.
Expected Result:
The scute would be positioned directly above the top of the turtle when it grows up, similar to other items created from entities by game events/interactions.
Screenshots/Videos:
Showcase of the scute item spawning compared to other items created by game events:
SpawnedItems.mp4
Notes:
I can also confirm that standing in an end crystal renders blaze fireballs completely useless, as haykam stated.
The Bug
Ominous item spawners can have a slow/choppy animation if the Time value in the level.dat file is over 16,777,216 ticks (~9.71 days in real-time).
The ominous item spawner becomes more jittery the higher the level time is, to the point where it stops animating completely. However, this takes much longer to achieve.
See this video for a demonstration of the bug.
How to Reproduce
- Generate a new world, or use an existing one, and play in it for approximately 9.71 days in real-time, or run /tick sprint 16777216 to speed up the process. Alternatively, use this world: MC-273758.zip
- Start an Ominous Trial by placing a Trial Spawner spawning any mob such as pigs, and drinking an Ominous Bottle near it in Survival mode.
- When you hear/see an ominous item spawner appearing, look closely at it.
- Note how the ominous item spawner's animation is broken due to the high-level time value.
Code Analysis / Possible Fix
Thanks to haykam for the explanation!
The bug starts occurring when the level time reaches 16,777,216 ticks (also 2^24), which is notably where floating-point numbers lose precision, due to the 32-bit single-precision floating-point as defined by the IEEE 754 standard. You cannot count by 1 in floats at that point, so the lerping of the angle fails.
The possibly relevant code for this issue is located in the OminousItemSpawnerEntityRenderer#render method. Source code of Minecraft 1.21 using Yarn mappings:
float j = MathHelper.wrapDegrees((float)(world.getTime() - 1L)) * 40.0F; float k = MathHelper.wrapDegrees((float)world.getTime()) * 40.0F;
A possible fix would be to get rid of the inner float cast and make wrap degrees for longs. That should get rid of precision issues because -180 to 180 is precise enough for this case, and a modulo of a long probably does not have overflow issues.
A fix could be something along the lines of:
// Assuming a MathHelper.wrapDegrees(long) now exists: float j = MathHelper.wrapDegrees(world.getTime() - 1L) * 40.0F; float k = MathHelper.wrapDegrees(world.getTime()) * 40.0F;
When an item is thrown on top of certain blocks such as honey or soul sand, it will abruptly lose all of it's velocity and fall straight towards the ground in an unexpected manner.
Steps to Reproduce:
- Create a strip of honey or soul sand on the ground (~3-5 blocks long)
- Aim the camera near 0.0, 0.0
- Throw an item along the strip of blocks
→ observe result - Throw an item on a ground made of a different block
→ observe result
Observed Behavior:
On the honey and soul sand, the block will stop mid-air and fall straight to the ground roughly 1-2 blocks away from the player.
Expected Result:
The item would either not be slowed yet because it is not actually on top of the block when thrown (and thus should not take it's properties), OR it would have it's velocity slowed down smoothly, rather than instantaneously.
Screenshots/Videos:
The issue occurring in a natural setting, such as a soul sand valley:
soul_sand_demonstration.mp4
The issue occurring in a controlled environment, compared to other kinds of blocks:
block_difference_demonstration.mp4
Notes:
MC-262317 is relevant to this report, and may be when the issue was first introduced per a comment by haykam here in the mojira discord
![[Mod] turbo](../../../data/avatars/users/92867.png){kind=small}
Can confirm in 24w45a.
This bug is related to this bug report too: MC-278182
It is crucial to fix this bug for proper, consistent behavior from item entities when moved by pistons
haykam's bug solution would be valid, as explained here: MC-278255
Furthermore, powder snow can cause the same bug too (1.17+ as the block was introduced back then)
The tags include `blocks`/`items` in their name when no other tag has this quirk. From a file path standpoint, it’s redundant: `data/tags/items/beacon_payment_items.json`.
Still an issue on 1.15.2 and 20w21a. This is caused by spawner mob setting logic being defined in SpawnEggItem rather than SpawnerBlock (Yarn names).
Can reproduce on 20w22a.
I disagree with this being a duplicate. The problem mainly lies in the fact that basalt generation isn’t dictated by something like fluid flow. Superflat generation is just one way to produce this bug, but simply having a non-updated row of basalt generators could cause this.
Here is a fix as a Fabric mod: https://github.com/haykam821/Empty-Tag-Fix
Seems to be caused by a reusable empty list used for empty tags, which causes IllegalArgumentException to be thrown as that same list can't be used for two entries
there/is/also/no/folder/there_is_no_file.json
There is no file.
No, it just would look like plants on a map
Yarn mappings
UNUSED_PLANT = new Material.Builder(MapColor.DARK_GREEN).destroyedByPiston().build();And is mined faster with a sword:
Code analysis
The sound event is specified and registered, with a proper sound associated with it:
However, unlike piglins, which can be imitated by parrots, piglin brutes are not added to the map of entity types to imitation sounds for parrots:
Because of this, the entity.parrot.imitate.piglin_brute sound event will never play.
Here is a mod with the aforementioned fix:
GitHub: https://github.com/haykam821/Brute-Imitation/releases/tag/1.0.0
CurseForge (when approved): https://www.curseforge.com/minecraft/mc-mods/brute-imitation/files/2997033
This issue is present in the game.
I can confirm this issue on Mac.
Is that name still wrong? While the spelling error was fixed, the correct name should still be 'lily pad'.
Can confirm in 1.19 release candidate 2. One line fix in the InGameHud class (Yarn mappings):
Code analysis using Yarn mappings:
The ParentElement#mouseClicked method iterates over children, returning early if a child handles a mouse click. Since text field widgets handle unfocusing within these clicks (TextFieldWidget#mouseClicked), if a prior child handles a mouse click successfully, then they will never get the chance to check for unfocusing. As a result, clicking a text field widget that's before another text field widget in the children list will not unfocus the latter text field widget.
A potential solution is to separate unfocusing clicking logic in a way that prevents it from being short-circuited.
This behavior still exists on 1.19.2. This issue should ideally be fixed because otherwise, mods cannot use conventional common tags for compatibility. For example, if one mod adds a steel chest but no mods adding steel ingots are present, the first mod's steel chest recipe intended to be steel ingots surrounding a chest would accept just the chest.
This issue still exists on snapshot 22w42a.
This issue still exists in 22w42a.
This issue still exists on snapshot 22w43a.
I suppose Mojang made this bug more inconsistent with a tooltip refactor. If this is marked as a duplicate, that report should be updated to generalize to all tooltips and include the tooltip not being visible when the mouse is not present.
This issue persists in 22w45a.
This issue exists in 22w45a.
This issue exists in 22w45a.
The first image is of the vanilla accessibility options screen. The modded screenshots show a custom tooltip implementation that respects tab focus and how 22w45a affects its tooltips.
This issue persists in 22w46a.
Code analysis (Yarn mappings)
One fix for this issue would be to move the CreativeInventoryScreen#mouseReleased method that implements the item group selection behavior to the CreativeInventoryScreen#mouseClicked method. A side effect would be that the item group would be changed when the mouse is first pressed, but that would be more consistent with other user interface elements.
The fix for this issue would be to simply move the CreativeInventoryScreen#mouseReleased (Yarn mappings) method into the CreativeInventoryScreen#mouseClicked method. Note that this is the same fix for MC-11739, since they are the same issue and I think one should duplicate the other.
Shouldn't this issue be fixed in 1.19.3 pre-release 2?
Fixed in 1.19.3 pre-release 3, as modifying light blocks requires creative mode and level two operator (LightBlock#onUse method in Yarn mappings)
Code analysis using Yarn mappings:
The codec stored in the AffineTransformation.field_42532 field does not have optional fields, so attempting to parse an incomplete transformation compound will result in an error being logged to the console instead.
Cannot reproduce in 23w07a by attaching a tamed wolf to a fence and relogging far away with the wolf still in render distance.
This issue still exists in Minecraft snapshot 23w07a.
Code analysis (Yarn mappings)
The InGameHud#setOverlayMessage method is called on the client when a packet is sent by /title for the action bar/overlay. This method sets the InGameHud#overlayRemaining field to 60 rather than the current value of InGameHud#titleStayTicks, which is 70 by default.
In general, the title and subtitle use a single InGameHud#titleRemainTicks field to calculate the transparency of the title and subtitle. However, the overlay uses the InGameHud#overlayRemaining field in addition to hardcoded values for calculating its transparency.
The recommended fix would be to extract the transparency calculation based on InGameHud#titleRemainTicks to its own method that can be reused with InGameHud#overlayRemaining for the overlay. However, the overlay would be shown for 70 ticks rather than the current 60. In addition, existing overlay messages would match the title and subtitle timings if not modified. If these potential issues are not ideal, then the three timing fields can be separated into three for the title and subtitle and three for the overlay, with the latter being adjusted to the current values. The command format would need to be changed to handle this separation as well.
This issue still exists in Minecraft snapshot 23w07a.
Code analysis (Yarn mappings)
The InGameHud#clearTitle and InGameHud#setDefaultTitleFade methods are responsible for the client portion of clearing/resetting functionality.
The former method clears the InGameHud#title, InGameHud#subtitle, and InGameHud#titleRemainTicks fields, but not the corresponding InGameHud#overlayMessage and InGameHud#overlayRemaining fields used for action bar/overlay messages.
Since there are no fields for overlay timing (MC-106167), they are not reset by the latter method. The existing timing fields that are reset are not used for overlay timing.
The recommended fix would be to clear the InGameHud#overlayMessage and InGameHud#overlayRemaining fields in the former method. Timings would require the recommended fix for MC-106167.
Code analysis (Yarn mappings)
The following code calculates the jukebox particle color:
For comparison, the following code calculates the note block particle color:
Math.pow(2, (note - 12) / 12d) / 24fAs a result, note blocks' particle color ranges from 0 to 0.04166666667 while jukeboxes' particle color ranges from 0 to 0.125. Also note that note blocks' particle colors have 24 steps while jukeboxes' particle colors have only 4 steps.
Duplicate of
MC-260427This issue is still present on Minecraft 1.19.4 pre-release 1. Note that it also affects camels as the mount entity and any non-player living entity passenger with the /ride command.
Code analysis (Yarn mappings)
The default travel behavior for a horse is overridden when it has a steering passenger as determined by the AbstractHorseEntity#getPrimaryPassenger method. This allows players to substitute a horse's travel behavior for their own movement.
However, the way the steering passenger is determined has a flaw. For reference, this is the entire method:
To summarize, the travel behavior will be overridden if a living entity is riding a saddled horse. This works for unsaddled horses, where the travel behavior is not overridden, and saddled horses ridden by players, where the travel behavior is substituted for the player's movement. This leaves the case where a saddled horse is ridden by a non-player living entity. In this case, the travel behavior will be overridden, but there is no substitute movement defined. As a result, the horse will not move.
One suggested fix is to simply reduce the steering player case to players when the horse is saddled:
This mixin implements such a change:
This issue still exists in Minecraft 1.19.4 pre-release 1. In addition, it affects all saddleable entities.
Code analysis (Yarn mappings)
Each implementation of the Saddleable#canBeSaddled method does not check the entity's passengers.
The suggested fix would be to check the Entity#hasPassengers method within each implementation of the Saddleable#canBeSaddled method. For example:
Code analysis (Yarn mappings)
Honey bottles are a custom item with a food component. The HoneyBottleItem class triggers the criterion in its implementation of the Item#finishUsing method:
However, the base implementation of the Item#finishUsing method already triggers the criterion for foods through the player's implementation of the LivingEntity#eatFood method:
One recommended fix is to simply remove the unnecessary criterion trigger from the HoneyBottleItem class.
This issue is still present on Minecraft 1.19.3 and Minecraft 1.19.4 pre-release 3.
Ignore that
Would player impact be that the focus indicated is quite confusing especially when managing to select multiple fields? In general, I just think it's an inconsistency bug.
This issue still occurs in 1.19.4 release candidate 1.
This issue still exists in Minecraft 1.19.4 release candidate 2.
This issue still exists in Minecraft 1.19.4 release candidate 2. Note that with changes to the create world screen, there are additional differences: the look is inconsistent and tabs cannot be selected using Cmd+1-9 keyboard shortcuts.
This issue is still present on Minecraft 1.19.4 release candidate 3. This issue also relates to
MC-29371as both result from the statistics screen using a custom tooltip implementation.I cannot reproduce this issue anymore on Minecraft 1.19.4 release candidate 3. It seems like the issue instead is that skeleton horses controlled by skeletons will only move after they have been hit for a short while.
This issue is still present on Minecraft 1.19.4 release candidate 3. The bottle put in one of the three lower slots should be a splash potion to brewed into a lingering potion by dragon's breath.
This issue still exists in Minecraft 1.19.4 release candidate 3.
This issue still exists in Minecraft 1.19.4 release candidate 3.
This issue still exists in Minecraft 1.19.4 release candidate 3.
This issue still exists in Minecraft 1.19.4 release candidate 3.
Cannot reproduce in Minecraft 1.19.4
Can reproduce in Minecraft 1.19.4. Note that the issue is easier to reproduce at low brightness settings.
Can confirm in Minecraft 1.19.4. It also affects powder snow (when moving horizontally) and sweet berry bushes.
Code analysis (Yarn mappings)
Cobwebs, powder snow, and sweet berry bushes use the Entity#slowMovement method as well to affect movement. This method sets a multiplier field which is used to multiply the movement distance when the Entity#move method is called. Typically, this allows a multiplier to be set for when the entity updates its position in the next tick.
However, additional movement can be applied from other sources, such as pistons and shulkers. In these cases, the movement multiplier affects the external source of movement rather than the entity's own movement.
To fix this issue, the Entity#move method should simply check the MovementType before applying the movement multiplier.
This issue still exists in Minecraft 1.19.4.
This issue still exists in Minecraft 1.19.4. The world border does not change color to match its status and players do not take damage until the game is unpaused.
This issue still exists in Minecraft 1.19.4.
This issue still exists on Minecraft 1.19.4.
This issue still exists in Minecraft 1.19.4. Note that this only applies to experience bottles and not thrown potions; possibly relevant is that the former has a gravity value (subtracted from vertical velocity when ticking) of 0.07 compared to the latter's 0.05.
This issue exists in Minecraft 1.19.4. Baby turtles have a height of 0.12 (30% scale factor from adult height of 0.4) which is just under the 0.125 height difference of soul sand.
This issue still exists in Minecraft 1.19.4.
Code analysis (Yarn mappings)
Bubble column effects (and in general other collision effects applied through an implementation of the Block#onEntityCollision method) apply to blocks in all positions that an entity's bounding box intersects, as per the Entity#checkBlockCollision method. As a result, by default, bubble column effects will apply to entities intersecting with the block position at all.
One fix for this issue would be to check the entity's relative Y position to the bubble column in the BubbleColumnBlock#onEntityCollision method.
This issue still exists in Minecraft 1.19.4.
This issue still exists in Minecraft 1.19.4.
Can reproduce
I cannot reproduce the issue of the painting not dropping as an item in Minecraft 1.19.4.
Is the arrow disappearing an issue? Arrow entities are removed when they hit another entity unless the arrow is shot from a piercing crossbow. Normal arrows disappear when hitting paintings, as expected, and piercing arrows are embedded in the block the painting is placed on, also as expected.
This issue still exists in Minecraft 1.19.4.
This issue still exists in Minecraft 1.19.4.
This behavior still exists in Minecraft 1.19.4.
This behavior still exists in Minecraft 1.19.4.
This behavior still exists in Minecraft 1.19.4. Note that some entities with associated inventories such as chest boats and chest minecarts show the crosshair.
This behavior still exists in Minecraft 1.19.4 and affects llamas as well.
This behavior still exists in Minecraft snapshot 23w14a.
This behavior still exists in Minecraft snapshot 23w14a.
This behavior still exists in Minecraft snapshot 23w14a.
This behavior still exists in Minecraft snapshot 23w14a.
This behavior still exists in Minecraft snapshot 23w14a.
This behavior still exists in Minecraft snapshot 23w14a.
This issue still exists in Minecraft snapshot 23w14a.
This issue still exists in Minecraft 1.20.1. The updated command is:
/setblock ~ ~ ~ minecraft:spawner{SpawnData:{entity:{id:"minecraft:zombie",Fire:12s}}}I can reproduce this issue on 1.20.1 and 23w33a. Note that it affects all text fields.
This issue still exists in Minecraft 23w33a.
Narrator is already capitalized within accessibility onboarding within the translation for accessibility.onboarding.screen.title:
I would personally expect a feature that uses title case to consistently use title case anywhere it is mentioned.
(There also is accessibility.onboarding.screen.narrator with "Press enter to enable the narrator," but capitalization isn't spoken...)
This behavior still exists in Minecraft 1.20.1 and Minecraft 1.20.2 pre-release 1.
I can no longer reproduce this issue. This issue seems to have been fixed between Minecraft 1.20.1 and Minecraft 1.20.2 pre-release 1.
This behavior still exists in Minecraft 1.20.2 pre-release 1.
This issue still exists in Minecraft 1.20.2 pre-release 1.
This issue seems to be related to GLFW issue #2377. Minecraft 1.20.2 updated the LWJGL library from 3.3.1 to 3.3.2, which updated the GLFW library from 3.3.6 to 3.3.8. Therefore, the bug seems to have been introduced here.
The bug seems to occur on all quadrants of the window except for the top-left quadrant. Does the issue still happen on a non-scaled screen, perhaps? The display settings should allow switching to a resolution that is double the scaled Retina resolution.
Upon further investigation, the difference between Minecraft 1.20.1 and 1.20.2 (and thus GLFW 3.3.6 and 3.3.8) is that the fullscreen option in video settings uses the style mask 0b0100 in 1.20.1, but 0b1100 in 1.20.2. The enabled bit corresponds to .resizable. This GLFW commit seems to have caused this behavior by causing the resizable bit to not be cleared when entering fullscreen.
My speculation is that the resizable bit is typically not set while in full screen, and older versions of macOS interpreted resizing incorrectly for that unique case. While I believe GLFW would have to clear this bit within _glfwSetWindowMonitorCocoa, Minecraft could possibly clear/reapply the resizable bit on its own after its own glfwSetWindowMonitor calls to fix the issue without requiring a GLFW update.
Edit: I misinterpreted what bit 0b1000 corresponds to; it should be .resizable, not .miniaturizable.
This issue and
MC-260889are caused by the same code path. The BucketItem#use method (Yarn mappings) calls the Item.raycast method, which raycasts a distance of 5 blocks, rather than the correct entity reach distance.The steps to reproduce are to write a web server that returns a Content-Length: 0 header and point the server resource pack URL to it. The exact resource pack used doesn't matter since the issue is in the headers, not arbitrary data that may or may not be exist or associated with any file.
The equals and keypad equals keys both appear as = for me, though when binding each of the two keys, the binds do not conflict with each other as two binds of the same key would. The binds are saved as key.keyboard.equal and key.keyboard.keypad.equal respectively.
This issue also affects placing wolf armor onto wolves and shearing wolf armor off of wolves in Minecraft 23w51b.
I can also reproduce using Minecraft 23w51b. Because the exit end portal generates at the floor of the world, the end portal blocks are placed outside of the world bounds, making leaving the dimension without dying impossible.
I can also confirm this issue.
Code analysis (Yarn mappings)
The SlimeEntity#getBaseDimensions method was updated in Minecraft snapshot 24w03a to not scale the entity's dimensions by 0.255 dynamically. Instead, the slime entity type's static dimensions were adjusted to get an equivalent result; the 2.04 width and 2.04 height dimensions scaled by 0.255 are now simply 0.52 width and 0.52 height. Magma cubes inherit the dynamic scaling by inheriting the SlimeEntity#getBaseDimensions method, but the magma cube entity type does not inherit dimensions from the slime entity type. The end result is that magma cubes still have the original 2.04 width and 2.04 height dimensions, but these dimensions are not scaled dynamically to create the correct dimensions as was the case previously.
The solution is simply to change the dimensions of the magma cube entity type:
Note that the scaling change results in slightly different dimensions being computed in the end. The original dimensions were computed as 2.04 * 0.255, resulting in 0.5202, while the new dimensions are 0.52, meaning slimes are now 0.0002 smaller on all axes. This is possibly a parity difference with Bedrock Edition.
Can reproduce in Minecraft snapshot 24w03b. The game freezes rather than crashing.
Code analysis (Yarn mappings)
A piercing arrow will continuously check for entities to pierce through in a loop within the same tick. To prevent the same entity from being collided with twice, pierced entities are stored in the PersistentProjectileEntity#piercedEntities set and ignored by collision detection.
Projectile deflection prevents the code that mutates the pierced entities set from executing:
Therefore, the arrow will continuously attempt to collide with the same entity over and over and get deflected; an infinite loop occurs.
A fix would be to move the deflection behavior either past the pierced entities update code or to stop checking for further collisions after deflection occurs. The core way to prevent the infinite loop is to exit the while loop in some way.
I can't reproduce shooting arrows from a bow in spectator mode (although the FOV effect persists). Tridents can still be thrown after changing to spectator mode.
This issue still exists in Minecraft snapshot 24w07a. Note that the issue is easier to reproduce when increasing the tick rate.
I think this is likely intended, since you could already use /give @s diamond_pickaxe{Damage:15432} in previous versions, even when Mojang fixed the rendering of the durability bar for negative durability values.
This seems like a feature request. As with all status effects, hero of the village is removed upon death or activation with a totem of undying.
This issue still exists in Minecraft 1.20.4.
This issue also affects Minecraft snapshot 24w09a.
Code analysis (Yarn mappings)
I believe this issue to be caused by other code (in inventory management methods) mutating the stack and clearing it, causing the stack shown in the animation to become empty and display as a hand instead.
The following is a simplified version of events that I believe to occur during the swap:
1. Player clicks the slot to pick up the item
2. A new copy of the stack becomes the cursor stack, while the previous stack becomes an empty stack
3. The previous stack remains referenced by the held item renderer
4. On future renders, since the stack is now empty, a hand is rendered instead
I believe the correct solution is to maintain a copy of the hand stack so that mutations from unrelated systems like inventory do not interfere with the stack used for the swapping animation. In previous versions, such a change might have resulted in performance issues (or at minimum, might have removed premature optimization in avoiding checking value equality of NBT often), but I doubt the situation is the same today. After all, several systems already perform value equality checks against a copied stack, such as updating the armor of an entity that a player is watching. Item stack components introduced in Minecraft snapshot 24w09a may have better value equality check performance as well, though I'm not sure on that matter.
In short: within the HeldItemRenderer#updateHeldItems method, remove the ItemStack.areEqual checks that allow reference equality to be used more often, and copy the stacks when updating them during the midpoint of the animation.
This behavior seems to exist in Minecraft 1.20.4 despite the TNT entity supporting custom block states.
This behavior likely works as intended; when unstable TNT (when it was the regular TNT!) was added to the game, it was described as 'Hit them for maximum fun', suggesting that the block needs to be touched by a player's hands to be primed. (Beehives and decorated pots have similar on-break properties which are likely also affected in the same way).
Do you know if there are any other pickup delay bugs? Unfortunately I can't find any other than ones that specifically include the term 'pickup delay'.
For what it's worth, here are the other possible sources of no pickup delay that I haven't confirmed:
If there aren't duplicates/WAI resolutions on these, then I will report them.
Could you show the NBT of the villagers? (/data get entity @e[type=villager,sort=nearest,limit=1])
I can reproduce in Minecraft snapshot 24w11a. The buttons can be focused, but get quickly unfocused afterwards, so while it's technically possible to navigate the book UI with the keyboard by quickly pressing the navigation keys and activating the correct button, this workaround is clearly not ideal.
This also affects narration.
This issue likely duplicates
MC-268556.This behavior is a bit odd since the new component format still supports spawn eggs that spawn different entity types: /give @s husk_spawn_egg[entity_data=\{id:llama\}].
The durability could be split only when splitting the stacks rather than when the item is first damaged as well.
I can reproduce this issue.
Deja vu
Is the recipe loading and just not working, or is there an error during loading that prevents the recipe from working?
I can reproduce this issue on Minecraft snapshot 24w12a.
I can also confirm. Mushroom stew is also affected in addition to the other 3 soups and stews mentioned in this issue.
You need to enable experimental features when creating a new world to obtain the update 1.21 content. You do have non-experimental content such as wolf armor in that world, though.
This issue seems to duplicate
MC-269684.This issue still exists in Minecraft snapshot 24w12a. A new command to reproduce the issue is: /give @s shulker_box[container=[\{item:{id:dirt,components:\{rarity:epic}},slot:0}],rarity=epic]
I believe this issue is a duplicate, since all three cases mentioned in this issue are already covered by MC-109087.
Since some of these text elements now display above a panorama, which should be a fluctuating background per the criteria, as of Minecraft 1.20.5's UI changes, should this issue's resolution be re-evaluated?
This issue seems like a duplicate of
MC-269352As of Minecraft 1.20.5 pre-release 1, area effect clouds now use the standard particles with the correct color, which seems to be correct behavior as these are the same particles used for the corresponding splash potion.
This issue seems intended. There are two formats (see the 24w09a changelog):
You're trying to put the show in tooltip option on the predicate itself through the single predicate format, but the show in tooltip option is only available on the full component format.
This issue did get fixed as the operations were renamed to add_value, add_multiplied_base, and add_multiplied_total.
I cannot reproduce this issue in Minecraft 1.20.5 pre-release 1.
I cannot reproduce this issue in Minecraft 1.20.5 pre-release 1.
This seems to be caused by the fix for
MC-270236.I cannot reproduce this issue in Minecraft 1.20.5.
I cannot reproduce this issue in 1.20.6 release candidate 1 with the update 1.21 experiment not enabled.
Would it be possible to upload the world with the issue?
This issue would be invalid anyways because the environment is modified. This seems like a duplicate of
MC-249136, meaning the issue is fixed in Minecraft 1.20.5.Should an enderman's block, an iron golem's flower, a player's pumpkin head, or a minecart's block be independently texturable? Mooshrooms include the mushroom block models as part of a feature renderer, so they aren't part of the entity model itself.
This seems like it became a duplicate of
MC-271843since that got triaged by Mojang despite being created later.Based on code analysis, this change seems to have been introduced in 24w10a, where code was specifically added to the WolfEntity#createChild method (Yarn mappings) to handle this behavior. That snapshot also introduced wolf variants, which similarly are inherited from either parent. Note that this code is copied from the similar CatEntity#createChild method, which also has collar inheritance.
I can reproduce this issue, if I'm understanding it correctly.
Ignoring commands, the empty firework star is typically only obtainable in the creative inventory, and adding it to a firework rocket results in a firework rocket that fizzes out (also only obtainable in the creative inventory). However, if crafted with dyes to gain fade colors, this firework star gains an implied small ball explosion, with no color specified. However, this explosion will still work with a default color of black. The explosion having a color is contradictory to the firework star's overlay texture not being tinted.
To me, it seems like the ability to craft a firework star without an explosion into one with an explosion is a bug. In other words, the firework star's explosion's fade colors shouldn't be modifiable because there is no explosion.
As an aside: there appears to be a datafixer issue regarding the default black color getting added to firework explosions going from Minecraft 1.20.4 to 1.20.5.
Can reproduce as well, but the actual effect seems inconsistent. For example, the crafter could craft sticks from 2 bamboo items placed both vertically and horizontally as opposed to just vertically. However, the craft could not craft purpur pillars from 2 purpur slabs in either orientation. The crafting table works as expected.
This issue still exists in Minecraft snapshot 24w19b.
Well, I always think that tag exists only to find it doesn't when I go to use it. Having that tag would help to fix MC-232359 as well.
On Bedrock Edition, the armadillo's scutes spawn at the vertical top of the armadillo, so there is at least a parity difference with this behavior.
Code analysis (Yarn mappings)
The turtle scute dropping behavior is implemented in the TurtleEntity#onGrowUp method:
As indicated by the integer literal 1, the item entity will be spawned 1 block above the Y position of the turtle's feet. Note that turtles are 0.4 blocks high and baby turtles are 0.12 blocks high, so this offset is far away from the turtle.
Because a hardcoded offset is used, this also means that the turtle's scale attribute will not affect the item entity's position.
Cannot reproduce in Minecraft snapshot 24w21b.
This issue still exists in Minecraft snapshot 24w21b. The crosshair indicating a screen handler for spectators is missing for blocked chests.
This issue still exists in Minecraft snapshot 24w21b.
This issue still exists in Minecraft snapshot 24w21b, with the following command:
/give @s minecraft:firework_rocket[fireworks={flight_duration:255}]The underscore is also likely intentional. Keep in mind that both the minecraft:aztec and minecraft:aztec2 painting variants' names are translated as de_aztec, which also includes an underscore.
I can confirm this issue.
Code analysis (Yarn mappings)
The StructureTemplateManager class contains a STRUCTURES_DIRECTORY constant, which was changed from structures to structure in Minecraft snapshot 24w21a. This affected loading from both resources (data packs) and files, as presumably this constant is used in all usages of structure in the rest of the class.
[Mod] tryashtar already pointed this out, but to apply the Gist to this specific case, use this definition instead:
{ "comparator_output": 0, "description": { "text": "Test" }, "length_in_seconds": 10.0, "sound_event": { "sound_id": "bug:test" } }This issue still exists in Minecraft snapshot 24w21b.
The format was changed. The correct translation key is now jukebox_song.minecraft.pigstep.
That screen doesn't have an entry list, so to me, it makes sense that there is no dark background layering. It's closer to the 'Credits and Attribution' screen than the screen containing server links, which is scrollable and has the dark background.
I cannot reproduce this issue in Minecraft snapshot 24w21b.
Code analysis (Yarn mappings)
In the data generator for block loot tables (the VanillaBlockLootTableGenerator class), the loot table for the crafter is generated with the following line:
this.addDrop(Blocks.CRAFTER);However, since the crafter is a nameable container (having a block entity with a LockableContainerBlockEntity superclass), the crafter should instead be specified with the following line, matching other nameable containers:
Note that the implementation of this change was by replacing the DoorBlock#getHinge method's otherState.isOf(this) check with otherState.getBlock() instanceof DoorBlock.
I can confirm this issue in Minecraft snapshot 24w21b.
Code analysis (Yarn mappings)
The name for the item entity is determined using the following code:
In other words, the item entity prioritizes the custom name (specified using CustomName NBT) and falls back to stack-aware default name of the item. To support the custom name and item name components, the ItemStack#getName method could be used:
This issue still exists in Minecraft snapshot 24w21b. Note that due to the fix for
MC-271911, a minecraft:air tag now exists for the three types of air. This issue could be fixed by including that tag within the minecraft:parrots_spawnable_on tag.There was no corresponding NBT format for food components with default values. Even if there was, the default values were only part of the componentization datafixer, so fields like the color field of the banner patterns component are required despite the fix for
MC-271159.This seems like a duplicate of
MC-272550.This issue still exists in Minecraft 1.21 pre-release 1.
Code analysis (Yarn mappings)
The EyeOfEnderEntity#targetX, EyeOfEnderEntity#targetY, EyeOfEnderEntity#targetZ, EyeOfEnderEntity#lifespan, and EyeOfEnderEntity#dropsItem fields are not managed by the EyeOfEnderEntity#readCustomDataFromNbt or EyeOfEnderEntity#writeCustomDataToNbt methods. On the other hand, the the value of the EyeOfEnderEntity#ITEM tracked data is. As a result, the former fields are not saved to or read from disk, causing their values to be the Java defaults when the entity is reconstructed.
I can confirm this issue in Minecraft 1.21 pre-release 1. It affects the componentization, so this issue can be reproduced without editing the NBT of an entity.
The entity's item stack will always reset to the default stack of the given entity's default item as a fallback, as the item stack format itself has changed.
Steps to reproduce
1. Create a world in Minecraft 1.20.4
2. Create a bubble column using soul sand and water
3. Obtain an enchanted snowball item using creative mode and an anvil
4. Throw the snowball into the bubble column vertically so that it stays in stasis
5. Observe that the snowball visibly has an enchantment glint
6. Load this world in Minecraft 1.20.5 or later
7. Observe that the snowball no longer has an enchantment glint
Note that the use of a bubble column is optional, but helps with reproducing as otherwise, the snowball would move and disappear quite quickly.
The command /data get entity @e[type=snowball,limit=1,sort=nearest] Item shows the new NBT of the entity's item stack.
Your song should be mono audio rather than stereo. I don't believe the limitation is a bug; the sound system has always worked this way.
I can confirm this issue with Minecraft 1.21 pre-release 1. The difficulty also defaults to Normal on the world creation screen despite being Peaceful when initializing the worlds.
In Minecraft 1.21 pre-release 1, all biomes with zombie and zombie villager spawns have a 19:1 weight ratio (effectively meaning 5% of all zombie spawns are zombie villagers). However, zombies spawn in packs of four, while zombie villagers spawn alone. In addition, husks and strays (drowned replace the normal zombie spawns) have a much higher weight in their respective biomes.
Could an example of a data pack that produces this issue be uploaded? The GitHub link is broken.
The default air, water, lava, and barrier states all fall back to the default air state (which I think is a separate bug), which is an acacia button. I imagine the issue here is that you're specifying an invalid block state, which falls back to the default value for the field rather than failing to parse the entire carver configuration.
Can confirm; the issue isn't specific to boats but to any leashable entity.
The following command reproduces the issue:
/summon minecraft:cow ~ ~ ~ {leash: {UUID:[I; 0, 0, 0, 0]}}I cannot reproduce. Did you turn the doMobSpawning game rule off, perhaps?
I can confirm this issue. The issue is a bow or crossbow enchanted with multishot running out of durability, so the following bow will reproduce the issue in survival mode after one use:
/give @s crossbow[damage=464,enchantments={multishot:1}]Code analysis (Yarn mappings)
In RangedWeaponItem#shootAll, the weapon stack is damaged per each projectile entity created. Each projectile entity is created with a copy of the weapon stack, so if the weapon stack breaks between creating entities, the entities after the weapon stack breaks will have an empty stack. This stack isn't supported by NBT serialization of the projectile entity, so the game crashes.
The fix for this issue seems to have been to change the generated structures directory back to structures. The structures created in Minecraft snapshots 24w21a and 24w21b will stay in the structure directory, so while less impactful, the lack of upgrade path has essentially been flipped.
I can confirm this issue in Minecraft 1.21 pre-release 1.
Code analysis (Yarn mappings)
The following code in the ZoglinEntity class manages the babiness of zoglins:
Notice that the zoglin becomes a baby if the IsBaby field within entity NBT is true. There is no behavior for making the zoglin not a baby if the IsBaby field is false.
Compare to the same methods in other entities with a boolean babiness status (zombies and piglins), where the IsBaby field controls babiness regardless of being true or false:
I can confirm this issue in Minecraft 1.21 pre-release 1. Only copper bulbs and copper grates are affected, as copper doors and trapdoors now use ingots in their recipe which cannot be pre-waxed.
I cannot reproduce. Do you have any resource packs installed? It seems like banner patterns for you are opaque with a black background rather than transparent, as shown by the skull charge button in the loom.
I cannot reproduce this issue in Minecraft 1.21 pre-release 1. I imagine the fix version is 24w18a as that is when painting variants became a dynamic registry, but that is not confirmed.
I can confirm this issue in Minecraft 1.21 pre-release 1.
This issue still exists in Minecraft 1.21 pre-release 1.
I think this is a duplicate ofMC-272585; your weapon stack broke, and that incorrectly affected the weapon stack of the projectile entity. In this case, the weapon and projectile are the trident.On further investigation, tridents use a different code path than bows and crossbows, so this is a related but separate issue from
MC-272585. The trident stack is damaged, then a copy of the damaged stack (which can be empty if the trident breaks) becomes the trident entity's weapon stack. LikeMC-272585, the crash occurs when the projectile entity attempts to serialize an empty stack, which is not allowed by the ItemStack#encode method (this serialization uses the same code path as the bow issue).Cannot reproduce:
/setblock ~ ~ ~ minecraft:end_gateway{exit_portal: [I; 0, 0, 0]}I can confirm this issue. Did it first appear in 24w21a? From code analysis (Yarn mappings), I see what seems to be a related change that isn't the cause of the issue.
The scaling of the particle was changed within the ElderGuardianAppearanceParticle#buildGeometry method in Minecraft snapshot 24w21a:
Adding autocompletion to additional arguments or parts of arguments seems like a feature request as well to me.
This issue seems to duplicate
MC-272378. The format change is documented in the comments of that issue.This issue seems to be a duplicate of
MC-272378, which has the format change documented in the comments.I can confirm this issue and that standing inside a end crystal is good counterplay against blazes.
Relates to
MC-255218; since that issue was fixed, could this behavior be working as intended?I cannot reproduce. What is your graphics hardware and video settings? Do you have any resource packs enabled?
This issue still exists in Minecraft 1.21. Would adding frosted ice to the minecraft:mineable/pickaxe block tag solve this issue, perhaps?
If this issue is considered valid, I wonder what other issues with prototype entity names would be considered valid. The 'sentry', 'mage', and 'warrior' structure metadata comes to mind although those names aren't exactly user-facing.
I believe the vanilla Minecraft launcher will try to install the target version of Microsoft's Java distribution for each version. Is that not the correct behavior? Having a newer version of Java than intended can cause some issues, such as dates in the world list showing a missing font glyph at one point due to a newer Java version changing out the whitespace character.
Could
MC-272540be added as a linked issue so that all instances of a specific registry not being reloadable are in the same forest?Note that this behavior is shared across dynamic registries (with the notable legacy exception of loot tables). I believe there are more similar issues and possibly ones relating to this registry specifically, but some I found are:
MC-272540(enchantments, WAI) andMC-260452(damage types, triaged as normal priority). The latter connects to a forest of other reloadable registry issues.Wouldn't the full blocks blocking hoppers change also impact this issue? Note that loot tables drop 1.2 blocks above the bottom center of the trial spawner, which would be outside the range of the hopper anyways.
This issue still exists in Minecraft 1.21.
There seems to be a Fabric mod which implements a fix for this bug: Disconnect Packet Fix
This also affects the minecraft:noise_threshold_provider block state provider's low_states and high_states fields, though the code paths are unrelated.
Code analysis (Yarn mappings)
These issues come from unchecked list sizes in the NoiseBlockStateProvider#getStateAtValue and NoiseThresholdBlockStateProvider#get methods.
The fix is the same for both: replacing the Codec.list(BlockState.CODEC) fields with Codecs.nonEmptyList(BlockState.CODEC). This is the same approach that, for example, world generation features take.
I can confirm this issue in Minecraft 1.21 for everything except wind charges, which have a specific sound (minecraft:entity.wind_charge.throw sound event with subtitle "Wind Charge flies").
Code analysis (Yarn mappings)
The SnifferEntity#getDigLocation method uses a constant value of 2.25 when calculating the magnitude of the vector from the entity's rotation and bottom-center position, which is proportional to the typical sniffer's dimensions. A scaled sniffer, however, does not scale this constant value. A proposed fix is to use the expression 2.25 * this.getScale() instead.
I believe this issue relates to MC-120507 as both involve the given item being considered part of the game for one tick.
I can confirm this bug in Minecraft snapshot 24w33a. The enchantment reappears when picked up in the picking up item particle and in the inventory.
I can confirm this issue as well
This issue seems to be a duplicate of
MC-275273, which is marked as confirmed already; the video here is helpful though.I can confirm this issue. I would recommend uploading the network protocol error so that it can be easily read and deobfuscated.