Cannot load save

[hackedpassword]

Is there an existing issue for this?

• I have searched the existing issues

Game Version

build 1008 - 4.12.0.1

Describe the bug

Steps to Reproduce

Manual load of an ongoing game after updating the Unciv apk.

Screenshots

No response

Link to save file

No response

Operating System

Android

Additional Information

If you guys need a save game or anything else let me know.

[yairm210]

What?!
Yes, please provide the game save!
Super weird!

[hackedpassword]

Had to pull this file out with total commander since it won't load. The other saves seem to be fine.

Note I updated from 4.12.0.0 - pretty certain.

Savegame

France - 339 turns.txt

Details

[hackedpassword]

Ugh accidentally touched close comment.

Anyway including the previous save. That will give something to compare to.

Details

France - 338 turns.txt

[yairm210]

@SomeTroglodyte
LastSeenImprovement.readOldFormat is getting a jsonData with real data, but jsonData.get("entries") is null
Putting a breakpoint on LastSeenImprovement.kt:46 and loading the save gets you to the interesting info

[SomeTroglodyte]

Having a class: com.unciv.json.HashMapVector2 part at all without the entries is somehow a contradiction. The old code would write both, and the new shouldn't be able to, as that class path is still a class, but a subclass of the data it writes, not a super...

So a patch might be adding && jsonData.has("entries") to the if on line 31, but I'd rather find out how that unwanted class got in there.

[SomeTroglodyte]

No, can't repro that - I can load turn 338, nextTurn it, and get a turn 339 save that's perfectly fine without the obsolete-class marker. So - do we know the Java runtime that did this or any such details?

[hackedpassword]

In the update period, only sprites changed, no json. history

[SomeTroglodyte]

only sprites changed

Didn't think a mod json change could in any way influence that serialization... But a weird Java classloader might. So which one is it? Android version & manufacturer?

(it's the writeObjectStart(actualType, knownType); call in Gdx Json.java line 508 that decides whether that class annotation is needed - and it shouldn't be, but maybe the java.lang.Object::getClass call a few lines above was weird? The knownType at this point is com.unciv.json.LastSeenImprovement, but maybe getClass failed to produce the correct actualType?)

[SomeTroglodyte]

@hackedpassword I wasn't clear enough - I'm asking which exact platform was the code running when it last saved - the save that was successful but then couldn't be loaded. Android version, mainly major version but maybe also OS manufacturer?

We'll need to know if that can repro on any other platform, beginning with an Android AVD of the same level. Sounds like it cannot. or we would be hearing massively about nobody being able to load their saves??? So far the analysis says it's not specific to your mod!

[hackedpassword]

Running android 12, galaxy s10, ATT model, kernel 4.14.190

Everything stock on this phone nothing fancy no hax/rooting etc.

The save did not cross platforms.

Let me know if there's anything missing.

[SomeTroglodyte]

Sounds good, the one AVD I kept should be enough - but probably not today.

Curious why there's not a lotta more noise, seems only you. Otherwise, that snippet up there ("patch might be adding && jsonData.has("entries") to the if on line 31") would be simple and "can't hurt 'xept perf" and definitely cure your one glitch...

[SomeTroglodyte]

Nope, an API 32 (Android 12L) AVD does not reproduce. Neither with a small vanilla test game nor your Turn 338 then next-turn. Writes without class marker as intended. 🤷

[hackedpassword]

Could be a one-off, perhaps a unique artifact inclusive of your recent save size reduction and solar activity. Since no one else is reporting, I'd say neutrino decay bursts have subsided.

Haven't seen the issue reproduce here either since, all load/save actions seem normal.

btw what did the faulty save produce as a wrong version/build value out of curiosity?

[SomeTroglodyte]

wrong version/build value

None at all, that's just the message it defaults to when an unexpected exception occurs during deserialization