Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

(cool) Food stacks [E]aten from a fridge gets placed in player inventory and immediately spoils #58824

Closed
descan opened this issue Jun 29, 2022 · 5 comments · Fixed by #60952
Closed
Labels
(S2 - Confirmed) Bug that's been confirmed to exist

Comments

@descan
Copy link
Contributor

descan commented Jun 29, 2022

Describe the bug

When eating certain foods (it doesn't always happen) that are being cooled in a fridge, if the item is in a stack the item is taken out of the fridge and placed in the players inventory after the first item is eaten. Thankfully this first item doesn't get immediately Rotten, but (especially after leaving the Eat menu and going back in) the foodstuff in the players inventory is suddenly rotten.

Steps to reproduce

  1. Have a fridge with cool food stacks (past their "expiration" date?)
  2. Attempt to eat them
  3. See them placed in player inventory
  4. (Possibly): Leave Eat menu, go back in to Eat menu
  5. Whoops it's all rotten suddenly, guess you shouldn't have taken it all out of the fridge, dumbass

Expected behavior

I expect my character to be smart enough not to dump this big stack of tomatoes or meat in their inventory if they're gonna just eat one.

Failing that, I expect a stack of food that's maintained chill-freshness to not immediately, 1 second later, spoil after being taken out of the fridge - a couple of minutes at least before all the bugs descend on it, no?

Screenshots

No response

Versions and configuration

  • OS: Windows
    • OS Version: 10.0.22000.739 (21H2)
  • Game Version: cc52f60 [64-bit]
  • Graphics Version: Tiles
  • Game Language: System language []
  • Mods loaded: [
    Dark Days Ahead [dda],
    Disable NPC Needs [no_npc_food],
    Bionic Professions [package_bionic_professions],
    Blaze Industries [blazeindustries],
    Alternative Map Key [alt_map_key],
    Translate Complex Dialogue [translate_dialogue],
    SpeedyDex [speedydex],
    Stats Through Skills [StatsThroughSkills],
    Generic Guns [generic_guns],
    sees-player, run, crouch, bleed icons, retrodays [sees_player_retro],
    Tamable Wildlife [Tamable_Wildlife],
    No Fungal Growth [no_fungal_growth]
    ]

Additional context

Fridges as a whole seem to behave weirdly, and I can understand if food being good for weeks past their spoil time, almost being in stasis-lock, is not exactly desired. That being said, it's a little silly if you can ruin entire stacks of food by trying to eat one of them, when a sensible person (given the information of "hey if I take ALL this stuff out of this weird refrigerator, it'll immediately go bad") would just... not take the entire stack out of their Magically Preserving Fridge.

I'm also not entirely sure what the cirumstances are where the food is taken out. Food in a container will remain in the fridge. A stack of crops I had also remained in the fridge. But I know it happened with an item of curry. In my current save, I can't actually replicate this behaviour, so I'm not sure what's going on or in what situations the character will grab the whole stack.

@descan descan added the (S1 - Need confirmation) Report waiting on confirmation of reproducibility label Jun 29, 2022
@PatrikLundell
Copy link
Contributor

It's certainly the case that there are weird cases of food reporting to have a decent time left while in a fridge spoils immediately it is removed.
The intended logic with fridges is that they'll slow the spoiling rate of food, so that milk will last a few days in the fridge, but spoil before the afternoon if in the middle of summer.
What I think happens with these weird fast-spoiling cases is that the decay timer isn't recalculated when the food is removed, so when the age is checked against the creation date the logic finds that at the ambient temperature it should have spoiled a long time ago..
What's needed is to keep track of the progress of the decay as conditions change and have a time stamp for the decay at the time of the last change. You probably don't want to update this for every item sitting in a powered fridge or in a root cellar every time the game accesses them, but you don't want to see that something that had several days left in the morning suddenly is rotten when you wanted to eat it for lunch because the noon temperature is a lot higher than the morning one.

@Kiael
Copy link

Kiael commented Aug 29, 2022

This issue continues to make using fridge appliances very frustrating. Only work around for now is to just never remove anything from a fridge once you put it in there and to only use anything within it as ingredients for cooking nearby.

@Stadler76
Copy link
Contributor

/confirmed with a freezer
Took out fresh frozen meat and it was insta rotten.

@github-actions github-actions bot added (S2 - Confirmed) Bug that's been confirmed to exist and removed (S1 - Need confirmation) Report waiting on confirmation of reproducibility labels Sep 11, 2022
@robob27
Copy link
Contributor

robob27 commented Sep 12, 2022

I did some testing with this. I think it has something to do with items in the fridge not getting properly loaded into the reality bubble for processing after a save/load?

  • I spawned a fridge/supporting appliances and 2 chunks of meat. I labelled one "test meat" and one "control meat"
  • I put "test meat" in the fridge and "control meat" on the ground
  • I added some debug messages to print when rot is updated for items. Before save/load, I was able to see both "test meat" and "control meat" having their rot values updated as I waited with the items in the reality bubble:

image

  • After save/exit/load, I now see only "control meat" having rot values updated even though "test meat" still exists in the fridge in the reality bubble:

image

  • I added some additional information to item debug to make it easy to see the amount of outstanding time to process on an item. Here is the output for "control meat" after waiting a bit:

image

Here is the output for "test meat":

image

We can see "test meat" somehow has 4 hours of time to process even though it was in the reality bubble. As soon as you take it out of the fridge, it simulates all of that time in the conditions outside of the fridge and rapidly rots the item:

image

Here is the branch with the changes I made to display the debug info/messages shown above.

It looks like specifically this loop isn't happening for items in vehicles after a save game is loaded. You can verify this by:

  • Setup a fridge with an item in it and a control item outside of it
  • Set a breakpoint inside that loop
  • Wait and see that the breakpoint is being hit
  • Save/quit/load the game
  • Wait and see the breakpoint is no longer being hit

So whatever is populating the item list that is used by cur_veh.active_items after loading a game. Just continuing to add any details I find until I either make it real easy for someone else to solve or end up solving it myself 😅.

@robob27
Copy link
Contributor

robob27 commented Sep 12, 2022

I was able to isolate when the vehicle loses the active_items after a load. It happens after this vehicle::refresh call in vehicle::deserialize in savegame_json.cpp.

By moving the manual backfill of the active_item cache to after that refresh, the items in the fridge now get processed as expected after a save game load.

I don't think this fix alone would do it. Presumably if refresh is called again later, it will break the active_item cache again for that vehicle. Maybe refresh itself should handle backfilling the active_item cache after processing fake parts?

The specific part of refresh that seems to cause this is this part here that adds fake parts (commenting it out also makes items in fridges get processed as expected after a save game load).

I think this bug was introduced when we added fake parts to vehicles.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
(S2 - Confirmed) Bug that's been confirmed to exist
Projects
None yet
Development

Successfully merging a pull request may close this issue.

5 participants