mirror of
https://github.com/FabricMC/fabric.git
synced 2024-11-29 02:56:12 -05:00
87855a703c
* Fixed blocks with vanilla loot tables making strict validation of datagen fail Previously, blocks that used `.dropsLike(block)` in their block settings to use a vanilla block's loot table, or `.dropsNothing()` to use the `minecraft:empty` loot table, would cause strict validation in data generation to fail as the vanilla loot tables wouldn't be present in the mod's own block loot table generator. This fixes that by ensuring that the block's loot table ID has a namespace that matches the loot table generator before adding it to the missing IDs list. Two test blocks were added to the testmod, one which uses `.dropsLike(Blocks.STONE)` to use the same loot table as Stone, and one that uses `.dropsNothing()`. Previously, these would have caused strict validation to fail as the `minecraft:stone` and `minecraft:empty` loot tables aren't generated by the testmod's generator. Now they pass just fine. * Fixed blocks with vanilla loot tables making strict validation of datagen fail Previously, blocks that used `.dropsLike(block)` in their block settings to use a vanilla block's loot table, or `.dropsNothing()` to use the `minecraft:empty` loot table, would cause strict validation in data generation to fail as the vanilla loot tables wouldn't be present in the mod's own block loot table generator. This fixes that by ensuring that the block's loot table ID has a namespace that matches the loot table generator before adding it to the missing IDs list. Two test blocks were added to the testmod, one which uses `.dropsLike(Blocks.STONE)` to use the same loot table as Stone, and one that uses `.dropsNothing()`. Previously, these would have caused strict validation to fail as the `minecraft:stone` and `minecraft:empty` loot tables aren't generated by the testmod's generator. Now they pass just fine. |
||
|---|---|---|
| .. | ||
| client | ||
| main | ||
| testmod | ||