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.
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.
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.
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":}}
@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.
1.18 Pre-release 1 added an in_square placement modifier. However this simply caused MC-241234. If (in a datapack), this placement modifier is not used, the fossil feature still does it's own placement inside the chunk, but is still unable to generate in the far east or south blocks of the chunk.
I've attached an updated Datapack to confirm this. This datapack generated two different fossil features in two layers.
The bottom layer around Y=-30 generates fossils of size 15x15 to show the same issue still exists
[media]
The top layer around Y=30 generates fossils of size 10x10, to show that this isn't simply the case because of the missing in_square placement modifier.
This bug occurs because the game tries (and fails) to load the outdated multi noise configuration saved in the level.dat file even though that configuration would be overridden by the new datapack immediately afterwards.
I would like to clarify, that a fix for this bug does not require the multi noise configuration saved with the world to be upgraded. It is sufficient if the upgraded world is reverted to the default 1.18 multi noise configuration.
The customized.zip datapack does not specify the
cloud_heightfield 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.
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, andtags/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_interactionis 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. 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.homogeneousListinstead ofRegistryFileCodec.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.
Not fixed in 1.18 Pre-release 1.
1.18 Pre-release 1 added an in_square placement modifier. However this simply caused MC-241234. If (in a datapack), this placement modifier is not used, the fossil feature still does it's own placement inside the chunk, but is still unable to generate in the far east or south blocks of the chunk.
I've attached an updated Datapack to confirm this. This datapack generated two different fossil features in two layers.
The bottom layer around Y=-30 generates fossils of size 15x15 to show the same issue still exists
The top layer around Y=30 generates fossils of size 10x10, to show that this isn't simply the case because of the missing in_square placement modifier.
This bug occurs because the game tries (and fails) to load the outdated multi noise configuration saved in the level.dat file even though that configuration would be overridden by the new datapack immediately afterwards.
I would like to clarify, that a fix for this bug does not require the multi noise configuration saved with the world to be upgraded. It is sufficient if the upgraded world is reverted to the default 1.18 multi noise configuration.
Also happens in worlds first generated in early alpha versions.
From my comment from the duplicate report:
Steps to Reproduce:
Load Minecraft Alpha 1.0.4 and create a world
Upgrade to Minecraft Beta 1.6.6 and load the world
Upgrade to Minecraft 1.6.4 and load the world
Upgrade to Minecraft 21w44a and load the world
Use "Open to LAN" to enable cheats
Go to spectator mode and fly downwards below y=0
You may also use different versions but I believe this is the minimum amount of conversions needed.