Alloy Smelter recipe inheritance rewrite

[rlnt]

Description

This pull request introduces a rewrite to the vanilla smelting recipe inheritance of the Alloy Smelter.

The current implementation leaves no room for customization. Modpack authors are not able to filter inherited recipes properly. The KubeJS EnderIO add-on made this possible but it's very hacky because the synchronization between server and client has to be handled via a dummy recipe type because of timing issues. Filtered recipes had to be synced to the client to hide them from JEI.

The new approach uses the RecipeManager directly. It wraps existing SmeltingRecipes as AlloySmeltingRecipes upon loading and injects them back into the manager. This way, the inherited recipes have the same recipe type as normal alloy smelting recipes and are handled through the default serializer. This has the benefit of automatic network synchronization. To properly reflect the origin of the recipe, the alloy smelting recipe type received a new flag which can be used to change behavior between alloying and smelting recipes. The recipe ID of inherited smelting recipes was also changed. It uses the EnderIO namespace and a path prefix which I decided to use smelting/ for (feel free to change this).

Because the recipes are properly synchronized, the JEI recipe category for the Alloy Smelter was modified and no longer shows all vanilla smelting recipes. Additionally, the integration endpoint to filter alloy smelting recipes is no longer required and was removed. The RecipeManager inject happens early enough so mods like KubeJS or CraftTweaker are now capable of modifying the inherited recipes or removing them completely. The recipe ID change allows other mods to easily target inherited recipes now.

If you want to split the recipe generation logic from the mixin class for better structure, feel free to.

A few technical things:

To allow modifications to the recipe loading, a RecipeManager mixin was required. Currently, EnderIO only uses mixins in the base module. However, since this change is machine-related, I decided to make a new package within the machine module and load the required mixins from there. Feel free to change this if you want a different structure.

A second mixin was required for the AbstractCookingRecipe. It's an accessor mixin that allows grabbing the hidden fields from the class. If you are questioning, why I don't grab the required elements via the methods in the SmeltingRecipe class, you have a good point. Since the inject in the RecipeManager holds an instance of the SmeltingRecipe and the RecipeManager also holds an instance of registry access, it should be possible to obtain the result of the SmeltingRecipe. However, for some reason, the lambda inject needs to be static and this prevents using the local instance of the registry access. I thought this was a bug in the Minecraft Dev plugin but the bytecode shows that the lambda is indeed statically executed. This may be a bug in Mixin itself because it's definitely possible to have non-static lambda mixins but since the library is not well maintained, I didn't bother to file an issue report. I'd like to avoid a second mixin but I didn't find another option.

Breaking Changes

The only breaking change I introduced is the removal of the integration endpoint to filter smelting recipes. But since my add-on was the only mod using this endpoint, I don't think this should be considered breaking.

Checklist

• My code follows the style guidelines of this project (.editorconfig, most IDEs will use this for you).
• I have made corresponding changes to the documentation.
• My changes are ready for review from a contributor.

[Rover656]

Thanks for this, I'm happy with how it looks and works.

Just a couple of comments for you before we can merge!

[Rover656]

Looking good to me - happy to merge if you are :) Cheers!

[rlnt]

Yup, go ahead. Thank you.