OK, I think I know what the problem is.

In SLX, a level exists as 3 different things:

1) The file itself
2) A TNeoLevelEntry, which stores the basic level information (title, levelID, etc)
3) A TLevel, which stores the more complex information (skillset, talismans, plus whether or not the level was successfully passed, etc)

I need to find a way to create a TNeoLevelEntry from the file. I can do that for the purposes of playing back the replay, but not loading the actual information. It's baffling, but nothing I haven't encountered from this codebase many times before. I'll get around to it.

Made a surprising amount of progress with this today. We now have a Playback Mode button in the Level Select Menu:



As well as looking pretty, this button opens up a dialog from which a folder of replays can be selected. Once chosen, SLX will then iterate over each replay in the folder, matching it up with a level from within the currently-active pack (note: at this point, it only looks in the currently-active pack for matches - this could be expanded to it searching the entire levels directory, but this may make loading slower). The "currently-active pack", in this case, is the parent pack of whichever level is currently selected in the Level Select treeview.

Each replay is then played back automatically, one after the other (the preview and postview screens are briefly seen in between each level). If a level has multiple replays associated with it, each one will be played back as and when the replay appears in the Playback list.

Playback Mode can be cancelled by simply cancelling the replay as normal (I might give this a dedicated hotkey if people think it's worth it - it's possible that users might cancel the replay by accident, and also users might want to do something within the current level, but then go ahead with playback again for the next level, which is currently possible if we don't cancel Playback Mode along with a normal replay cancel).

Some issues:

1) The preview screen always shows the first level in the list's info, even though the correct level is loaded when playback itself starts
2) The music is always that of the first level in the list - this is likely part of the same problem, but I'm not sure exactly what's going wrong
3) If a replay doesn't have a definite "end" point (so, if the original player pressed [Esc] rather than nuking at the end of Tailor-made For Blockers, for example), the level will continue to play indefinitely - not sure exactly what to do about this at the moment, but ideas will come
4) Not an issue as such, but randomizing the playback currently isn't possible by any other means than manually mixing up the replay files so they're not in logical order. Let's get the other issues sorted first and get the feature nice and tight, then we can look at expanding functionality to randomization of playback, etc.

If you're interested, check out commit 80da87c02 to see implementation so far. If you can see possible improvements or ways to fix the above bugs, input would be most welcome.

Otherwise, just watch this space!

L2 has 120 levels in total, with the 12 tribes having 10 levels each.

Again, happy to do the 10 beach levels. I'll probably get on them soon, it shouldn't actually be too difficult to just recreate them manually.

Once I've done that, it's very likely that others will jump on board for the remaining 110 levels

The 16x8 tiles in the image dump are in the correct order. So a 1 in the level file would mean the first 16x8 tile, a 2 is the second 16x8 tile, etc, so it should be straightforward. You just need to create the NL tilesets based on those 16x8 tiles (which I assume can also be automated). Then you're sorted for the terrain at least.

Regarding your other question, of course you could also create images of the levels from the level files and the 16x8 tiles, it's a very similar process to the above.

FF buttons be hold-down instead of toggle, how I thought they always should've worked

Interesting observation. In Lix, I hold the 10-second framestepping, too, and it becomes fast-forward for me. Hard to say if it's worthwhile to turn toggle-on fast-forward into hold-to-fast-forward. I imagine that toggle-on is better for recording solution videos, but that's niche. Even in livestreaming, I prefer hold-to-framestep instead of the toggled fast-forward.

I haven't played Golems enough yet to decide if I want a super-fast hold-to-fast-forward in Golems.

snapshot basically only needs to store the accumulated changes to the terrain and effect maps along with the (uncompressed) creature states, gadget states, and various other small bits of game state.

There is wisdom here: Separation of all level state into an immutable and a mutable section. It's enough to store the immutable section once, at the beginning. We store the mutable section in regular intervals, possibly compressed.

We can push this further in all of our engines.

E.g, hatches and water don't need to be part of the mutable state at all. Their animation is only dependent on the number of physics updates since the beginning. We can keep them in the immutable section, and only prepare them just-in-time during the drawing step. It's common to have 10 to 50 water tiles in a level; Lix can omit many allocating deep copies here.

Traps must remain in the mutable section because they eat lemmings at unpredictable times, and both physics and graphics depend on such recent eating. Theoretically, traps can split into an immutable location and the mutable number of the physics update of recent eating, at cost of even more complication.

Thanks!

-- Simon