Recursive Crafting: craft prerequisites automatically first

[DeltaEpsilon7787]

Is your feature request related to a problem? Please describe.
It gets rather annoying when to craft something you first need to craft something more basic, which may also require crafting even more.

Describe the solution you'd like
An alternative mode of crafting that calculates what you need to craft first based on the resources you have available and queues a chain of crafting: Factorio-like crafting. Crafting should also take advantage of batch crafting. This will make crafting less painful, especially chemical and various other stuff.

Describe alternatives you've considered
N/A

Additional context
N/A

[ZhilkinSerg]

I believe that would be viable only for player camps and npc crafting.

[mlangsdorf]

I really don't want CDDA deciding that I want to craft a frame for my welding rig, instead of telling me I can't craft it so I can go out and loot a frame from a car in 30 minutes of effort.

[CoroNaut]

The point of recursive crafting is so that it will ask you at every step: "do you want to craft one of these prerequisites?" especially if you can craft 2 or more different items to create the higher level item.

[DeltaEpsilon7787]

I really don't want CDDA deciding that I want to craft a frame for my welding rig, instead of telling me I can't craft it so I can go out and loot a frame from a car in 30 minutes of effort.

That's why it's an alternative mode, not the default mode. Clearly there are plenty of edge cases where scavenging the material makes more sense.

The overall point here is that it asks you if you want to craft a prerequisite and how and it does so until you reach enough things to craft the thing you originally wanted. It also handles all the math and such by automatically dispatching batch crafts.

[ZhilkinSerg]

How do suggest handling of anything besides crafting itself (safemode, monsters, hunger, thirst, light, sleep, etc)? It is not Factorio, so player character has needs and also crafting can take a lot of time.

[DeltaEpsilon7787]

How do suggest handling of anything besides crafting itself (safemode, monsters, hunger, thirst, light, sleep, etc)? It is not Factorio, so player character has needs and also crafting can take a lot of time.

This is a non-issue. Regular crafting handles it already. Again, recursive crafting simply performs several regular crafting in a row. If, at any point, any of them is interrupted, then the material already crafted are dumped into player's inventory or outside and the player has to do it later, but the crafted material is already there so it would simply resume from where it started.

[ZhilkinSerg]

It is an issue. Crafting doesn't handle anything beside crafting and there is a little of automatic needs management - #25400 is not in yet (though #24077 could help a bit) and there are no automatic eating or drinking while crafting. Also #23668 and #25188 are unsolved.

Btw, isn't current issue is a duplicate of #25265.

I am thinking one of the possible solutions could be off-screen crafting - you bunk in safe fortified location, store food/water/fuel/crafting components, select what you want to craft and time fast-forwards until you crafted selected things. This could either be linked to player camp (when npc craft things for you) or be a separate feature.

[kevingranade]

It turns out that one of the very tricky things about this kind of feature is that the crafting menu is currently set up to evaluate craftability of every recipe individually, but making it recursive means evaluating craftability of recipes in groups, which turns it into a much more difficult problem.

Queuing recipes for crafting sidesteps this issue nicely.

[DeltaEpsilon7787]

@ZhilkinSerg

It is an issue. Crafting doesn't handle anything beside crafting and there is a little of automatic needs management - #25400 is not in yet (though #24077 could help a bit) and there are no automatic eating or drinking while crafting. Also #23668 and #25188 are unsolved.

None of these issues appear to cause some irreversible loss of resources other than time. If the lights go out while you're crafting something, too bad, you'll have to start crafting things again (or probably resume the activity if you're lucky), but things you'd crafted already will exist so you don't literally start all over again. Also, while I can understand the concern for satisfying needs during crafting, most players don't usually starve to death or craft until they drop sleeping even when doing a prolonged craft, like most forging recipes. In short, I simply don't see how this issue brings any new problems that are not already present for regular crafting.

Btw, isn't current issue is a duplicate of #25265.

This particular issue is a bit different. In it, he suggests to highlight recipes that can be autocrafted. This is a hard problem that suffers from combinatorial explosion, making it not especially useful UNLESS we implement a weaker version that sidesteps the hard part. There are simply too many ways to skin a cat. My suggestion only deals with autocrafting -- the player must decide on the basic resources and tools used themselves. Again, this is nothing more than performing several crafting actions in a row. It's not like batch crafting -- you make one craft technically, but it yields several results -- it's several batch crafts in a row. If any of them fails, the whole chain is stopped and you need to try again.

@kevingranade

It turns out that one of the very tricky things about this kind of feature is that the crafting menu is currently set up to evaluate craftability of every recipe individually, but making it recursive means evaluating craftability of recipes in groups, which turns it into a much more difficult problem.

As explained above, you don't need that.

Queuing recipes for crafting sidesteps this issue nicely.
Exactly. The player gets to decide what to craft. If they run out of material mid-craft, it's their fault.

So ultimately, while a full-on Factorio-like system is desirable and in my experience with Bob&Angel, even with a crap ton of recipes it all runs smooth as butter, a weaker variant of it may also be appropriate for the time being.

Incidentally

but making it recursive means evaluating craftability of recipes in groups, which turns it into a much more difficult problem.

Depends on the implementation. If we're going for a full implementation, then yes -- most recipes have many ways to be crafted, leading to a combinatorial explosion in complexity. Quite a fair bit of recipes allow to use various tools with charges, further complicating the problem, not to mention a risk of failure during crafting. Even current iterative system can't handle a recipe like "1 A | 1 B = 1 C" when you have both A and B in batch crafting -- only one path is selected for batch crafting even if you can pursue both.

However, you don't necessarily need to consider the whole thing -- simply recursively expanding the set of ingredients into flattened set of sets would work just fine to tell the player that they have the necessary resources at hand, but not specifically enough to actually succeed.

[Human-Shield]

Another reason to move towards a project crafting system.

Any item that takes over an hour could be done through marking a space as a project and when examining it, it checks the surrounding tiles for resources (and recursively for crafting subcomponents). This does it just for what the player wants to consider making in the future (not every item in the menu) and only when the player examines one project at a time. And does a better job saving progress and letting players spread effort over multiple days.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions. Please do not 'bump' or comment on this issue unless you are actively working on it. Stale issues, and stale issues that are closed are still considered.

[stale]

This issue has been automatically closed due to lack of activity. This does not mean that we do not value the issue. Feel free to request that it be re-opened if you are going to actively work on it