* Deprecate some conventional tool tags added to vanilla
For backwards compatibility, the old tag IDs are added to the vanilla ones. The exposed keys are redirected to their replacements.
Also optionally adds Cherry Grove biome to `c:in_overworld`.
* Keep the convention tags, just deprecated
* You saw nothing
* Apply disabled shade from vanilla quads directly to material
- Remove QuadViewImpl.shade
* Fix enhanced AO calculation and respect non-terrain culling state
- Fix AoCalculator using AO face data computed with a potentially different shade state
- Move non-cached computation code to separate method in AoCalculator
- Turn AoCalculator's brightnessFunc and aoFunc into abstract methods
- Do not check null check world in non-terrain AO calculation since it cannot be null
- Pass through lightFace and shade state as method arguments in AoCalculator methods to prevent additional lookups
- Do not check for the axis aligned flag in AbstractQuadRenderer.shadeFlatQuad
- Respect cull parameter passed to non-terrain rendering by merging TerrainBlockRenderInfo into BlockRenderInfo
- Use reusable search pos when calling Block.shouldDrawSide to prevent additional BlockPos allocation
- Change BlockRenderContext.render and TerrainRenderContext.tessellateBlock to return void since return value is no longer used
- Remove QuadViewImpl.vertexStart since it is unused
* Add suggestions
- Mark Direction parameter to BlockRenderInfo.shouldDrawFace as Nullable
- Reuse MaterialFinder in FrameBakedModel
(cherry picked from commit 3a95925af4)
* 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
* Add github action to check that all resources are generated.
* Test
* Revert "Test"
This reverts commit 8e187bc781.
(cherry picked from commit 40dc7a94f6)
* Fix the issue that cannot load world after uninstalling a dimension mod/datapack, by making deserialization fail-soft, instead of removing non-vanilla dimensions.
* Fix style.
* Fix license.
* Small changes to FailSoftMapCodec.
* Make FailSoftMapCodec final.
* Revert "Make FailSoftMapCodec final."
This reverts commit 0c0642a1c4.
* Use ModifyVariable and change comments.
* Remove unnecessary `equals`
(cherry picked from commit 00a2eb1095)
* 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>
* Fix#2639: Indigo fallback consumer does not respect BlendMode or emissivity
* Change renderer testmod to test material change
* Remove presumably unneeded `quad.geometryFlags()` call
* Also test emissivity
* Call emitBlockQuads in the testmod
* Allow passing the block state explicitly to the fallback consumer. Fixes#1871
* Expand testmod to also test item models
* Also fix fallback consumer ignoring material for items
* Slight changes
* Introduce new interface for the expanded fallback consumer
* Add javadoc to ModelHelper
* Allow OptionalInt in BiomeModificationContext
For some reason, vanilla uses `Optional<Integer>` instead of
the preferred `OptionalInt`. Add an override that allows passing
`OptionalInt`. For consistency with vanilla, the old method is NOT
deprecated.
* Do not rely on Identifier identity when checking registration
`Identifier` is a value-based class and should never be compared
using `==`. Luckily, this does not cause bugs right now.
(Using `equals` is worse, since it'll prevent spawning pigs.)
Instead use the proper method of checking if an entry is registered.
* Fix#2079
`generateAccessWidener` task in TAW module will now automatically generate TAWs for the constructors of non-abstract item classes, similar to how it already did so for blocks.
As such, previously manually added item constructor TAWs have been removed from the template. This also means that `HoeItem` is now TAW'd. (I totally overlooked it earlier... whoops!)
* Replace useless nullability comments with jetbrains annotation
* These were old comments
* Revert "These were old comments"
This reverts commit 4e9555ad51.
* checkstyle + nullability in mixin
* 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.
