Ah, yeah, I forgot that, during save+load3, you would have discarded replay actions on framestep-back.
Here's the scenario where save+load3 is still bug-free even when you discard replay actions on framestep-back. Changes to reply #15 are in bold.
* Dig in frame 100
*
Savestate in frame 500* Jump in frame 1300
*
Load state - State's replay was (100 dig)
- Active replay was (100 dig, 1300 jump)
- Therefore, keep active replay because state's replay is initial segment.
- We're back in frame 500
*
Savestate again in frame 500 - State's replay was (100 digger)
- State's replay is now (100 digger, 1300 jumper)
- R in corner is visible (Reason: future assignment of 1300 jumper)
* Begin video capture
* In frame 550, load state.
- Active replay stays active (Reason: state's replay is identical to active)
- No snipping sound (Reason: Active remains as-is)
- We return to frame 500
- Active replay is still (100 digger, 1300 jumper)
- State's replay is still (100 digger, 1300 jumper), same as active
* Implode at frame 700
- This cuts (1300 jumper) from active replay (Reason: 1300 is in the future)
- Snipping sound plays (Reason: We cut something from active replay)
- Active replay is now (100 digger, 700 imploder)
* Load the savestate.
- State's replay is still (100 digger, 2000 runner)
- State's replay overwrites active (Reason: State's replay isn't initial segment)
- Snipping sound plays (Reason: We cut (700 imploder) from active replay)
- Active replay is now (100 digger, 1300 jumper)
- If we wait until frame 1300, we'll see the jumper play back
It's a very concocted sequence, and I've filed
#295: Savestate shouldn't preserve future when !(keep replay after ◀▮) because I don't like this behavior in 0.9.9. Still, it's possible in 0.9.9 and doesn't exhibit the reply-#4 bug.
-- Simon