Hunch: Do the event handlers (callback functions) for on-click run in separate threads? Or somehow else separated from the main logic? And do they accomplish a lot of work by loading the level during the callback? Then: I'd try to make the event handlers lightweight. They should merely notify the main logic that filename/level X should be loaded. Later, the main logic opens the file. We can't get a race bug if only one thread ever opens files ...

... which means progess if these assumptions hold:

• Avoiding such a race will actually fix the symptom.
• Windows file I/O, or your UI library, can have such races in the first place.

I've written all the Lix UI myself (no UI library, only Allegro for the graphical primitives) and the UI runs single-threaded in the main thread. I can't run into a threading bug by design. The downside is that everything fast/parallelized/coroutine-like needs explicit and hand-written support for this in the UI widget that wants to parallelize. It's rare enough (only the level search) that it was fine to implement a coroutine by hand: Load level metadata from disk for several levels until N milliseconds have passed, then memorize progress and stop, and when the UI calls us next tick, load some more.

Level metadata loading is opening file, reading line-by-line until we have found author and title, and then closing it immediately. It duplicates part of the normal level loading, but that's okay, it's a speed hack. Windows file I/O still has to open the file in both cases for reading, I can't get around that in a level tree of loose files.

More details when I have more time.

-- Simon

Quote from: WillLem on August 27, 2026, 04:06:01 AMUsers can now set Insert as the default mode
advanced users can set this as their default mode

Hmm, defaulting to non-insert mode is in good line with the findings.

Consider to complement this with an option to allow airclick to cut the replay during insert mode. That's what I've missed the most along with starting in insert mode.

You'll essentially have the same 3 independent bool options as Lix has: Start in insert mode? Airclicks cut in regular mode? Airclicks cut in insert mode? This is the least annoying set that I found so far. I don't expect this design to live forever (3 bools is 8 variants), and I really want to do better than this. But it's the best I see for now.

---

If we disable airclick, should clicking the R in the panel cancel replay? I.e., should that R always function as a cancel-replay button? The UI doesn't communitcate that, but it can still react to clicks. Hunch is yes, but it really leads back to the same ancient question of how to make replay canceling explicit and easy to discover.

-- Simon

Users can now set Insert as the default mode (NLCEPlayer commit 2f55cf7.)

This means that as soon as a replay begins, it will do so in R Insert Mode (if that's the desired default mode) rather than R Standard Mode. The 'Insert Mode' toggle hotkey (O by default) can still switch between the two as usual.

So, we can now tweak Insert Mode to be more like the proposed 'Single Mode' (which we can now consider rejected as a standalone idea), and advanced users can set this as their default mode if they wish to do so.

I believe this solution offers the best of all worlds.

Solved the Bittersweet levels. Another high quality batch, and these are getting tough now!

OK... guarding against re-entrancy didn't work (although I still can't shake the suspicion that this is what's responsible, albeit maybe from the Windows side).

I'll make an experimental build that logs clicks and ask Flopsy to test it, but... thinking about it, I'm beginning to wonder if it's time to just re-think the entire Level Select menu.

I'd like to set the treeview on fire and display the levels some other way.

Lix is able to search 1000+ levels in seconds. How does Lix store levels in the menu? Does it cache on load? Does it store them as a simple list and worry about connecting the level to data later, or is storage fully object-based?

The fact that Lix lists the levels on buttons is clever; the buttons cannot be clicked twice, which is an elegant way to prevent having to re-load the same level.

I never got round to announcing this, but since my last post in this thread was about playing Hollow Knight: Silksong, I should mention that I did indeed finish the game. Reached 95% by myself, then got some pointers for the last few things I was missing (just the names of the areas they were in), since combing all over the game world for things that could be anywhere felt like it would be a sour note to end on after such a beautiful game.

There are still achievements to go for -- similar to the first Hollow Knight, there's one for completing it in 5 hours, and there is a "Steel Soul" mode where your save file breaks if you die. Both of these will be much harder to achieve in Silksong as it's both a harder game and a much larger one. So I haven't yet found time to get back to the game to give them a serious try.

Meanwhile, in the last couple of weeks I have rediscovered and played through I Wanna Lockpick, a puzzle game I first tried a couple of years ago. Back then, I got stuck and eventually looked at hints and fell into a spiral of getting spoiled on solutions, and it stopped being fun. But recently, one of my Touhou friends was playing this game on Twitch, and that reminded me of it, and I felt long enough had passed that I could try again, this time without looking at hints at all.

I'm almost at the end now: 64 in-game hours, 207 of 213 puzzles cleared. I'm hoping I can go the rest of the way 

So, what is this game? Well, you take the coloured keys and locks idea from Chip's Challenge... and you make that the entire game. That might sound like it must get boring and repetitive, but it really doesn't, because it gets extremely creative by introducing new types of keys and locks (and I won't say more than that in case anyone wants to look into it themselves -- it really is most fun to go into it blind!) And since you are always manipulating numbers of keys and locks, the puzzles have a strong mathematical flavour that, I think, would appeal to a lot of the people here.

Added a Nuke status check to the second block. This fixes the bug but keeps the pre-assigned check available should it prove to be necessary for any reason.

Fixed in NLCEPlayer commit 636fdeb.

Thanks for the heads up and the suggested fix.

Just to double check, you are referring to the second block in CheckIfZombiesRemain?

function TLemmingGame.CheckIfZombiesRemain: Boolean;
var
  i: Integer;
  ReleaseOffset: Integer;
begin
  Result := True;

  for i := 0 to LemmingList.Count-1 do
    if LemmingList[i].LemIsZombie and not LemmingList[i].LemRemoved then
      Exit;

=============== FROM HERE =================

  ReleaseOffset := 0;
  if (LemmingsToRelease - ReleaseOffset > 0) then
  begin
    i := Level.Info.SpawnOrder[Level.Info.LemmingsCount - Level.PreplacedLemmings.Count - LemmingsToRelease + ReleaseOffset];
    if i >= 0 then
      if Gadgets[i].IsPreassignedZombie then
        Exit;
  end;

============== TO HERE ==============

  Result := False;
end;

Removing the second block fixes the bug, but just wanted to make sure that's exactly what you meant.

Try Ghidra.  Reverse engineering is a lot of work, but it can be fun if you like puzzles.

I've recently been wondering if anyone has a tool, besides Objdump, that can conver MS-DOS machine/binary code into platform-specific assembly code?

Reason being that is what I or someone else would need to even begin hacking the original games/formats! Amiga and other original Non-Windows-x64/x86 Platforms would also be great, thanks!