Describe the bug

I tried to add my own recipes to ae2 recipetypes like the grinder via crafttweakers data support. I had to recognize that ae2's recipetypes are unknown so I asked on crafttweaker's discord and they said the reason might be that the recipetypes are not registered on the mods side.
This is a post from crafttweaker dev "kindlich" on another mods issueboeard about this topic: BlakeBr0/ExtendedCrafting#93 (comment)

To Reproduce

Install ae2 and crafttweaker and try to add a processing recipe via script. E.g.

<recipetype:appliedenergistics2:grinder>.addJSONRecipe("ae2_grinde_test",
    {
        input: {
            tag: "forge:ores/redstone"
        },
        result: {
            primary: {
                item: <item:minecraft:redstone>.registryName,
                count: 6
            }
        },
        turns: 4
    });

Expected behavior

The data json support of crafttweaker generally works for all recipes added with minecraft's datapacks without any crafttweaker support on the mod's side or any needs for crafttweaker to do something.

Additional context

No crash.

Environment

• Environment:
  forge-31.2.31
  appliedenergistics2-7.0.0-beta.1
  CraftTweaker-1.15.2-6.0.0.37

Both the type and serialiser use the same ResourceLocation like kindlich recommended. If this does not work, I would suggest asking them as I am not familiar with crafttweaker at all.

There appears to be no forge registry event for a IRecipeType, only the internal one, which forge explicitly declares to not use.
But I would not exclude that I might have missed it.

If this is required for you, I would suggest requesting a new event for it. I certainly do not want to deal with some internal minecraft registry and then have Lex later yell at us or completely break it in some way.

While we can make a PR to forge to make it a ForgeRegistry, they won't accept it for 1.15 because it is a breaking change, so it would only be for 1.16.

Basically no one is going to shout at you and you aren't going to be breaking anything by touching the registry, that one isn't deprecated meaning it is fine to use (apparently)

To give the solution: call IRecipeType.register, and store the returned IRecipeType. The static helper method will automatically convert the String into a ResourceLocation, and register the IRecipeType into the vanilla registry.

There is no need for a Forge registry (and Forge does not explicitly add @Deprecated to the vanilla IRecipeType registry) because there is no need for the syncing and management (+ overhead) provided by ForgeRegistry for a simple token interface/class.

Tried looking through the code for it, but github is really annoying when trying to find specific code...
Do you guys register your recipe type at all? like so:
https://github.com/CraftTweaker/CraftTweaker/blob/af643c5b59b6bfceffdba261ebd8119e1c90bc83/src/main/java/com/blamejared/crafttweaker/CraftTweaker.java#L121-L126

It doesn't look like it to me.
It seems like you only create it.

We need it in the recipe type registry or otherwise we aren't able to find it

@kindlich Why are you not looking up the serializer? If this is about adding recipes, Vanilla necessarily needs to be able to go from serializer id -> serializer -> deserialized recipe -> recipe type. Why can't you?
If this is about removing recipes: They have unique IDs anyway...

It's not only about removing recipes.
This is what CrT will use internally for recipetypes:
https://github.com/CraftTweaker/CraftTweaker/blob/1.16/src/main/java/com/blamejared/crafttweaker/api/managers/IRecipeManager.java

The methods annotated with @ZenCodeType.Method are what the user will be able to use in the scripts.

We provide functionality to remove based on certain criteria, as well as listing existing recipes.
We added the way to add by JSON to this interface as well because it makes it easier for the user since our other handlers have addition and removal on the same object.

Regarding removal:
I'm not sure, I thought adding the same recipe location to multiple recipetypes was possible.
If that is not, then the ability to list existing recipes still requires us to be able to get the recipetype.

@kindlich Hmm, oh well, it doesn't matter. I somehow doubt we're going to be the only ones forgetting to register though :-D

We're going to register the recipe types anyway for consistencies sake. (see the linked PR, which will need to be cherry-picked back)