[WIP] Recursive recipes

[marilynias]

Summary

Features "recursive recipe crafting"

Purpose of change

From the feedback for #81030 it became clear that was actually desired is to be able to craft recursively.

Describe the solution

Give recipe components another flag: [ [ "flour", 22, "CRAFTABLE" ] ]. If those components are not present, recursively check if those components are craftable and craft those first.

When displaying recipes, show recipes which components can be crafted in a different color (similar to when its using rotten components).
When crafting, craft required components first.

TODO:

• selector when multiple components are craftable
• result information for selector menu (kcal etc.)
• auto-craft the next recipe when component craft is completed
• general optimization/caching
• correct "recraft last recipe" behaviour
• check circular dependencies
• check for multiple recipes for same component (suffix)
• check for in-progress crafts
• check for components consumed by previous step

Describe alternatives you've considered

Testing

Additional context

Demo:

2025-06-10.15-00-51.mp4

Just a prototype for now, currently very brittle and un-optimized.

Also don't mind the yeast_dough_rested recipe, its in preparation for the future.

[PatrikLundell]

Similar principles are used for construction, sometimes with very weird results.

An example:
I ordered my companion to build upwards stairs. This requires the construction of half a stair, which in turn requires the construction of a shallow pit. The bizarre path chosen was to build a coffin, bury it, unearth it, and then build the half stairs on the shallow pit left behind.

This is not an isolated case, as base camp expansions can use up much more time and materials than they ought to based on similarly bizarre paths for pits, doors, and windows.

What I'm warning against here is that your recursive logic has to be robust enough to at least find a decent path to get the materials needed, or you may end up having your rare tools deconstructed to get reasonably common components you might have wanted to get through just about any other path.

[Hyperseeker]

This is indeed an excellent change, but please bear in mind that recipe steps are equally desired. Unattended steps would be a godsend.

[marilynias]

This is indeed an excellent change, but please bear in mind that recipe steps are equally desired. Unattended steps would be a godsend.

I don't think unattended recipes require steps. But that will be a problem for the future.

[marilynias]

What I'm warning against here is that your recursive logic has to be robust enough to at least find a decent path to get the materials needed, or you may end up having your rare tools deconstructed to get reasonably common components you might have wanted to get through just about any other path.

Components that are craftable have to have the flag set in the recipe. Components without the flag are ignored.

[PatrikLundell]

Deliberately marking components eligible for recursion reduces the risk of stupidity, but it doesn't prevent it. There are quite a few things that can be made using multiple recipes, so a choice of which one to use would have to be made. I believe there is a "base" recipe which is just the name of the item, but there can be alternatives that use suffixes. One approach would be ignore suffixed versions and only considering the base recipe. That would obviously have consequences.

[marilynias]

Oh I forgot about suffixes. But since I plan of implementing a choice query for which component to craft if multiple are possible, similarly to current component query, it should not be too difficult to ask for the recipe version you want to use.

[Hyperseeker]

I don't think unattended recipes require steps.

I think they will, 'cause otherwise what you end up having is a bunch of half-finished products, and I seem to remember the core dev team being quite opposed to creating a bunch of small items for this sort of thing. It's partly a developer experience thing, in this case.

No pressure. Just wanted to give some feedback on a cool feature.

[marilynias]

I think they will, 'cause otherwise what you end up having is a bunch of half-finished products, and I seem to remember the core dev team being quite opposed to creating a bunch of small items for this sort of thing. It's partly a developer experience thing, in this case.

No pressure. Just wanted to give some feedback on a cool feature.

The comments from #81030 made it clear that every step should have its own product to be able to be used in different recipes, so intermediate items no matter what.
But yeah, not relevent yet for this PR.

[GuardianDll]

That's actually a pretty decent representation of what we want, methinks
I don't think it is actually necessary to have subcomponent for steps, like i absolutely can see dough not requiring such, or set of crafts that may or may not require to unfreeze the meat before cooking it (atm we have bunch of crafts that do allow to cook frozen meat directly, and another bunch that do not), unless it is handled by allowing to require item with specific flag (like water vs water (hot))

[marilynias]

update: can select which recipe to use for a given component. Currently shows recipe id, since I dont think there is a description of the recipe that doesn't just list the result. I will probably allow using the "name" field in recipes for non-practice recipes in a separate PR if it doesn't break other stuff like crafting menu filtering.

2025-06-23.15-20-37.mp4