[1.12.1] Questions about JSON recipes

[the_rooster]

I'm creating a mod for 1.12, and from what I've seen the JSON recipe system seems to be unable to handle the way my mod is designed.  I recently ran across a thread in this forum that pointed out that the way in which I'm currently registering my recipes in code is completely horrible and should be avoided at all costs.  So, in interest of doing things the right way, I'm hoping someone with a better understanding of the json recipe system could help me out.  My questions are:

 

1. Can the json recipe system handle creating a recipe for items that are not known at compile time?  My mod allows for users to define ores in a .json file, and it will generate ores, ingots, armor, and tools for each ore (based on config).  Registering recipes programmatically makes this trivial, I simple loop through all of my ores and register the recipes for each of them.  In the json system it seems that I would have to know every possible ore that anyone could ever want to create, and have already made a .json for all of them.  

2. Is there a way to take a "template" recipe and at runtime replace a placeholder value with each of my ores in turn? This would solve the issue above.

3. Slightly related, How would a custom IRecipe extending ShapedOreRecipe ignore a portion of an ingredients oredict name.  In my mod, ores can have variants which are registered with name such as oreIronPoor, which would smelt into things like nuggetIron.  I want to have a custom recipe that allows you to craft tools and armor using these lesser versions of ores, and have the end result be pre-damaged.  I don't want to register all of my ores with the oredict name of oreIron, because then even the poor ores could be put through ore-doubling mechanics to completely negate the point of them.

 

I'm hoping someone with a better understanding of this system can at least point me in the right direction.

[jabelar]

1. Yes. At "compile time" there is no compiler relation at all between the JSONs and the item and block classes. The JSON matches based on the string registry names which it doesn't know about until the registration events are run. So recipes are only matched at run time. As long as the items and blocks are registered prior to the recipes I think you're good. For example I've created recipes that change based on configuration settings (requires restart of Minecraft to take effect) because the configuration loads before you register the recipes. You can also create conditions in your recipes and change the conditions in your code to change the behavior of the recipes. I give a few tips on these topics here: http://jabelarminecraft.blogspot.com/p/minecraft-modding-ore-dictionary.html

 

2. You can still implement old-school recipes I think by creating your own IRecipe implementations. They could be a "template" that you construct with different parameters. I haven't tried it but have seen mention of such an approach in other threads.

 

3. If you're extending or implementing the class it is your code, so I think you'd just override the appropriate methods while doing some string processing to take the portion of the name you care about. For example, there is string function for whether a string contains a substring, so if for example the full name contains "OreIron" then you could consider it a match and it should pick up all the variants.

 

All the above is really just about Java. Pretty anything you want to do can be done. You could create your own asset format instead of JSON if you wanted to and use your own Java file handling, you could use reflection and replace major portions of the built-in system, and so forth.

[Draco18s]

58 minutes ago, jabelar said:

 As long as the items and blocks are registered prior to the recipes I think you're good.

Which if you're using the registry events for your blocks and items, that is guaranteed to run before json recipes are loaded.

[the_rooster]

2 hours ago, jabelar said:

1. Yes. At "compile time" there is no compiler relation at all between the JSONs and the item and block classes. The JSON matches based on the string registry names which it doesn't know about until the registration events are run. So recipes are only matched at run time. As long as the items and blocks are registered prior to the recipes I think you're good. For example I've created recipes that change based on configuration settings (requires restart of Minecraft to take effect) because the configuration loads before you register the recipes. You can also create conditions in your recipes and change the conditions in your code to change the behavior of the recipes. I give a few tips on these topics here: http://jabelarminecraft.blogspot.com/p/minecraft-modding-ore-dictionary.html

By "compile time", I mean when the mod is packaged for release.  In my understanding, the json recipes in the assets folder are placed into the jar at this point.  My issue is that I cannot actually create the recipes ahead of time, because the ores added to my mod are defined by a json file in the configuration directory.  So someone could theoretically use my mod to add an oreUnobtanium.  Aside from some sneaky things like editing the .jar file while it is running, there would be no way to add a "blockUnobtanium.json" (recipe that converts ingots of unobtanium into blocks of unobtanium) into the assets directory of the .jar.  

 

Source code for my mod is here, so it's a little clearer what i'm talking about: Ores 

 

2 hours ago, jabelar said:

 

2. You can still implement old-school recipes I think by creating your own IRecipe implementations. They could be a "template" that you construct with different parameters. I haven't tried it but have seen mention of such an approach in other threads.

I'll look a little deeper into this, I've already implemented a custom IRecipe for some recipes, though I didn't see a way to map a single recipe across an array of possible inputs using the JSON system.

 

Ideally, what i'd like to be able to do is something like this:

{
  "result": {
    "item": "romimocoores:helmet#ORENAME"
  },
  "pattern": [
    "xxx",
    "x x"
  ],
  "type": "forge:wildcard",
  "key": {
    "x": {
      "type": "forge:ore_dict",
      "ore": "ore#ORENAME"
  }
}

Which would then on load be registered for each of the ores in my ModBlocks.ORES hashmap.

 

 

2 hours ago, jabelar said:

3. If you're extending or implementing the class it is your code, so I think you'd just override the appropriate methods while doing some string processing to take the portion of the name you care about. For example, there is string function for whether a string contains a substring, so if for example the full name contains "OreIron" then you could consider it a match and it should pick up all the variants.

Yeah, That was my initial instinct here, though I couldn't wrap my head around how shapedOreRecipe does it's matching of ingredients.  Although after looking, it looks like the answer is in OreIngredient

 

1 hour ago, Draco18s said:

Which if you're using the registry events for your blocks and items, that is guaranteed to run before json recipes are loaded.

Definitely.  Which brings to mind another question.  Is there a RegistryEvent<Recipe>? I originally looked for that so as to do as much as possible in an event driven way, but I didn't see any matching event. 

 

Thanks for the replies.  My Java knowledge is pretty good, and I could hack together something to make this work, however if a way exists to do this using the tools forge provides at the very least it should lead to fewer headaches when 1.13 comes around.

 

 

[Draco18s]

28 minutes ago, the_rooster said:

Definitely.  Which brings to mind another question.  Is there a RegistryEvent<Recipe>? I originally looked for that so as to do as much as possible in an event driven way, but I didn't see any matching event.

Yes.