[1.1.56] Failed to load a non-modded save from a supported game version because of a NaN value

[curiosity]

To reproduce, load the attached save.

Expected: the save from a supported version is loaded.

Observed: a so-called "notice" saying "NaN value loaded from input file. File could be corrupted.". Nothing else happens after dismissing the notice.

[curiosity]

Whoever moved this from bug reports to technical help, mind explaining yourself? Or should I repost this in bug reports?

[Stringweasel]

Bug Reporst -> Technical Help -> Resolved

What happended??

I have a save file that is also giving the exact same error message. It was running fine in the previous versions, but it failing now with this new check. I'm not sure what to look out for.

[Stringweasel]

My specific point of failure is:

Code: Select all

  12.086 Loading level.dat: 3949242 bytes.
  12.088 Info Scenario.cpp:199: Map version 1.1.53-0
  12.180 Warning Map.cpp:346: Map loading failed: NaN value loaded from input file. File could be corrupted.
  12.359 Warning Map.cpp:346: Map loading failed: NaN value loaded from input file. File could be corrupted.
  12.387 Error AppManagerStates.cpp:1599: NaN value loaded from input file. File could be corrupted.

[Stringweasel]

Here is the save file.

It's one of my Hall of Fame simulations. It's the map Wube used to create the Trailer in 2014, which was then migrated through all the versions to 1.1. I had to manually delete some files inside the zip when I migrated. I have other many maps that's also *almost* that old, but none of them gives the corrupt error.

I'm just curious if there's some way to fix it without having to try the entire migration process again, which will take many hours. Maybe if I know *why* it fails I could hack it to work again.

[Stringweasel]

Solved. It was a corrupted biter and a corrupted turret. I destroyed and replaced these entities in a previous version (1.1.53) where it still worked, and now it's solved. Bilka helped me determine where the corruption was detected, but you can apparently find the classes where the corruption happened yourself.

if you enable "log-stack-trace-on-non-critical-exception" (in the config/ the rest settings) it'll do that and you can see the classes in the stack trace. Note to disable it afterwards, it's very much a debug option