Cold Bed on Route is updated into v3.08.
Fixed a bug where, upon starting a second or third playthrough after transferring items in and out of containers, the contents of the containers would incorrectly remain in the same state as the previous loop, disrupting gameplay.
This update focuses solely on addressing this relatively severe bug.
We apologize, but if your save data was created in v3.07 or earlier, the affected loop may still have corrupted item states—even if the default values have been reset.
To restore proper functionality, you can either delete the current playthrough from the start options or complete a loop (even if it results in a game over), which will reset the state correctly.
Since this update is brief, we’d like to take the opportunity to explain the bug in more detail:
Each item in the game (whether it’s a girl, a ship, or a metal box) is stored as a single unified data block. This includes data such as weight, durability, and status (e.g., acquired, not acquired, stored in a box, discarded, etc.).
Containers like a metal boxe have an additional structure: inventory data that holds information on what items are stored inside.
When beginning a new loop (either by clearing the game or deleting data from the title screen), these item data blocks are reset by copying values from a predefined set of "initial state data."
However, the issue in this update arose because the inventory data of container items was mistakenly copied using shallow copy instead of the intended deep copy.
To clarify:
A deep copy (the correct behavior) duplicates the initial state data into the container’s inventory data, creating an entirely separate instance—no problems here.
But with a shallow copy (the incorrect behavior), the container's inventory data ends up referencing the same object as the initial data. This means that any interaction—such as adding or removing items during gameplay—would also modify the supposedly immutable initial state data.
As a result, if you continue playing without restarting the game, changes to the container contents directly affect the initial state data. Then, if you begin another loop, the game copies this now-corrupted “initial” data back into the new playthrough—effectively carrying over container contents from the previous loop, which should not happen.
This issue was difficult to reproduce consistently because the likelihood of it occurring increased with each additional loop. Our initial assumption that it would trigger in the second loop caused us to overlook cases where it only appeared later.