Eesh

Of course, the event handler to use is 'Change', not 'Click'. The UI should not update every time the treeview is clicked, only when a node changes.

This removes the need to track the last-clicked node, and complements the other fixes (re-entry prevention, decoupling of loading from event handler).

NLCEPlayer commit 2d209ab.

Quote from: Armani on August 29, 2026, 08:14:48 AMAfaik, there is no code path anywhere in SetInfo that calls ProcessMessages so with the current structure

SetInfo is now 'UpdateInfo' in CE, and ProcessMessages gets called just after the group caption is updated. This is because CE does a lot less 'load everything all the time' and mostly only grabs what it needs; the trade-off is that we occasionally need to manually push the UI to update (and of course, to keep the form responsive).

Quote from: Armani on August 29, 2026, 08:14:48 AMIt would be even better if we kept a "load pending" flag. If a load is already pending, don't post another message.

Yeah, this is (sort of) already how it's done. The click captures the node, sets the flag, and posts the message. The flag acts as a re-entrancy guard so that no further messages can be posted until the current one has been actioned. See the commit if you're interested to know exactly how the fix is implemented. Maybe you can suggest improvements?

Quote from: Armani on August 29, 2026, 08:14:48 AMFor some reason in NL, every single click would re-scan the entire tree to populate the level titles and info, parsing level files on the spot for any visible nodes that hadn't been labeled yet. This was very very inefficient. (Has this been fixed in CE?)

Yes, LoadNodeLabels is slightly more lightweight than it was previously, and has been moved out of UpdateInfo (previously SetInfo). That way, we can use it only when the tree is expanded rather than every time we need to load level info.

Quote from: Armani on August 29, 2026, 08:14:48 AM1) Populate the labels once for whatever is initially visible then incrementally populate them only for a group's direct children nodes when that group is expanded.

This is already done. LoadNodeLabels now only cares about what's actually visible, and it's called whenever the tree is expanded.

Quote from: Armani on August 29, 2026, 08:14:48 AM2) Skip the full level reload for the preview panel when the selected level's path hasn't actually changed.

This is also already done for the next update. Re-clicking the same level in the tree over and over no longer causes the level to reload. Obviously, if a different level is clicked, that level loads. And, since we still aren't using data caching, re-clicking the previous level again after clicking a different level causes it to re-load.

There is definitely more that can be done to optimize the level select menu, but the changes made in CE have brought it a long way.

OK... the click handlers are now super light. They grab the active node and post a message, that's it.

Once Windows has finished handling the click, the message pushes the loading through. This makes the tree snappier than ever, and should prevent the UI from going unresponsive.

Pending testing, this should hopefully be the answer.

Implemented in NLCEPlayer commit a2ee836.

Removed 'Allow Same-Lemming-Overwrite in Insert Mode' option; we show 'CUT X TASKS' and assume that the user wants to do this (NLCEPlayer commit 787bae5).

Added 'Click Air to Cut Replay in Insert Mode' option; users can choose to let air clicks cut the replay in Insert mode (air clicks always cut the replay in Standard mode) (NLCEPlayer commit 3ab5ade).

I'm definitely up for Bristol, and would also be happy to travel to anywhere on the coast. Seaside in Winter can be very beautiful.

Happy to help Northern friends with transport if needed.

Quote from: Simon on August 27, 2026, 04:28:13 AMIf we disable airclick, should clicking the R in the panel cancel replay?

Definitely.

The panel hints let the user know that they can cancel. But, panel hints are also optional. Discoverability is an issue for sure; maybe we can show a message the first time we enter replay mode (we're back to that again).

Quote from: Simon on August 27, 2026, 04:48:46 AMHunch: Do the event handlers (callback functions) for on-click run in separate threads?

I'm not entirely sure to be honest. I certainly haven't implemented any sort of threading, but it may have been done by one of the previous devs.

Quote from: Simon on August 27, 2026, 04:48:46 AMAnd 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.

I'm about 60% sure that the click is too heavy; the handler calls a method which includes loading level info and all sorts of other stuff. I've tried making it more lightweight by only processing exactly what we can see at any given time, but the click certainly could be more optimized.

Do you imagine: the click should 'request' that we load the level? Then, once the click has been eaten by Windows, then and only then load the level? (And, suppress further clicks until the level loading is complete?)

That could work!

Another collaboration session might be due. It would be good to look at a few bugs with you. We can look at Lix as well, it would be good to get the 'release mouse' hotkey finished.

I would absolutely love to visit Germany and meet everybody. If I do manage to come over in Feb, I'll likely arrange my own accomodation so as not to overwhelm Simon with guests.

@Simon - I believe you live on a mountain! Are there relatively inexpensive hotels/BnBs nearby?

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.

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.

Quote from: Proxima on August 24, 2026, 02:06:39 AMThere is no such thing as cheating in a single-player game

Fair enough. A better way to put it is probably "it undermines a big part of the game's challenge", which - in the case of L1/L2/L3 - was to solve the levels in real-time as much as possible as well as solve the puzzles.

Quote from: Proxima on August 24, 2026, 02:06:39 AM

QuoteWe all agree that the ability to framestep backwards immediately renders most of the original levels (which is what many players come to the Forums looking for) obsolete.

Out of 120 levels, there are five timed bomber levels in the entire game. ONML has only two out of 100.

Did I miss something? We're not talking about timed bombers here, we're talking about framestepping. The original point stands: a lot of L1 levels feature challenges related to general timing and crowd control, which are rendered trivial by the ability to framestep.

Quote from: Proxima on August 24, 2026, 02:06:39 AMIt's true that the original game didn't have any kind of replay system ... if it had had replays from the beginning, I can't see that anything I liked about the game would have been changed or diminished.
...
And then UU got added, nothing really changed, and it was still the same game, just easier to play.

Fair enough. There's a very good chance that adding the ability to jump backwards a bit (possibly via savestate loading) won't ruin RetroLemmini's general gameplay and will just save the player time, which is an important consideration and the reason for this topic in the first place.

Any Rewind feature will no doubt be a balancing act between making the game better to play, and retaining as much of the old school 'charm' as possible.

Quote from: Proxima on August 24, 2026, 02:06:39 AMI know that maybe it's not my place to say these things ... I'm mostly contributing because I hope this discussion can help you reason out the decision

This is much appreciated. All feedback is good, all opinions are valid and helpful to the outcome one way or another. Thank you for taking the time to contribute your thoughts!

Quote from: Simon on August 23, 2026, 11:38:59 PMDebugging idea

Thanks for the ideas

For now, I've guarded against re-entrancy for treeview and preview loading, both of which are relatively expensive tasks. They've already been fairly well optimized, but I realised that there's nothing actually preventing them from being called multiple times. Multiple quick-succession clicks would be a problem, then.

The re-entrancy guard should hopefully do it. Flopsy is testing now.

Caching is a very good idea, but... it would need to perform a cache every time it opens/closes to keep it up to date (potentially?).