Food preparation overhaul - Discussion and design

[oosyrag]

Is your feature request related to a problem? Please describe.

Organizing thoughts on a potential new cooking system. Open for discussion and ideas of course. I'm unlikely to have the ability to implement this myself. Roughly similar to Project Zomboid cooking, for those familiar with it.

Goals: Compatible with existing recipe crafting system Add flexibility when cooking, to allow for cooking outside of rigid recipes Reduce bloat of existing recipe system, especially minor variations of the same thing Allow for passive cooking of prepared dishes over time, similar to boiling water, making charcoal, or burning wood

Gameplay: Granular cooking by cooking method + ingredient will allow for creation of generic dishes. Separate interface from crafted recipes, but if method and ingredients match an existing recipe, will result in the recipe output. Generally lower hapiness/morale for results than recognized pre-cataclysm recipes, but allows for more flexible bulk crafting with available ingredients for calorie gains over unprocessed ingredients.

Solution you would like.

Enter new cooking interface

Select cooking method, based on available tools. For example:

Grill - open fire and skewer Stew - pot, fire, and water Pan fry - pan, fire, and cooking oil Sandwich - with knife and bread Bake, boil, ect.

Select core ingredients to add (up to available volume limit per cooking method?). Sorted by category, and only viable ingredients per cooking method available to choose from. Variable calories based on what gets added, generally more than raw ingredients. Portions can also be dynamically adjusted based on total calories of dish for reasonable eating.

Select viable seasonings/condiments to add per cooking method. Generally for minor morale boosts, diminishing returns (maybe negative returns even, if too many are added).

Batch crafting amount, if multiples are detected to be available to be made based on selected ingredients.

Dialogue to "Start cooking now and wait until complete?" - Similar to existing system, where you sit for an hour and watch soup boil. Alternatively you'll get an uncooked/prepared item that can be cooked passively. Variable prep/cook times based on ingredients or cooking method. Cook time can also be a range. For example, a stir fry will burn quickly after becoming cooked, but a soup may have hours of leeway between cooked and dried up/burnt. However, a stir fry cooks quickly, and is a good candidate to use the auto cook/wait option, while a soup might take hours, and be more suitable for the passive cooking option to multitask. Something like sandwiches would not have a cook time outside of preparation at all (Cereal + milk in a bowl? Would cereal count as a stew? 🤔 ). Passive cooking can use a similar mechanic to boiling. Alternatively, perhaps it could use something similar to the campfire/wood burning mechanic, with the item having multiple potential stages from raw to cooked to burnt to ashes. Set that kitchen timer!

If ingredients match existing recipe, end result will be same as recipe food, otherwise turns into cooked generic food. Recipes can still be crafted via the crafting menu, and recipes should generally give more morale than generic food for pre-cataclysm civilization nostalgia. Recipe list can be culled of all the boring stuff/minor variations.

This system could also potentially integrate with the existing system via bulk food prep of intermediate ingredients, like cooked rice/pasta or baked bread ect. to be used in recipes.

Describe alternatives you have considered.

Unfortunately this will add yet another layer of UI bloat, which I am not a fan of. For example, constructing and crafting being separate, or multiple ways to dissassemble/cut/butcher an item. However, there are some advantages, as the crafting interface by itself is a bit overworked/bloated, and this could potentially cull a lot of redundant recipes.

Additional context

No response

[Maleclypse]

Hey there, this would be a major overhaul and many of the things you've discussed here are desired outcomes. This would be a pretty major overhaul so probably the best way to really approach it would be to divide it into a project plan and then create the PR with the first steps. So from reading this it looks like first thing would be to create the PR to add genericized cooking without recipes. Maybe even as a tab inside of the crafting menu. Once that proposed PR doing just that was up and to be reviewed I believe you'd get lots more feedback. That will also help guide the directions on what happens after like adding passive cooking etc.

[Maleclypse]

I've currently marked it as project freeze but if you broke it up into digestible single PRs that each approached one new thing they might not need to be project frozen. But if you created a PR that did all those things in one go it would be too large to review and held up by project freeze. Does that make sense?

[oosyrag]

Sure, makes a lot of sense! It will be a while before I dig into this so I didn't have expectations of pushing something for 0.G, but I did want to get my ideas down in writing. I haven't even really decided how to approach this yet as there are multiple potential systems involved. The project plan will follow after I familiarize myself more with the existing code and think of how best to break it down into smaller tasks.

Also I'm also basically completely new here so I was fishing for comments or existing ideas from people who had more experience with the game and may have thought about similar things as well. But working from a clean slate without conflicting ideas can be nice too.

[Croisis]

Could you maybe consider JSONising the basic support for passive cooking/crafting as one of the first steps please? AFAIK there is currently only the water boiling available in that regard and that is also hardcoded in C++.

It would be great to have a working (semi?) passive system for that in general, not just specifically for cooking. Some chem crafting comes to mind as well, maybe also forging etc...

Even the existing charcoal production is a huge clickfest with the 4 stages, delayed_transform and manual disassembly... The system you proposed would work great for that I think as it is basically the same usecase just with one more step.

Edit: I've just noticed that there is a similar open issue for this passive crafting part mentioning tea #56095

[remd]

Could you maybe consider JSONising the basic support for passive cooking/crafting as one of the first steps please? AFAIK there is currently only the water boiling available in that regard and that is also hardcoded in C++.

It would be great to have a working (semi?) passive system for that in general, not just specifically for cooking. Some chem crafting comes to mind as well, maybe also forging etc...

46775 addresses the desire for unattended crafting.

[DIBAOS]

Maybe we could make it easier? For example, we could just put ingredient and water in one pot on a fire and await it to cooked, or bake food directly over fire if we have rack so don't need to hanle it, these can be done just by actions without any recipe. But something which has complex or difficult food recipe is not suitable in this way, such as cooked organ.

[Croisis]

Well there is the obvious technical issue that you can't mix liquids and solids in one container, preventing the most intuitive and UI-friendly approach of grabbing a suitably large container for your desired end product, stuffing it with whatever ingredients you want to cook and placing it over the heat source. Simple stew-like recipe type of thing. Works for tea, broth, soups etc, stuff you don't need to sit and watch bubbling.

No batch timing issues either, if I want to cook 600 portions of broth I need for a full batch of 50 3L glass jars of soup I'm about to make, I'd just grab a 200L drum for it and be done with it in one go, thank you very much. Simple time calculation as well as it basically becomes the matter of adding the required amount of energy to the mix, technically speaking. And it is not just for this type of recipes either, think meat confit for example - the meat needs 5 hours of slow cooking, so a batch of 50 portions should really still need just about 6 hours tops, not 2 days plus (if you have suitably large container for it to be done in one go ofc).

I mean am I the only one with for example the x12 broth and x10 tea recipes in my private tweaking mod because I got tired of the tedium it otherwise is?

[oosyrag]

My plan was to first craft an intermediate "uncooked" state of an item, which would be the mixed solid/liquid if the type of cooking calls for it.

This item can then be progressed to cooked/hot/burnt with the proper heat source passively over time.

Alternatively, the option to immediately wait/auto cook until done will be available if the player wants, preventing multitasking but also preventing burning. This would be similar to how it is now, with the bonus of possibly performing maintenance tasks when they are implemented.

Also, skewered grilled/roasted chicken gizzard or liver can be delicious with a little seasoning and doesn't really require any recipe. Mmmm churrascos.

[Croisis]

The first uncooked stage is probably something that will be needed anyway to represent ingredient preparation if nothing else. But the thing is that the UI for it will probably end up kind of clunky if the goal is to allow more flexibility, don't you think? I.e. havig a stew with some kind of meat type (or five), several types of veggies and spices plus (clean) water and maybe salty water as well to stew it all in. That would require quite complex UI system to do intuitively, or a lot of iterative steps for each ingredient causing a lot of overhead. That's why I mentioned the idea of grabbing a container and stuffing it with whatever is desired to be used in the recipe as step one and processing it based on the contents. Maybe it could still work as one prep step for the solids with adding the liquids as additional one?

Also as it was mentioned in the #46775 discussion, the fun part would then be to ensure that the heat source (or processor in general) is actually blocked by the crafting process. Having a 1000L brazier with fire burning all day long makes it easy to fit whatever you want to cook in any quantity but the uncooked state should be able to be handled by a vehicle-mounted heatplate as well, which would be a lot trickier to do.

[Croisis]

As far as the vehicle-mounted cooking tools (or appliance for that matter) are concerned I'm not too sure what would be the most appropriate way to handle the requirements code-wise as I haven't mustered enough courage to actually set up the Visual Studio and dig through the code yet (I'm a Java dev and it has been years since I've so much as touched C++, plus learning a new IDE and the fun it entails... meh 😉).

Anyway, do you think it would be feasible to implement the existing transform use_action for vehicle parts as well without too much hustle? I'm thinking of the possibility of basing the passive recipe processing on a set of new flags and handling it via the existing framework used for battery recharging (if there is one that could be repurposed in the first place?). So basically the same way the items with "RECHARGE" flag are affected one at a time by the charger, the passive crafting would be done by applying craft percentage increasing effect based on another set of flags defined by the recipe. Heat can have multiple types or qualities with various effects. Open fire risking burning the food if you leave it there for too long or just randomly by simply beeing too hot if you would be inclined to be a little bit malitious with the implementation. Electric oven or hotplate would have a regulated output and no risk of burning the food by using a timer to switch it off. If you would like to have fun with it, the same uncooked input could even yield different results based on the flag type actually used to finish it... like trying to bake a cake on a pan over an open firepit vs in the electric oven.

Thoughts? Is this passable or is it going too far?

EDIT: I forgot to explain why this requires the transform use_action in the first place - to switch the desired mounted processing tool on and turn in into a different item with a different set of properties, item flags and power output for the overall time calculation. Open fire would always have the HEAT_FIRE flag but you would need to turn the hotplate on to get the HEAT_HOTPLATE effect with the transformed part missing the hotplate pseudo tool - effectively blocking it for all other purposes.

The added benefit of enabling the transform action for vehicle parts would be that it would also enable various convenient features for the vehicles in general like lift axles and all kinds of foldable stuff from solar panels to a folding bed turning into a table while using the existing interface to manipulate with them.

[Sathra225]

So an oven or hotplate would work something like a smoking rack does now? So put in a "prepped dish (raw)" and start, gives a time until done, and at the end of the time, auto-ejects the product into the inventory of the fake_item doing the cooking? Hopefully in the 'working' container if liquid. Then non-electric heat sources do the same thing, but the fake_item starts another timer till it burns/ruins whatever is on the tile. The other cooking steps like bread-proofing are more like fermenting products/tanning instead? With generic heat-cooked recipes being like 'meat stew' (broth + flour + meat + 2 veggy types) for the prep-stage and inheriting values from the inputs, with the result quantity being based on one of the inputs quantity or total sum volume/servings or something? Thinking through how it might work.

[stale[bot]]

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.

[Night-Pryanik]

Closing as stale, since stalebot can't do it by itself.