I'd love another meetup!

Bristol sounds good for me, and November should be fine!

August 28, 2026 stream is over and I managed to solve 10 more levels of the Planet rank, one of which was Altruism, the level that Simon skipped Replays attached

I also attempted Planet 13 - Choir of the Mad but was a no solve. I remember this level from Nepster's Return of the Tribes, the L2 level pack for Old Formats NL that Nepster never finished making, so it was just a matter of remembering the solution. There, it's remade in the L2 Medieval tileset. I wasn't able to remember the entire solution during the stream before I ended. I remember it involved some really clever use of the blocker, but what that is, I can't yet remember. The interesting thing is that I played through all the levels of the pack that Nepster made for Return of the Tribes last year. So, I apparently can remember solutions from 3-5 years ago but not from a year ago? It sure boggles the mind! At the same time, there's more, and that is I haven't spent anywhere near as much time on the Return of the Tribes levels as NepsterLems despite how the levels in the former are just as hard, if not harder, and it does feel a lot harder IMO.

Once I manage to solve Planet 13 offline I'll stream more of the pack. Still haven't figured it out yet, but I know the solution will come to me given time

This time, the ones that look like backroutes are Tomb Raider and Cubism. At least I'm certain I don't recall solving Tomb Raider from NepsterLems like the way I did the NepsterLix version. I remember not taking a shortcut at all for the level in the NepsterLems pack and taking the long way around pretty much the entire level.

Both Altruism and Cubism were new to me, as they're not in NepsterLems. The rest of the levels I've played are from NepsterLems, so it was more or less a matter of trying to remember the solution I used in the latter. I remembered the solution to Five do not Survive incorrectly for a few minutes before it came back to my memory. I might had also been wrong about using an RR timing based solution in the NepsterLems version of the level. Any levels where I did abuse the RR manipulation in NL I had to come up with a somewhat new solution, though luckily they didn't need too much of a tweak from the solution I used.

Regarding Altruism, yes, absolutely agree that it's too difficult for its position. It really reminds me of Scrap the Builders from NepsterLems, and IIRC that level is Sun 7 in the latter, which is the rank after Planet and hence the 4th rank. Indeed, Altruism greatly resembles the layout of Scrap the Builders, and the feedback given for the latter is that it really feels more of a Black Hole rank level, and I absolutely agree there! Especially as both Icho and namida struggled with it. I did as well, and that was the next level of the pack that caused me to quit the NepsterLems pack for a while back in 2020, after I was finally successful in getting past my previous roadblock, Planet 13 - 50% is not Enough. Ultimately, when I finally did return to the NL pack, I ended up using a really overcomplicated solution that just barely works thanks to the fast triggering needles trap of the L1 Pillar set. Also, Altruism feels way harder than the NepsterLems version of the level!

Enjoying the pack as usual and can't wait to play the rest! Great levels I remember them being, especially the new ones I haven't played because they're not in NepsterLems      

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.