Implement a game entity that encapsulates a partially-completed crafting activity.

[ifreund]

Once that is done, it becomes feasible to greatly extend the time required to craft clothing.

Add a new craft item to store the recipe and a list of the components, which will be removed from the game world upon starting the craft (this will fix all the bugs with components disappearing).

• component list goes in components
• batch_size goes in charges
• recipe goes in a new const pointer
• progress goes in item_counter
• tools are already cached in last-recipe for use with long crafting. Should be able to use that.

I will also create a new player_activity to work on this craft which can be started by activating the item. This activity will check each turn for the required tools, fire etc. and consume charges incrementally throughout the crafting duration. Progress percentage or equivalent will be stored in the craft item.

Starting a craft and creating this item will automatically start the activity. It can be interrupted at any time because everything important is stored in the item.

Note:

• I don't intend to touch craft times yet, those can be extended in follow up prs.
• This should make enabling npc crafting fairly trivial.

[I-am-Erk]

I think it should be implemented for everything, because even though not everything should have the "stop crafting and return to it later" mechanic, (eg clean water) the same "percent crafted" thing could be used to make some things start crafting and return later. Set up a pot of water to boil and return when it hits 100% crafted.

[ifreund]

Yeah I agree, I was originally worried about tedium then just realized That I can just auto start the activity when one of these in progress crafts is created.

[I-am-Erk]

I'm very excited to make things like custom built medieval armours represent a realistic time investment. It will dramatically shift the game balance.

[kevingranade]

I'd like to avoid subclassing item if possible, extensive subclassing/inheritance is a problem we've mostly avoided so far, and I'd like to keep it that way.
Crafting components can go in item::contents, and I'm sure we can shim in anything else we need elsewhere (if nothing else as a normally-null sub-object referenced via a unique_ptr).

[ifreund]

Alright yeah looking at this closer there's really no need for a subclass. item::contents is fine for the components. The other two things I really need to store are the recipe and the progress. I think the recipe will have to be stored as a unique_ptr, but I can use item::item_counter to store the progress.

Edit: forgot about batch_size, but I think it might work really well to store that as charges.

[aawilson]

Anything that might need to be puzzled over to support more complicated structure later? Like, for instance, a multi-stage recipe that has periods of active work and periods of inactive percolating? I'm excited to see a recipe for pemmican that's not 3 hours of actively standing over a charcoal smoker, or to see the end of "activate the tanning hide to unroll it".

[ifreund]

Anything that might need to be puzzled over to support more complicated structure later? Like, for instance, a multi-stage recipe that has periods of active work and periods of inactive percolating? I'm excited to see a recipe for pemmican that's not 3 hours of actively standing over a charcoal smoker, or to see the end of "activate the tanning hide to unroll it".

Yes this would make that much easier to implement. No, I'm not going to plan around or even think about it at this stage.

Definitely something I'd be interesting in doing eventually though.

[ifreund]

Decided to move the long term plans to #29210 since the original note was just for a craft entity with present mechanics