Describe the bug
I have installed a FOODCO Kitchen Buddy and 60L tank on the same tile, along with a water faucet that I use to access said tank. When using e -> d to "have a drink", I get the message "You can't drink it while it's frozen." However, I can still use e -> c and fill containers with this same water.
To Reproduce
Steps to reproduce the behavior:
e menu, try to drink it directly.e menu, try to fill a container.Expected behavior
Both actions should be consistent, either both resulting in frozen message, or both working as normal.
Versions and configuration(please complete the following information):
So this is actually related to #25056 as well.
There's a semi-easy, gross, fix which involves just checking if the item is frozen before checking if you can pour it. I hate this because it makes the code more fragile and is prone to error.
There's already checks for things like "itype::phase" == "liquid". In an ideal world, making something frozen would change the phase to solid so that it just does the right thing in all cases. The problem is that item type is not mutable at runtime, so you can't change the phase type of an item.
There's a couple different ways to fix this, some of varying degrees of intensity and complexity. I'm not sure yet what the best way to go about it is, so that's why the behavior is kind of weird here.
Introducing: phase changes from gas to liquid to solid with thousands more lines of code for all the ways we need to change phase! :wink:
Step 1: Find a Finite State Machine Library
Step 2: Consult with physicists to obtain full list of state transitions for all materials
Step 3: Enumerate each state in FSM
Step 4: Find out on merge that a new object dependency has invalidated the FSM handlers for this library
Step 5: Find another FSM library and tie it into the rest of the project
Step 6: Test, literally every object in the save immediately turns to gas on the first tick thanks to a bug
Step 7: Fix that bug with two hundred lines of code additions handling a weird edge case on plasma transitions
Step 8: Decide to add crafting transitions to the FSM because the end result will be cleaner
Step 9: Merge master branch, an intervening PR has removed all liquids from the game, making your code useless
Step 10: Retire and become a hermit
Not sure if there's a joke here that's going too far over my head, but to clarify I'm not suggesting modeling phase states for all materials. I'm simply suggesting changing the way the data-structures are organized so that you could specify a different state. We've already done the hard part of figuring out when/how something freezes, now we just need to fix other parts of the model that can take better advantage of the code we already have.
Most helpful comment
Step 1: Find a Finite State Machine Library
Step 2: Consult with physicists to obtain full list of state transitions for all materials
Step 3: Enumerate each state in FSM
Step 4: Find out on merge that a new object dependency has invalidated the FSM handlers for this library
Step 5: Find another FSM library and tie it into the rest of the project
Step 6: Test, literally every object in the save immediately turns to gas on the first tick thanks to a bug
Step 7: Fix that bug with two hundred lines of code additions handling a weird edge case on plasma transitions
Step 8: Decide to add crafting transitions to the FSM because the end result will be cleaner
Step 9: Merge master branch, an intervening PR has removed all liquids from the game, making your code useless
Step 10: Retire and become a hermit