November would work! Let me see if my gf and/or my sister and her family would like to come, what dates you looking at?

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.

if there is one thing I wish brass had, its pieces that transition rusty to steel, they of course wouldn't be steel but it'd be nice to have something that looks aesthetically pleasing when placing a rusty piece next to a steel piece

?? I must say I do not understand how that can work on NL ?? Can you explain a little how you do that and what the player is supposed to do ?

In any case, Duck-Hunt X Lemmings looks fantastically fun

This should not exclusively rely on an audio cue because there are situations where the game could be played without sound - like players who are deaf or listen to their own music while playing or are in a noisy environment where they cannot properly hear the sounds, just to name a few examples.
My first thought was mildly adjusting the base color of the end-of-screen box (green for success, red for failure) but that won't accommodate colorblind players.

I'd personally advocate for including a little graphic on the end-of-level screen, but it requires some thought:
- It shouldn't be too large, i.e. bloat the screen or hog the player's attention.
- Where to put it such that it still fits into the screen layout nicely?
- The significance of the graphic should be intuitively distinguishable without further explanation.
- Pros and cons of using a game-related graphic (e.g. Lix) vs. a universal one (e.g. checkmark, X)?

Making an FPS themed level..🔫 Stay tuned!


If you can ignore the Goldberg–looking machinery on the right half of the level, the level should play smoothly and it shouldn't be too difficult for players who haven't had much experience with FPS games.

I still have to figure out how to deal with friendly fire and make the win condition easily recognizable...

Suppressing further clicks until a level finishes loading likely won't do much. Afaik, there is no code path anywhere in SetInfo that calls ProcessMessages so with the current structure, there shouldn't really be any chance of the click handlers actually running on top of each other. Though, adding a re-entrancy guard as an extra safeguard against overlapping clicks at little to no cost, is not necessarily a bad idea.

Keeping the click handlers as lightweight as possible is definitely a good approach. That should prevent the UI from becoming non responding. It would be even better if we kept a "load pending" flag. If a load is already pending, don't post another message. Then when the message handler actually runs, re-read whichever node is actually selected at that moment and load based on thatrather than using a stale node captured when the click originally happened.


For 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?)
1) 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.
2) Skip the full level reload for the preview panel when the selected level's path hasn't actually changed. No full reload(no parsing, no terrain rendering) for the info panel when nothing has actually changed in practice.
This would make the game feel more like playing NL in the Lix engine.

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.

Third stream is over and was on Friday, August 28, 2026 at 5PM PST:

https://youtube.com/live/F0jAwVGFDLY?feature=share

Edit: Oops, I forgot to post the link before I went live Must remember to do this! Not used to this apparently