Fix Some Recipes Being Out of Reach of CraftTweaker

[serenibyss]

This PR restructures the loading order of the Forestry compat, as well as some autogenerated recipes (block compression, packer/unpacker, forge hammer, etc) which were all getting registered on the postInit event fire. Since there was some discussion on this in the issue thread this PR is addressing, I will explain to the best of my knowledge how the recipe registration order behaves.

Following the preInit event, Recipe Registration Events under the name of RegistryEvent.Register<IRecipe> are fired. These events can be given priorities through the @SubscribeEvent annotation, but ultimately, all of these events will be fired before CraftTweaker scripts are run (excluding certain loaders, like #loader gregtech, which is run in preInit). All recipe registration is intended to be done in these events, after preInit and before init. While it is considered bad practice, if for whatever reason recipe generation must go after CraftTweaker, then it should be done as the very first thing on the init event firing.

Now for whatever reason, these recipes were being registered in the postInit event, which is barely in time for JEI to pick them up and put them in its own recipe registry, not to mention well after CraftTweaker has finished running through all of its scripts.

Here is a sample script that can be used to prove that the recipes from the original issue are being properly removed:

import mods.gregtech.recipe.RecipeMap;

val compressor as RecipeMap = RecipeMap.getByName("compressor");
val reactor as RecipeMap = RecipeMap.getByName("chemical_reactor");

// 3x3 block compression recipe
compressor.findRecipe(2, [<minecraft:coal:0> * 9], [null]).remove();

// Comb chemical reactor recipe
reactor.findRecipe(24, [<gtadditions:comb:13> * 9, <ore:crushedSpodumene>.firstItem], [<fluid:water> * 1000]).remove();

With this PR, I also verified that all other recipes are reachable by CT, since I did not see any reason why they should be done after. I also restructured the proxy slightly, since much of it was unnecessary and was only spreading the code out making it harder to follow.

Closes #84

[Exaxxion]

It seems like following these changes there are no recipes generated in GTCE machines from the Forestry centrifuge and squeezer recipe maps.

Before:

After:

Before:

After:

The indentation for your changes is also inconsistent with the existing formatting. Please use tabs for indentation and spaces for alignment.

[Exaxxion]

Does this block even have any effect after your changes elsewhere?

[serenibyss]

Yes, it is still needed for ClientProxy registering the color handlers of the GT Combs

[Exaxxion]

I see, you were using it as a stub so ClientProxy could override the superclass method. I forgot to consider the sidedness of the proxy object's dependency injection, so it looked at a glance like we were unintentionally calling a method whose contents were just entirely moved elsewhere.

[serenibyss]

I see the issue. Apparently Forestry recipes are similarly generated after it is too late for CraftTweaker. So this means that the Comb Centrifuge and Extractor recipes for Forestry Combs will be out of reach unfortunately.

[Exaxxion]

It seems like the Forestry devs are still doing bugfixes on 1.12.2 so it might be beneficial to work with them on this. They should be doing their recipe registration during FMLInitializationEvent rather than FMLPostInitializationEvent.

Called after FMLPreInitializationEvent and before FMLPostInitializationEvent during mod startup. This is the second of three commonly called events during mod initialization. Recommended activities: Register your recipes and Ore Dictionary entries in the GameRegistry and OreDictionary Dispatch requests through FMLInterModComms to other mods, to tell them what you wish them to do.

[ALongStringOfNumbers]

The Forestry devs might still be doing bugfixes on 1.12.2, but they have not released a new version with those bug fixes since April of last year.

I think in lieu of that, this PR should be merged and if the Forestry devs ever release a new version for 1.12.2 with the fixes that would be required for this PR, we can then add back the Forestry recipe adjustments as well as upgrade our dependency on the Forestry version.

[Exaxxion]

Yes, that's a fair point. There also hasn't been any subsequent activity since we filed the bug ticket to Forestry. I worry that because my explanation was a bit poor and Dan needed to correct it after their initial reply, that they are dismissing the problem after more or less replying "what are you on about."

[Exaxxion]

Code changes look fine for what we can do right now. We'll need to keep track of whether the Forestry devs choose to address the item registration timing issues and can follow up with fixes if they do.

Unfortunately this means we aren't fully fixing the underlying issue ticket, but we know the nature of the problem now.