# Breaking changes
- `VillagerPlantableRegistry` replaced with `ItemTags.VILLAGER_PLANTABLE_SEEDS`
- `FabricItemGroup.builder()` no longer takes an `Identifier`
- `FabricItemGroup.build()` no longer registers the ItemGroup, this now needs to go in the vanilla registry.
- `ItemGroupEvents.modifyEntriesEvent` now takes a `RegistryKey<ItemGroup>` in place of an `Identifier`
- `FabricLanguageProvider` now takes a `RegistryKey<ItemGroup>` in place of an `ItemGroup`
- `IdentifiableItemGroup` removed, replaced with vanilla registries.
- `FabricMaterialBuilder` removed, no replacement.
- `HudRenderCallback.onHudRender` now passed a `DrawableHelper` in place of `MatrixStack`
- `ScreenEvents.beforeRender` now passed a `DrawableHelper` in place of `MatrixStack`
- `ScreenEvents.afterRender` now passed a `DrawableHelper` in place of `MatrixStack`
- `Screens.getItemRenderer()` removed. Replace with `MinecraftClient.getItemRenderer()`
`DrawableHelper` is likely to be renamed soon, see: https://github.com/FabricMC/yarn/pull/3548/
* BlockSetTypeRegistry and WoodTypeRegistry
Adds `BlockSetTypeRegistry` for creating `BlockSetType`s using Identifiers.
Also adds `WoodTypeRegistry` to replace `SignTypeRegistry`, matching the new more accurate Yarn name. The old `SignTypeRegistry` remains as deprecated for compatibility.
Also updates Yarn build.
* Delete SignTypeRegistry.java
Broke in the update anyway, no use keeping it
* Suggestions
* Whoops
* Suggestions
* Fabric custom ingredient API
* More Ingredient API work
* Optimize shapeless matching logic
* Fix all the things
* Move custom ingredient network serialization to account for ingredient extension API
* Apply suggestions from code review
Co-authored-by: apple502j <33279053+apple502j@users.noreply.github.com>
* Address 🍎 review
* Get rid of the @Overwrite
* Implement graceful fallback for clients not supporting some custom ingredients
* Move custom ingredient code to new Recipe API module
* Fix client package change
* Address review comments
- And/Or -> All/Any
- Move builtin ingredient registration to entrypoint
- Initial protocol version is 1
- Misc other changes
* Add testing instructions
* Use a List for `getMatchingStacks`
* Overengineer ingredient query a bit
Co-authored-by: apple502j <33279053+apple502j@users.noreply.github.com>
Co-authored-by: modmuss50 <modmuss50@gmail.com>
* 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.
* Add more transitive Access Wideners
- Expose `StateProviderType` constructor. Fixes#474.
- Expose DefaultBiomeCreator.getSkyColor. Fixes#981.
- Make custom `RenderLayer` registration easier. Fixes#1635.
- Add warning at the beginning of the generated AW to prevent manual
editing of the file.
* Add warning to datagen generated AW
- Added transitive-accessible wideners for `BlockStateModelGenerator$TintType`, `BlockStateModelGenerator$BlockTexturePool`, `BlockStateModelGenerator$LogTexturePool`, and `BlockStateModelGenerator$BuiltinModelPool` classes
- Added transitive-accessible widener for `TexturedModel#makeFactory` method
- Moved transitive-accessible wideners for `ItemModelGenerator` methods to the generate run, so it covers the 2 new methods and any future ones
- Fixed `generateAccessWideners` task so it can now find the jar
- Tweaked the whitespace in the accesswidener file a bit
* Include datagen in the production fatjar. Closes#2228
* Allow exclusion of block loot tables from strict validation. Closes#2241
* Auto-generate item models even when strict validation is disabled. Fixes#2240
(cherry picked from commit 4d962b4e9e)
A common source of crashes on modded Minecraft servers comes from modders accidently calling client only code from the client, this PR is another large step towards elimitating that.
This PR has been months in the making and years in the planning, requiring major changes to Loom & Loader. In recent Minecraft versions Mojang has made it easier than ever to cleanly split the jar, going against the status-quo of merging the client and server into one jar.
From the start we have designed Fabric to have a very clear split between client and common (client & server) code. Fabric has always encoraged keeping client only code seprate from the server, this can be seen at a fundamental level with the entrypoints in Loader. Fabric API's have all been designed with this mind.
This PR provides a compile safety net around Fabric API using client only code on the server. Even though there are almost 400 changed files, minimal changes beyond moving the files were required to achieve this in Fabric API, thanks to the effort of all contributors in the past.
These changes should not affect modders or players in anyway, a single "universal" jar is still produced. Im happy to awnswer any questions.
