As per title. There might be other water collecting containers applicable to this change. If anyone finds them, please comment them to get included.
Braziers, clay pots,
Problem with this approach is that every item needs a separate trap entry.
Do you have the inclination to replace the trap code with something better?
I believe the only reasons that buckets can't collect water is that it isn't resealable and isn't watertight. If you were to store a bucket of water inside your backpack similar to a water bottle, you would obviously lose the water because the bucket can't be sealed. For the instance of wielding the bucket, it would be plausible that you would want to fill it with water even though you can't store it for later use unless you set it down.
It would be better if there was some way to get funnels to fill buckets as with any other container. This might require first finding where the "is container valid for filling from funnel" code is, then determining exactly what all other functions are affected by any changes to it.
If multiple fluid functions are dependent on the same section, and enabling buckets farther down the code chain is not possible, it might possible to enable buckets at the origin of the issue, then specifically exclude buckets farther down the code chain in all cases except when it should be allowed. This would be more tedious than difficult, but possibly less hassle than untangling funnel code from being dependent on a check that might cause regressions if fully changed.
Making them collect water on their own would be interesting but harder to implement, and in practice you would want a funnel anyway as buckets would likely have a smaller collection radius.
I believe the only reasons that buckets can't collect water is that it isn't resealable and isn't watertight. If you were to store a bucket of water inside your backpack similar to a water bottle, you would obviously lose the water because the bucket can't be sealed. For the instance of wielding the bucket, it would be plausible that you would want to fill it with water even though you can't store it for later use unless you set it down.
Why not dump the water out of the bucket when storing it in inventory an inflict a wetness penalty on the character?
On Dec 13, 2016 8:57 AM, "BorkBorkGoesTheCode" notifications@github.com
wrote
Why not dump the water out of the bucket when storing it in inventory an
inflict a wetness penalty on the character?
Because we want the player to discover this limitation as soon as possible.
Ambushing them with it after the fact for an action they, "should have
predicted" isn't nice.
My assumption when I read the comment by @BorkBorkGoesTheCode was that they were proposing the ability to set "bucket of water atop an open door" pranks,
My assumption when I read the comment by @BorkBorkGoesTheCode was that they were proposing the ability to set "bucket of water atop an open door" pranks,
No. It seemed reasonable to dump the contents of a full bucket if it was wedged into a backpack without sealing it first.
That was mainly a joke based on my first read of it, actually. The actual idea would likely be a bad idea unless it was made overtly clear to players that the container is not resealable.
I can see this idea being terrible (regardless of how clear bucket status is made) in the event the player accidentally spills a bucket of concentrated acid all over themselves.
Well, i thought that the obvious use for this is to 'Set' the bucket outside to collect rain water and leave it there. A bucket of water isn't the most portable of water sources but if can "Use" say, a bottle, on it... then it kinda acts like a mini-well. Way I've seen this used IRL when it comes to rain water collection, is that there'll be several buckets and vats on the ground and when the rain stops, the water is then hauled to a tank or water barrel.
I don't know much about coding, but it does sound like it could complicate whats already there. To add to that, as I observed in the previous issue, finding a hacksaw and scavenging tanks from cars is not all that hard.
Seems the consensus I'm seeing is that "It's a good idea, but too hard to implement.". Personally, I'd have loved to see this implemented as it might open the doors to other "Set" appliances to add more realism in place, like 'Set'ing a turret, man I'd LOVE that. :D
But I still get the difference regarding usage vs. coding efficiency argument, so I defer this to you devs. :)
EDIT: Grammar fixes.
One of the main issue with this is the distinction between resealable and watertight and the fact that many part of the code rely on a function that checks for watertight which in turn determine that something is watertight by checking that something is resealable and watertight.
Here is a thread about it from a few months ago: http://smf.cataclysmdda.com/index.php?topic=12566.msg274480#msg274480
I suggested this be raised as a separate issue from #19715. (There are some initial notes of mine there that are relevant to what @DangerNoodle mentioned in their first comment here.)
As @remyroy highlights, the watertight/seals checks "grew organically", with is_watertight() checking for both container->watertight and container->seals (which seems confusing to me now); and is_bucket() checking container->{watertight,!seals} (along with a check if it isn't an open-once can).
As mentioned in #19715, I might look into both of these issues, if there's agreement it shouldn't be left as-is.
To clarify, we have two functions checking items for sets of properties. What I propose is refactoring them into two or three different functions that check for one property each. It will be easier to reason about containers then in issues like this and #19715.
Closing due to 5 months of stalled discussion. @keyspace you were the last to exhibit interest in this, if you (or anyone else) still wants to pursue, let me know and I'll reopen.
Most helpful comment
Problem with this approach is that every item needs a separate trap entry.