Resolved [1.5.0] Loading different autosaves results in same game state being loaded.

[Apocal]

Summary: When loading to avoid a player KO result, the game returns to the immediate post-KO autosave situation even from older autosaves which never involved the battle.
How to Reproduce: Get knocked out during battle to some bull****, retreat and then try to load from the second or third oldest autosaves. Despite the timestamps being well before, it will be post-battle, player KOed in all three saves.
Quest/Settlement Name (if related): N/A
Media (Screenshots & Video): None
Version: 1.5.0
Installed community-made modifications: None.
Computer Specs:
OS: Windows 10 Home
GPU: NVidia GeForce GTX 860M
CPU: Intel(R) Core(TM) i7-4720HQ CPU @ 2.60GHz (8 CPUs), ~2.6GHz
RAM: 16GB
Motherboard: VN7-591G
Storage Device (HDD/SSD): Samsung SSD 860 EVO M.2 1TB

 

[elysebluemoon]

Hi, the time stamps of older save files have been zeroed out, but the new save files won't be affected. Can you check these save files? If this isn't the issue, please upload all autosaves to upload.taleworlds.com. Please paste the link to this thread in the description box on the upload website so I can identify it.

 

[Apocal]

Done.

It isn't the issue with time stamps, this was on a fresh 1.5.0 playthrough, no mods.

 

[elysebluemoon]

Forwarding this issue to the QA team for further investigation. Thanks for reporting.

 

[Apocal]

Forwarding this issue to the QA team for further investigation. Thanks for reporting.

Hey, this is sorta embarassing, but I think I figured out the issue. The game autosaves periodically, even if the world map is paused. Usually when I'm taken out by javelins, I simply alt-tab out and do something else for an hour or two and this is probably why the old autosaves -- from before the battle and my KO -- are overwritten.

But the timestamps aren't changing to reflect this.

 

[elysebluemoon]

I've forwarded this extra info as well, I will update this thread when I hear back from them.

 

[elysebluemoon]

The developers tested this as well and could not find a bugged situation. Marking this thread as solved, thanks for reporting!