jacobsjo

The customized.zip datapack does not specify the cloud_height field in the overworld dimension type, that was added in 25w15a. It appears intended that a dimension doesn’t have clouds when that field is not specified.

Can confirm. As comparison, the spawn weights of wolfs in other biomes:

• Snowy Taiga: 8 / 60 = 13.3%

• Old Growth Pine Taiga: 8 / 60 = 13.3%

• Old Growth Spruce Taiga: 8 / 60 = 13.3%

• Taiga: 8 / 60 = 13.3%

• Spare Jungle: 8 / 58 = 13.8%

• Grove: 1 / 13 = 7.7%

• Savanna Plateau: 8 / 68 = 11.7%

• Forest: 5 / 45 = 11.1%

• Wooded badlands (1.21.4): 2 / 8 = 25%

• Wooded badlands (now): 2 / 48 = 4.2%

The selection chance of wolfs in wooded badlands used to be the highest of all biomes and is now the lowest of all biomes. It seems likely that this was an oversight when adding the other passive mobs to that biome.

I've attached a datapack containing a total of 8 gametests testing that saddled horses, camels, pigs, and striders drop their saddles with both doMobLoot enabled and disabled. The tests with doMobLoot disabled fail.

I have verified that this datapack does still work in 24w46a. I've attached a video with a demonstration.

Code analysis by @ErrorCraft (text slightly edited by me, and translated mappings from yarn to official):

In ServerPlayer::changeDimension (which is used even when the dimension is not changed) it first sets the Player's position via Entity::teleportSetPosition by resolving it. So a y position of -60.0 with a teleport command with ~10 will set the player's position to -50.0. It then calls the ServerGamePacketListenerImpl::teleport method, which coincidentally calls these same methods! However, since it uses the Player's position, it now uses -50.0 instead of the expected -60.0! So the final y coordinate is -40.0, rather than -50.0, because it applies the offset a second time. However, on the client the player gets moved -50.0, so this actually causes a desync.

Now... What causes it to go back to its original position after executing the command a second time? The Player's y coordinate is now -40.0 and we want to teleport 10 blocks upwards from -60.0, which is -50.0. It calculates the position by subtracting the entity's position from the calculated position. This results in the following calculation: -50.0 - -40.0 which equals -10.0, the exact opposite of what we wanted, which causes it to teleport the Player 10 blocks down twice as described before.

Because this happens in the changeDimension override in ServerPlayer, it means that the issue only affects Players, which is something we can observe too if we try it out on another entity like a Pig; The Pig's position is set correctly.

This issue (or two, though one causes the other) is fixed by removing the Entity::teleportSetPosition call in the ServerPlayer::changeDimension method.

To reproduce the desync issue, just go in Survival mode and invoke the /teleport ~ ~10 ~ command while standing still and observe the fall damage. Then compare to the damage taken by falling from 20 blocks high. Falling from 10 blocks the fall damage is less.

This affects other types of tags too. It appears to affect all tags of registries whose entries are controlled through datapacks. Specifically, I've tested tags/worldgen/structure, tags/enchantment, and tags/loot_table.

Other tags are working as expected. Specifically, I've tested tags/block.

This bug was fixed in 24w35a

Can confirm.

This even happens when the block_interaction is set such that the block is destroyed (probably because the knockback is calculated first).

Apparently this bug first appeared in 24w21a and didn't happen in earlier snapshots.

I can confirm the behavior described using the attached datapack in 24w19b. The attached datapack uses separate enchantments for each armor piece but the same UUID for all attribute modifiers. So this behavior is probably WAI.

This was fixed in 1.20.5 pre 4.

Can confirm, also happens when the difficulty is set to peaceful.

Duplicate of MC-269978

Can confirm. Easier reproduction:

1. place a husk spawner from a trial chamber using:

/place template minecraft:trial_chambers/spawner/melee/husk

3. Use Ctrl + Pickblock on the trial spawner and place it elsewhere

2. go into survival mode and verify that the original spawner can spawn 3 husks simultaneously
4. ❌ The manually placed spawner can only spawn 2 husks simultaneously (the default value)

can confirm. The following command should summon an ominous item spawner that takes 2000 ticks to spawn the arrow, but instead spawns it immediately:

/summon minecraft:ominous_item_spawner ~ ~4 ~ {item: {id:"minecraft:arrow"} , spawn_item_after_ticks: 2000L}

can confirm. Command to give yourself a sword without any tool rules:
/give @s minecraft:diamond_sword[minecraft:tool={rules:[]}]

The same thing happens when the "minecraft:tool" component is completely removed using:
/item modify entity @s weapon {function:set_components, components: {"!minecraft:tool":}}

duplicate of MC-269644

Confirmed in 1.20.2, also affects the LIST_CODEC that uses RegistryCodecs.homogeneousList instead of RegistryFileCodec.

Fixed in 1.18 Pre-release 2. No reopen necessary anymore. (Fossils are now supposed to be used with a in_square placement modifier)

@PotholedSea40 No, this was fixed in 1.18 Pre-release 1. What you are reporting is not caused by missing biome definitions (it is not at PV: Peak). What you are seeing is MC-237243 and MC-236796 - both resolved as WAI.