Can use full/partially filled containers to boil water

[niglow]

0.C-21983-g9432266174

Get a sealed tin/aluminum can or a glass bottle with alcohol from the nearest grocery store, also get an empty container without "boiling" quality and start a fire near a source of water. You'll be able to use the full can/bottle to boil water.

[Coolthulhu]

Can reproduce.

[bdgackle]

I'm going to miss this bug when it gets fixed, because I exploit the hell out of it, but yes, can confirm -- you can store water in a container you are using to cook with.

There is an element of realism here, though, since in real life, you'd fill the pot up with dirty water, and end up with a pot full of clean water afterwards.

That is probably how this should change -- boiling water from whatever source should get you a pot full of clean water. You shouldn't need a container of dirty water, a container for clean, AND a third empty container to boil in.

This has the added effect of giving the player an incentive to find bigger sized pots (and us to add them). Making water in a 3 Gal stock pot should be a more pleasant experience overall than doing the same in an empty aluminium can.

[lcy03406]

Boiling water should be similar to charcoal making. You setup a cook of water, lit it, and wait it to boil.
In addition, instead of clean water I'd love to see a pot of boiling water, so that I can cook meat in "hot pot".

[niglow]

It'd be very authentic to be able to leave a pot on the fire and come back after a while only to find that all water has evaporated or that your precious soup has burned out.

[bdgackle]

One concern to add: you have to boil several units of water per day to survive. If we increase the realism thing, we could accidentally add lots of tedious keystrokes to a game element that is already a little bit tedious.

Maybe the correct behavior here is to leave the "pick a container for clean water" menu as it is. We require either an empty container with boiling, or that the dirty water is already in a container with boiling. The container used for boiling would then show up afterwards in the "pick a container menu".

This would require that the player's character has to behave logically (by placing dirty water in empty container, boiling, then either leaving water in the pot or storing somewhere), but the player just has to make sure the right materials are available. No keystrokes are added. Also, the only code changes would occur at the materials check, so it would be less complex to implement.

[Coolthulhu]

Edge cases:

• A tool loaded with an item should work (as in, be usable for crafting)
• A container loaded with contents should not work

So, can we assume that a tool will never be a container?
If not, we either need to allow all tools that are containers in crafting regardless of being filled or not or invent some new distinction. Disallowing (all) loaded container-tools from crafting is not an option.

[kevingranade]

So, can we assume that a tool will never be a container?

No, counterexamples include rice cookers and crock pots.

However, we can instead assert that none exist in a unit test and have it point to the code that relies on this distinction.

invent some new distinction

Such as an "empty container" property.

[Coolthulhu]

No, counterexamples include rice cookers and crock pots.

That complicates things quite a lot since it means we can't rely on contents alone for containers, need to reinvent contents for tools, or need to flag contained or "connected" contents as such.
At the moment contents handles both container contents, gun gunmods and magazines, tool magazines (if applicable).

Current code will not handle tool-containers at all, if possible I'd push it as a post-0.D thing because this is certain to delay 0.D otherwise.

[SpencerMichaels]

I haven't looked at the item code specifically with reference to this issue, but I've touched it when making some modifications to the reloading code. My impression is that whatever way we can get the current system to exclude this case while also handling things like crockpots etc. would require some pretty weird hacks. I'll see what I can do about this, although it looks like lots of people have tried already. Maybe: container considered empty if: contents is empty OR ( it is a tool AND all of its contents are of types that it uses as fuel, e.g. batteries ).

In the long term — probably after the 0.D release — what about reorganizing the Item class so that it has nullable sub-components corresponding to the islot_* types in itype.h? Right now it's a big monolith as far as I can tell, but if items actually had separate Tool and Container components that knew how to manage their own related functionality (e.g. myItem.getRangedWeapon()->getMods(), myItem.getLiquidContainer()->capacityForLiquid(my_liquid), myItem.getTool()->getCurrentCharges() > 25, etc) this check would be trivial. From a cursory glance, it looks like a lot of the item code is not intertwined between components — e.g. all the tool handling stuff in most function is in an if (is_tool()) {...} block) so this may just require moving code around more so than rearchitecting anything major.

EDIT: I made an attempt at a fix in #22530, although it's a slight hack/exception.