In-game time is not persisted correctly by first save/load

Ziphilt commented 3 years ago

Cities Skylines version 1.13.1-f1 No DLCs The only mod subscribed is RealTime version 1.20.3.0

This problem might be the same as the one described by this Steam user: https://steamcommunity.com/workshop/filedetails/discussion/1420955187/1835685838071573184/ You answered at the time that it is probably due to an incompatible mod and the user seemed to fix their issue, but I'm having this issue with no other mods installed.

This issue only happens when RealTime is enabled and I start a new game, save, and load it again. Later saves and loads appear to work as expected.

Steps to reproduce

Start a new game. In-game time is set to today's real date and a fixed morning time (06:00 on my system) configured by RealTime. Note the real world time. Suppose for example it is 12:00.
Keep the game paused, and wait a few minutes.
Save the game, quit, and reload the save.
In-game time is now set to the local real-world time, as of when the game first loaded the map (12:00 instead of 06:00).

Another test case

Start a new game. In-game time is as before (06:00). Note the real world time. Suppose again it is 12:00.
Unpause the game and let the simulation run for a set time, say exactly 1 hour of ingame time.
Save the game, quit, and reload the save.
In-game time is now set to the local real-world time, as of when the game first loaded the map, plus an offset of exactly 1 hour (13:00 instead of 07:00).

Expected result

I would expect RealTime to persist game time (not local real-world time) on save/load, especially because RealTime makes in-game time significant for gameplay.

It appears that the base game does persist in-game time correctly.

Debugging

I tried my hand at debugging this, and I think I tracked it down to src/RealTime/Simulation/TimeAdjustment.cs. Note that I'm not familiar with Cities Skylines modding or C#.

It appears that this code uses SimulationManager.instance.m_ThreadingWrapper.simulationTime to derive a new value for SimulationManager.instance.m_currentGameTime, as well as values for ticks, frames, and others. I'm not sure what the difference is between simulationTime and m_currentGameTime (I couldn't find anything on the Internet by searching).

The game starts at 06:00 as configured by RealTime, but somehow the real world time at startup is saved instead of 06:00. Perhaps the real world time remains in simulationTime? RealTime never appears to modify that value, only read from it.

It seems that simulationTime and m_currentGameTime move forward together as the game plays, but they are offset from each other on the first run, since TimeAdjustment.Enable() only changes m_currentGameTime (via SetGameDateTime()) if the LoadMode is NewGame or NewGameFromScenario (due to logic in src/RealTime/Core/RealTimeMod.cs).

Given the behavior I'm seeing, I think that m_currentGameTime is lost on save/quit, and the next load retrieves the past value of simulationTime. Since TimeAdjustment.Enable() does not modify the time when loading a save game, simulationTime and m_currentGameTime do not get out of sync in that case.

My guess for a fix is that RealTime should save the change to simulationTime when starting a new game. But that's only a guess, and I don't know whether that is impossible or has other considerations.

I hope that debugging attempt was useful, or at least entertaining :)

dymanoid commented 3 years ago

Thanks for reporting! There should be no issues with persisting the correct time because Real Time merely uses the game's functionality for doing that.

I will look into it.

SuncatStudio commented 2 years ago

Were you ever able to fix this one?

I just recently learned about the Real Time mod and began using it, and really liked it. Then I noticed the time skip reported above. I've run three or four test games now, and can confirm that this bug is still manifesting exactly as described here.

Since it only happens on the first save/reload, I feel I can work around it. But thought you should know.

dymanoid / RealTime