[BUG] [PLAYER] Stateload without savestate

[IchoTolot]

We expected to get to the start of the level with this, but instead we got to an internal savestate. Internal savestate = savestate that was made internally to improve the framestepping performance. We never made an own savestate!

Pressing the stateload once more got us to the beginning of the level, but the terrain was only updated with the first pressing of the stateload. A result of this is attached as a png. The level restarts, but with still altered terrain from the last try.

To reproduce this (we made this with Cranes contest entry to R1): Play a little bit and alter the terrain, then press the 10sec skip forwards or wait for a little bit ~ 10 secs. You must have played at least a little bit normally so that an internal savestate is created. Then press the stateload it will take you to the internal savestate + resets the terrain to this internal savestate. Pressing the stateload again brings you now as intended to the beginning of the level, but does not resets the terrain to the initial situation

Proposal: Pressing the stateload without a user-made savestate simply takes you to the beginning of the level in replay mode with the initial terrain layout.

For the picture: The basher hole should not be there anymore.

[namida]

Proposal: Pressing the stateload without a user-made savestate simply takes you to the beginning of the level in replay mode with the initial terrain layout.

Intended behaviour is that pressing stateload without saving a state first would do nothing. I am okay with implementing your suggestion instead.

The current behaviour is a bug either way.

[Simon]

My guess, too, was to not do anything on stateload without savestate. If stateload were a GUI element, it would be hidden or greyed out.

I'm okay with savestate = initial position.

-- Simon

[IchoTolot]

I would be ok with both behaviors. As we talked about this yesterday both ways seemed logical: Either do nothing or jump back to the start.

Only the bug needs to go

[namida]

This has been fixed for the next update. I've kept the existing (intended) behaviour of "do nothing in such cases".