Milo Recipe Extension

[Nerdpie]

This comes about from my idea a couple weeks back to try and parse ZenScript files to determine recipes for a modpack. I had originally posted this on the MC Computer Mods discord, but it got buried pretty quickly...

(Trimmed) copy/paste:

I had a thought regarding Milo recipe books and ZenScript parsing: does the JSON implementation used by Milo support JSON Merge Patch? If it does, we could collect the default recipes for various mods, and then map the ZS files to patches that add and remove recipes, rather than building monolithic recipe books for each pack. This still leaves a few issues, though:

• Fluid stacks - To my knowledge, Milo doesn't currently support FluidStacks
• OreDict entries - We would either need to define OreDict support, or pull a default entry; easy for vanilla things like logWood, but modded items would almost need to have MC running to get the entries...
• Alternative recipes - For example, Enigmatica 2: Expert has multiple recipes for chests, with some being cheaper, but requiring slightly more progress into the game. How would the recipe books accommodate this?

Expanding upon that, while recipes could be multiplied to get even bucket amounts, some recipes would be rather expensive to do so, and seeing as Plethora supports at least some fluid manipulation... (haven't actually used it myself, preoccupied with adding mod support...) For the last point, multiple versions of the recipe could be available, with some form of 'active' flag, but that either requires the user to directly edit the recipe list, or a new UI. As always, feature creep...

Thoughts?

[kepler155c]

Much of the crafting code assumes 1 recipe per item. Given that, it would require a good amount of rework. I see it as possible, but it also raises many questions (like which recipe should be used at any certain point - you would have to score recipes - or you as flag as mentioned).

Getting the ore dictionary type should be very easy - requires an adjustment to itemDB (which builds up the database over time).

The recipes are written as normal tables (see usr/config/recipes.db). I have converted json files to recipe files previously - but each mod seemed to have it's own format.

I have not looked into fluid stacks at all -

Support could be added to the recipeBook program to handle the json format - should be a straightforward transformation (I previously had this broken down into mods - but haven't converted over the files after the recipeBook update).

[Nerdpie]

Well, I would only expect one active recipe per item; any more, and the complexity increases significantly. I was more trying to think of how one might express the alternatives, and select the option to use. For instance, should we use eight planks => one chest, or the common convenience recipe of eight logs => four chests.

If I'm following, you mean having the itemDB build up a cache of what items are in a given OreDict list, such that would could reverse lookup "I need logWood for this recipe; who fits that criteria?" In that case, we would need to express oreDict values in recipes; CraftTweaker's "ore:" prefix seems reasonable. (At least until someone decides to make a mod with that as its ID...)

While I have a few guesses, I'm not entirely sure why I was thinking in terms of JSON format; it could be that I remembered Starbound's modding using it, and the Merge Patch extension, and how it would be a convenient translation for ZenScript recipe addition and removal; it could have been underlying recipes changing to JSON in 1.13 (I think? Haven't really looked into it). :man_shrugging:

Two things relate to FluidStacks in recipes: those recipes that require a fluid input, such as Forestry's Carpenter, and recipes that require 1000mb of fluid, normally in a bucket, but can also work with other containers, such as Thermal Expansion's Portable Tanks (I'm not sure if this is vanilla behavior, or if another mod is tweaking the handler for these recipes...)