I don't want to interfere with Flopsy and this will be probably my last reminder but the videos not considered in the first post until now are:

Cunning 6-10
Cunning 11-13

One thing which I have noticed for some time is that the readme is now a md-file even in your Win release.
What is the proper program to open that and is it intended that it is that format in the Win release?

Another point where people can trip over:
When installing dmd with the installer on Win it wanted to install another external big program for 64bit-support.
I always declined that and got a warning that there is no 64bit support then but for Lix it was sufficient without that (program). Lix builds fine even without.

Simon, I have it recorded. I used the level "Any Way You Want": It shows a basher asssignment as past actions in the list but none of the bashers is used up.
In this case it doesn't seem to erase the action from the active replay when loading a later point phyu-wise and the save is still part of the replay actionwise.

So basically:

Save.
Rewind a bit (don't cancel anything which would belong to the save).
Do an action (before the phyu-point of saving).
Load.
=> Action still in active replay as past action (although not part of the loaded state).

Edit: Exchanged "Hellfire"-video with a much more to the point video.

Quote from: Simon on January 26, 2018, 08:53:59 PM
I can't be sure since I don't understand the bug, but I doubt the slow machine affects the correctness of the algorithm.

I meant less the slowness of the machine itself but rather how your code handles it. It tends to do at times huge warps backwards when using fast frameskipping back and it really looks shaky then.
Would it be possible that the recalculations access the savestate rather than the active replay?

The only thing which could be counted in is that I have slow machine with low FPS. So especially fast frameskipping back behaves shaky/produces bigger steps back by design. Maybe these kinds of recalculations play a role?

Yeah, that's what probably happened in my tests.

I'm actually out of ideas how to reproduce the bug especially since savestate/stateload behaves intendedly so peculiar.

If you have ticked that the replay is kept upon rewinding then it behaves as you describe.
But I'm not sure if that is good since with loading you usually want to discard some of the later actions?

Quote from: Simon on January 26, 2018, 03:26:28 PM
Here's a scenario in which save+load3 is bug-free in 0.9.9 design:

* Dig in frame 100
* Jump in frame 1300
* Framestep back to frame 500
* Savestate in frame 500
  - Savestate's replay has (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
 

Simon that's just not what usually happens. Rewinding cuts the jumper out of the replay. I have attached a video.

Thanks.

Quote from: Simon on January 26, 2018, 01:53:05 PM
Whenever you stateload: The snipping sound plays because stuff in the active replay is discarded -- unless the stateloaded replay is an initial segment of the active replay, then we keep the active replay and no snipping sound plays.

But isn't that the problem that it shouldn't make that snipping sound since the jumper is after the savestate and shouldn't therefore be in there?
I've attached a video what normally happens if you do that what I did in save+load3.

But can you show what is stored in the savestate in an extra list?

What I noticed from my save+load3 video is that it makes the cancel sound when I load after imploder. I think it usually only does it if one has canceled actions of the savestate and then done other actions?

I've tried around and made some videos but unfortunately couldn't reproduce it until now.
To a certain extent the actions within a savestate are stored outside of the running replay. For example if you cancel an actions before the savestate point it doesn't show them anymore on the list but if you load the save it brings them back on the list.

Quote from: Simon on January 26, 2018, 09:49:30 AM
When you made the savestate, was the jumper already in the replay?

I actually can't answer this question since I did so many things to force it.
But I maybe should say that I've unticked the option to keep the replay when rewinding. So rewinding cancels for me. Nevertheless the jumper could be in the replay by just loading after having done the jumper assignment. Apart from that even with rewind cancelling all the replay up to that is stored in the save.

I have made a video where I think something odd happens concerning replay storage with saves. Unfortunately I still don't have the exact steps to it.
What happens:

I load the save and do an action.
I load again and let the replay play through. -> It does another action from an earlier attempt.

I used "Goblin City" as test ground.

Only another thing connected to that:
The same issue arises if you have e.g. something like allegro-debug-5.2.dll. It then only creates allegro.lib since it goes only to the first hyphen (as far as I've tested and maybe arising from "tokens=1 delims=-" ). That could be a problem if you have have release and debug dlls in the same folder since for allegro-5.2.dll as well as for allegro-debug-5.2.dll allegro.lib is created probably one overwriting the other. That was one thing that threw me off in the course of trying to run against Allegro debug libraries since I didn't know that at that time.
Couldn't the debug liberaries have an underscore rather than a hyphen like eg. allegro_debug-5.2.dll?