Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[BUG] Recycling Recipes in the Fluid Extractor Registered Too Late #1762

Open
1ahmadbassam opened this issue May 16, 2024 · 3 comments
Open
Labels
status: unverified type: bug Something isn't working

Comments

@1ahmadbassam
Copy link

Describe the bug
Hello. I know this repo is mostly dead, but I thought I would share this for anyone programming for GTCE and encountering issues with removing some fluid extractor recipes.
Unfortunately, it appears as though some recipes get registered at the very end of the recipe registration sequence, i.e. with very low priority. This includes glass and its derivatives.

Outcome
Removal with Crafttweaker for those recipes fails because they would not be found by the CT handler which runs prior to the registration sequence of these recipes. Moreover, mods subscribing to a Forge event with normal priority will not be able to override or remove those recipes either. The current solution I've found was to register an event with the lowest priority (see this for more information).
Unfortunately, as I am barely experienced with Forge programming, I cannot suggest a fix at this time.
Most likely, RecyclingRecipes class has to be initialized with a higher priority (it is currently initialized with the lowest priority); however, this will have side effects of failing to register recipes for late handlers which might add content (such as Crafttweaker itself).

@1ahmadbassam 1ahmadbassam added status: unverified type: bug Something isn't working labels May 16, 2024
@Exaxxion
Copy link
Collaborator

Recipes are supposed to be registered during RegistryEvent.Register<IRecipe>, but often mods do not do this correctly and if you want compatibility with those mods, recipes have to be registered after they register theirs (and consequently those late-registered recipes are out of reach of CraftTweaker).

We have this problem with Shadows of Greg's Forestry compatibility for example, as Forestry is one such mod registering their recipes out of phase.

Not sure offhand if this is the case here as I've not looked at it yet, but figured it's worth mentioning.

@Exaxxion
Copy link
Collaborator

Looking briefly at the code, we are registering during that event, but with the lowest priority.

//this is called last, so all mods finished registering their stuff, as example, CraftTweaker
//if it registered some kind of ore dictionary entry, late processing will hook it and generate recipes
@SubscribeEvent(priority = EventPriority.LOWEST)
public static void registerRecipesLowest(RegistryEvent.Register<IRecipe> event) {
GTLog.logger.info("Running late material handlers...");
OrePrefix.runMaterialHandlers();
DecompositionRecipeHandler.runRecipeGeneration();
RecyclingRecipes.init();
WoodMachineRecipes.init();
if (GTValues.isModLoaded(GTValues.MODID_CT)){
MetaItemBracketHandler.rebuildComponentRegistry();
}
}

You'd have to ensure that anything modifying the recipes registered there runs after that, so yes, you'd have to use the lowest priority too.

@1ahmadbassam
Copy link
Author

I figured that out myself as well after tracing back the places RecyclingRecipes was initialized.
However, what baffles me is why do glass recipes specifically generate at such a late phase considering glass is a Vanilla resource (it could be because I also have Forestry along, and Forestry contains liquid glass, but honestly no idea). I have poked around with examining the recipe tree at different stages and it seems that most materials (with the exception of glass) generate their fluid extractor recipes earlier (i.e., with a higher priority).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
status: unverified type: bug Something isn't working
Projects
None yet
Development

No branches or pull requests

2 participants