AsherGlick
commented
2 years ago tl;dr: Use requirement_groups and ignore the problem like I did.
This is a very deep rabbit hole I fell into previously.
“Mix and Match” recipes that allow for multiple non-uniform items as requirements are truly a pain to deal with in the resource calculator. Unfortunately, the problem is not as simple as you describe it because each item in the recipe can be a different subtype of wood, not just each item type.
This means that for a chest that needs 8 planks of wood, and there are 8 plank types, would have 8^8 (or 16,777,216) possible ordered recipes. Luckily resource calculator does not care about ordering. So we can reduce that down to only 27,456 possible recipes. This is obviously still too many. To combat this, I originally tried to manually force all recipe’s to contain only the same types of wood. EG: all planks and slabs would be the same type of wood. This matches how the specialized recipes work. EG: in order to make a birch fence gate, you need to only use birch wood. This was not perfect though, and a bit tedious. So I tried creating a step towards a solution in the form of requirement_groups. A requirement_group could contain any number of other items and then could be used as if it itself was an item. This was great, but I never got around to figuring out how this would work in the user interface. Just displaying the possibilities would return us to the 27,456 possible recipes to choose from. So I decided to not solve the problem and instead only show the recipe of the first item in a requirement_group with the expectation I would eventually figure it out in the future. For now the requirement_group just acts as an alias for the first item in the list and I have not received any complaints about it yet.
I am happy to consume some other format that you have extracted instead of having your application match the resource calculator format. This would free your app from needing to obey any schema changes to resources.yaml in the future, such as whenever I figure out what to do with requirement_groups.
Last, something is better then nothing. If you want a validator to ignore everything with a * wildcard and only use this extracted data to validate some recipes, it will still be a step in the right direction, even if it is not the complete ideal. Further thought can be given to how to validate the wildcards in the future.
mmodrow
I've been thinking and prototyping on the whole "let's parse the recipes from the jsons in the jar" thing. I need some input from you, so I follow your suggestion of opening an issue on that topic.
I whipped something up that pulls all the relevant JSONSs from a jar and started writing the mapping models and the deserializers. Works like a charm so far. I get all the item tag & recipe jsons and fully deserialized & flattened tag objects in fractions of a second.
To properly match your structure I need to map tag references in the recipes back to the actual items. This is fine with e.g. chests (when only using one type of planks that's at max 8 recipes to consider), but quickly results in escalation considering things like barrels (8 slab types x 8 log types = 64 recipes).
Currently the game has 3 recipes where logs/planks/wooden_* meet another tag (both types of campfires & the barrel). To still allow for things like torches from char coal and from coal, I'd like to still allow tags to resolve to different items for different recipes and not flatten them to a single item.
Thinking about your UI I'd aim for a heuristic, that creates at most 4 recipes from a single json. That would result in at most 6 entries (4x crafting, 1x plain item, 1x alternative crafting method like stone cutting or smelting). Does that sound reasonable to you?
Or would you prefer a full dump & pick'n'choose the best ones by hand?