This has now been implemented in SuperLemmix. We can give it a try there and see if it's any good.

It's been done as a 'Min-Max' skill limit, to keep the interface as clear as possible and to allow both limits to exist for the same skill.

Example UI:

If a skill has a minimum limit of 5 but no max, it will show as '5+' and 'Use at least 5'.
If a skill has a minimum limit of 5 and a max of 10, it will show as '5-10' and 'Use at least 5 but no more than 10'.
If a skill has no minimum limit and a max of 10, it will show as '0-10' and 'Use no more than 10'.

SLX Editor support has also been added.

SuperLemmix 3.0.3 should hopefully be released in the next 5-7 days.

SLXPlayer commit 0b5147d - 507c34c.
SLXEditor commit 1ab2b41.

After testing from Flopsy (thanks! ), it's very likely that this issue is now resolved.

1.1.3 will be released sometime during the next 5-7 days. It would be nice to get feedback on this particular issue from NLCE users.

Nice idea!

This can already (sort of) be done. The pack author can add a Postview text screen to the final level of the final group, which can be used to congratulate the player on completing the pack (e.g. Mayhem 30 Rendezvous at the Mountain contains such a screen!)

However, that doesn't account for when players might complete the levels in a different order; a likely scenario, since incomplete levels may occur earlier than the last level in the pack, and the player will then come back to those levels later.

So, OK then: let's detect if the level just solved is part of a pack, and ask for the completion status of all other levels in that pack. If all are solved, regardless of ordering, let's show a simple 'Congratulations!' screen.

I've added this one to the to-do list.

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.