the_rooster

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 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. 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 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.

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.