Removed vanilla crafting recipes still showing up in JEI
Opened this issue ยท 8 comments
Issue Description
I have many vanilla crafting recipes disabled in .core.cfg (not the default list, but I left most of them). They seem to be disabled just fine, but they still show up in JEI
What Happens
See above
What You Expect to Happen
Ideally these removed vanilla crafting recipes would not show in JEI
Script
Affected Versions
- Minecraft: 1.12.2
- Forge: 14.23.5.2838
- CraftTweaker: 1.12-4.1.19
- Dropt: 1.12.2-1.15.1
- Pyrotech: 1.12.2-1.2.1
- Athenaeum: 1.12.2-1.17.2
This approach has hit a snag. It works fine for crafting recipes because those all have a unique identifier, however, smelting recipes do not have a unique identifier. Smelting recipes are identified by their output and, since the removal code is run in the LoadComplete event, it is run after CrT; any smelting recipes added by CrT that matched the output listed in Pyrotech's config would then be hidden in JEI.
I'm trying to think of a case where this would be an issue.
Ok, this is actually an issue in Pyrotech right now:
JEI displays the removed recipe as well as the new recipe. However, since the output of the new recipe added by Pyrotech matches an output to be removed, it gets removed as well...
Recipe removal was moved to the LoadComplete event in order to prevent Pyrotech from removing recipes before Thermal Expansion had a chance to generate its recipes from the removed stuff. Specifically, the log to planks crafting recipes. I don't know if Pyrotech's removal of furnace recipes interfered with Thermal's recipe gathering, but I moved it to the LoadComplete event anyway.
This has been a lot of work so far and it looks like it will be causing even more headaches.
If I move the removal back to where it was before. Thermal Expansion will be missing a few common recipes, such as the sawmill recipes for turning logs into planks. Other mods that rely on state interrogation to derive recipes might also suffer for this.
In the case where another mod suffers recipe loss due to Pyrotech, the user could be instructed to remove the recipes of interest from Pyrotech's config. This would re-enable the crafting recipes that Pyrotech removes by default and at that point it would be up to the user to remove them using other means.
If the user were to stop Pyrotech from removing the recipes and then remove them with CrT, for example, Thermal Expansion might still be missing the recipes. I don't know when TE gathers its recipe data. At least then it would no longer be the fault of Pyrotech.
Thermal Expansion does its sawmill recipe scan during post init: https://github.com/CoFH/ThermalExpansion/blob/8ea25f853358bfe2d9f9359bf6d979f0de9e16fa/src/main/java/cofh/thermalexpansion/util/managers/machine/SawmillManager.java#L91
It looks like this is happening because in 1.2.0 the recipe removal was moved to the LoadComplete event. This is also the event during which JEI starts all its plugins, so this is probably the conflict. I'm not entirely confident in how the FML lifecycle events are ordered. I'm using an older version of JEI in my dev environment, and I haven't experienced this, which would indicate that the LoadComplete event was handled first by Pyrotech.
The evidence suggests that with the newer versions:
- JEI initializes its plugins, and then
- Pyrotech removes recipes
I'm going to look into maybe having Pyrotech check if JEI has started before removing the recipes. If it has started, hide the recipes in JEI.
Confirmed this approach seems to work and the behavior is consistent across versions.
JEI is still gathering the removed recipes for the worktable though, so those must be removed too.