Closed BlayTheNinth closed 6 months ago
Am I right that this API change allows other mods to add new recipe types by calling CookingForBlockheadsAPI.registerKitchenRecipeHandler()
and attaching ForgeCookingForBlockheads.KITCHEN_ITEM_PROCESSOR_CAPABILITY
to the desired BlockEntity
objects, whereas previously there was no way for other mods to make the Cooking Table menu show recipes not of type RecipeType.CRAFTING
or RecipeType.SMELTING
?
registerKitchenRecipeHandler
allows custom recipe class implementations to be supported, but Cooking for Blockheads still only loads CRAFTING and SMELTING.
The goal of KitchenItemProcessor
is to potentially allow support for other kitchen devices/machines, but it is fairly limited for now (i.e. it's fire-and-forget the same way the oven works).
The existing API for Cooking for Blockheads has not aged well. While originally completely based on slots, it has undergone one non-breaking refactor since that allowed it to work better for non-inventory item providers like the sink or ice unit.
However, the overall design and implementations still make it essentially impossible to interact with an item provider without relying on some form of slots, and has grown to be needlessly complex. This resulted in hard to debug issues with kitchen falsely reporting missing ingredients, as well as an inability to support Fabric's ItemStorage providers, limiting extensibility.
To solve this, a new API is being planned that will massively simplify the current code, while also allowing for much greater compatibility. This new API is already being implemented and tested in the unreleased spinoff mod Crafting for Blockheads and the relevant classes can be found here:
Some things not covered by this new design yet: