[BUG] [PLAYER] Occasional desyncs

[namida]

I've noticed an occasional case where there's a desync between the replay and the ongame state. The desync arises after a backwards frameskip, and often the displayed state can be "repaired" simply by backwards stepping even further.

I haven't tested extensively yet, but I think it's occurring when a skill is assigned precisely on a frame where the level's state is saved to memory.

I also notice that often when this happens, the highlit lemming (if there is one) gets changed and/or unmarked (still functions as highlit, but no visible indicator of it).

Once I find the source of these, I'll release a V1.43n-B update (identical to V1.43n apart from fixes to these bugs, so no physics changes) that addresses it.

[namida]

Did some testing. I was right about the cause of the desync, but haven't managed a fix yet.

The highlight bug turned out to be unrelated, but I found and fixed the cause of it.

[namida]

I think I've got it fixed, but will need to test it some more.

To be specific, it happens if you assign a skill on the exact frame that the timer goes from "xx-x1" to "xx-x0" (on a time-limited level). If you were to then backwards step before reaching the next 10 second mark, the skill assigned exactly on that frame will still be in the replay, but will not be reflected in the on-screen state (including in terms of physics and skill counts). If you were to backwards step past the faulty 10 second mark, and let it play from that point, the skill will occur as normal.

Chances are that a proper fix for this would need rewrites to how each frame's updating is handled, similarly to how this issue does. So instead, I just coded a workaround that detects the conditions that trigger the issue, and if they're detected, it'll use an older saved state for backwards framesteps. (The more-logical thing to do would of course be to not make the save state in the first place, but this too would've taken a lot of change to the code, compared to the relatively simple change for the ignore-faulty-saved-state method.)

I don't think it's possible to ever have no acceptable save state (since I don't think it's possible to assign a skill on frame zero), but just in case, there's fallback code to ensure proper functioning even when no earlier saved state is available.