Minecraft Version

1.18.1

KubeJS Version

kubejs-fabric-1801.4.1

Rhino Version

rhino-fabric-1800.1.7

Architectury Version

3.1.44

Forge/Fabric Version

0.46.2

Describe your issue

Since KubeJS cancels RecipeManager.apply right at head mods that depend on that method to inject their own recipes dynamically breakl completely by just having KubeJS installed in the same instance.

Crash report/logs

No response

Can you provide the mod(s) that you noticed is/are being broken?

I don't believe that normal mods that are simply adding recipes should need to be injecting them directly into the recipe handler. KubeJS does so because it can modify recipes post startup.

Here you go:
https://github.com/DaFuqs/Spectrum/wiki/Custom-Enchantment-Upgrade-Recipes
https://github.com/DaFuqs/Spectrum/blob/1.18/src/main/java/de/dafuqs/spectrum/mixin/RecipeManagerMixin.java#L31

In this case, a single json can define >1 final recipes.
For the recipes to upgrade enchanted books this method spares modpack makers to create individual recipe.jsons for level1>level2, level2>level3, level3>level4, ... and instead generates those single recipes dynamically. But that also means they need to be added to the recipe manager dynamically, just like KubeJS does.

This one's a bit difficult. We basically completely override vanilla logic in the sense that we force KubeJS to handle the recipe loading instead, both to inject our own logic (firing the recipe event, automatic in-/output replacement, data exports, etc.) and to hopefully speed it up a little compared to vanilla's logic.

While injecting at HEAD and cancelling certainly isn't pretty, and I'd honestly much rather like to find another way instead, I'm not really sure there's a better way to essentially strip out basically all of the method's remaining code using mixin entirely, right?

Do you have another method I can inject finished recipes perhaps?
Using a mixin plugin I could only run that part of my code when KubeJS is installed.

Do you have another method I can inject finished recipes perhaps? Using a mixin plugin I could only run that part of my code when KubeJS is installed.

I don't think we do yet, however from what I remember Lat wanted to rework the recipe event anyways so I could see about moving it to a less destructive mixin in the meantime as well ^^ If nothing else works, and it turns out the KubeJS recipe parsing mechanism is still faster than vanilla, we could also just force the vanilla recipe iterator to be empty to skip that code path entirely

Lovely. I will keep an eye on this, then. Ty! :)

There is now a method you can override in a KubeJS Plugin to register recipes like this to KubeJS.

The full steps for doing this are:

• Make a class that extends KubeJSPlugin
• Override injectRuntimeRecipes and add your recipes there
• Cancel your normal recipe adding if KubeJS is installed (the mod list contains kubejs).
• Add a kubejs.plugins.txt to the root of your jar (the resources folder) that contains a single line of the full classpath of your KubeJS plugin, ie mods.chiefarug.moddymcmodface.compat.kubejs.ModdyKubeJSPlugin

I still have to take a look at the recipe event unfortunately, since all of my current approaches to solving this seem... suboptimal in one way or another... It might honestly just be better to rework the whole recipe event in 1.19 given that that version is slated to release within the next two weeks

I am optimistically going to mark this for KubeJS 6.0, since we are trying to rework recipes in that release and that may include a refactor to how we handle RecipeManager.apply as well, but... unfortunately I cannot guarantee things, it's just... too big of a mess to say for sure if we'll be able to fix it right now with the limited time both Lat and I have :P

Do not stress it too much. I have since added a working (but a bit cursed) workaround by reading all recipes, adding my dynamic ones and then applying them all again.