API or KJS integration to clone GT recipes or register them in JSON form

[Xefyr0]

Cross-mod Integration

KubeJS

Minecraft Version

1.20.1 Forge

Feature Description

Posting an Issue here as suggested by @jurrejelle

In my experience as a GTM packdev, the GTM integration with KJS has been excellent for creating new recipes - the methods exposed from com.gregtechceu.gtceu.integration.kjs.recipe.GTRecipeSchema and its nested class, GTRecipeJS have been a major boon for the packdev experience.
Similarly, the experience with removing recipes has also been smooth.

However, I can't seem to find such an easy way to modify or copy recipes.
Yes, replaceInput and replaceOutput work perfectly (Many thanks to Kross for implementing this previous request of mine) but they have a flaw in that they are only able to change an item or fluid type, and cannot:

1. Modify amounts of input or output items/fluids
2. Add or remove Inputs or outputs
3. Alter recipe properties beyond inputs/outputs, such as e.g. Conditions, Data, or Duration

There is a reasonable, if verbose way to modify recipes by accessing the underlying JSON structure directly as seen in this example on the wiki but if I want to, say, make a copy of a recipe, modify that recipe, and then register this modified copy then it becomes quite the struggle.

I've spent 5-10 hours trying to work my way through the combined recipe registration system of GTM and KJS, and it seems the intended process is to:

1. Search for the recipe to modify using KJS' filters with event.findRecipes or similar (fine enough)
2. Modify the recipe or its JSON representation with new or replacement inputs, outputs, duration, conditions, etc. (Verbose, but reasonable)
3. Register this modified recipe or a copy with a specified id
   (Monumentally difficult. Induces hair-tearing and general anguish)

The natural starting point for step 3 is to feed the JSON member of the RecipeJS from step 1 into event.custom, but this has two issues:

1. You can't specify a recipe ID with event.custom. Yes, there's a method and field RIGHT THERE in the source but you can't use it due to (I assume) the same old Java/JS/Rhino fuckery.
2. The EU tick input is missing:

Issue 1 can be solved by using the regular KJS recipe builders from the GTM API since those can be fed recipe IDs easily and yield instances of GTRecipeJS, which inherits from RecipeJS. It requires either a bunch of boilerplate or dynamically indexing event.recipes.gtceu to decide which member of call depending on the recipe type, but that is acceptable given the nature of KJS.
Issue 2, however, is significantly more challenging and is the best workaround I could come up with is to remove any tick inputs from the JSON fed into the instance of RecipeJS/GTRecipeJS, and then manually adding it back with KJS GTM API calls such as EUt and inputEU.
I hope you can empathize with me on how unappealing it would be to use these workarounds - I haven't investigated the effects of these workarounds on all of the ways a GT recipe can hold information, and suspect that one or both will break or that I'll need another one when I try to test a different recipe than the Gold/Platinum to Osmium fusion recipe I've been using. And frankly, I don't want to spend another 5-10 hours dealing with that possibility or the even jankier workaround I'd come up with in response to it.

When I shared this in the GTM Discord, I quickly received a response suggesting that I use the regular old GTRecipeJS methods to build the copy I want from scratch instead of trying to directly copy an existing one.
This is as tedious as it sounds, and I don't want to have to write the boilerplate to call some combination of up to 155 methods(!) plus any additional ones from addons to reconstruct what already exists.

This leaves me stuck between a combination of rocks and hard places - I'm aware that this may be a result of a skill issue on my part with a ready-made solution that I've overlooked, in which case I'd be happy to hear it. If not, I think adding a solution to my problem to the GTM API or KJS integration would be helpful to more than just myself - you can see the TFG team taking the "rebuild the recipe from scratch" route here and it's over a hundred lines of boilerplate but still doesn't cover all of the conditions and data a recipe can have.