Basher/Miner steel collision detection has been relaxed in commit f966d37. It's now possible to bash and mine right up to the steel block.

Please note that this is a significant physics update which can and likely will break existing replays for any level in which the solution involves bashing or mining up to a steel block. It should theoretically never affect the actual level itself though, only the replays.

With that said, I think we can agree that this is a desirable fix that's worth a few broken replays. Now's the time to speak up if you disagree!

Quote from: Guigui on January 23, 2026, 10:20:57 PMYes all works good if the CE is put in its own directory.

OK, I can confirm that running CE from a NL 12.14 directory results in checkmarks not being displayed in the level select menu. It turns out that it's because CE uses larger images (24 x 24 rather than 16 x 16) due to the treeview itself being larger (and having larger clickable areas). I forgot that I'd made this change, and it does result in the checkmarks not being visible if the assets don't match what's expected.

Quote from: Guigui on January 23, 2026, 10:20:57 PMthe text scrolling bar on the main at the bottom of the main page not displaying properly.

And yeah, this is due to the data\title.nxmi file being set up slightly differently to accomodate the CE menu graphics.

Quote from: Guigui on January 23, 2026, 10:20:57 PMAll in all, not sure if this idea of running CE from NL is that good. It looks like it leads to some conflicts and gives you some troubles.

I'd probably have to agree at this point. CE has been created with the sole purpose of being a UI upgrade, but it clearly needs to be able to load its own assets in order to achieve this goal.

It seems that the best thing to do would be to ask CE to check for a subdirectory (we could call it "assets-ce" or something) which contains all the CE-specific graphics, data files, etc required to run CE correctly. Mutual assets (levels, replays, music, etc) and NL-only graphics can be placed in the root directory as usual.

Then, when loading something, CE can check for "assets-ce" before checking the root directory. Anything that's found to be missing (Sleeper sprite) or different (title.nxmi, the checkmark .pngs) can be placed into "assets-ce". (Of course, running CE from its own directory will not require the CE assets folder).

That's something I can certainly look at for the release of 1.1 proper. It may be worth doing an RC-2 to check that it's definitely playing ball, if we decide to go ahead with this.

---

It does beg the question though... why would you want to run both programs? NeoLemmix CE literally is NeoLemmix12.14 with UI tweaks. The internal game is exactly the same by design, and that will never change. Most of the features that have been added in CE are optional, and those that aren't can be modded to some extent (the menu gfx, for instance).

With that said, I probably will go ahead and find some way of running CE assets from the NL directory. It should be done as cleanly and minimally as possible.

Well, it's funny you should ask.

I already implemented support for subfolder a few days ago (commit 5d9cc71) so the next version (1.45) will be able to access the subfolder and represent the correct music file for your level.

If you notice anything else, let me know. I'll likely be releasing NLCE 1.1 proper along with Editor 1.45 very soon (within the next few weeks).

As an experiment, could you try moving userdata.nxsv and NLCE into their own directory (with all the RC-1 stuff) and see if you get the green checks then?

Settings are now stored in "NLCESettings.ini" to prevent clashes when loading settings. CE will initially read from "settings.ini" if it exists (to prevent you from having to do the config again), but will save to the new file and use that one from then on.

N.B. Both programs will continue to read/write to/from the same userdata.nxsv and hotkeys.ini. If running from the same directory, it's most likely that users will want this, since both programs will show the most up-to-date completion progress for all levels. As far as hotkeys are concerned, even if new ones are added to CE, NL would just ignore any lines it didn't recognise in hotkeys.ini.

Yeah, I'll make sure that CE can read from "sound" as well as "sounds" in 1.1 proper.

Scratch that, I've already done it! In commit 5d091f3, full cross-compatibility with legacy NL directories has been added. This was done after the release of 1.1 RC-1. I don't even remember doing it, but it's there and it works! EDIT: Thinking about it, it was probably done in response to this topic. I've made directory cross-compatibility a fairly high priority in general, since it does make a lot of sense that people would want to run both NL and CE from the same directory.

One thing to note is that some of the sounds themselves may have different names or may use different sounds for the same thing. It's worth combining all sounds from CE and NL into the same directory (whichever one you use) to ensure that both programs can access the sound files that they need. You should only need to do this once, and thereafter add any sound that may later be added to CE (this would need to be done for regular NL anyway).

Fixed in commit 6a92a27.

Linking the proposed behaviour to the zoom hotkeys as opposed to directly to the mousewheel handler is by far the easier approach to take here. It's a few lines of code and it works perfectly.

Attempting to hard-code it to the wheel would be a lot more of a bug-prone effort. The wheel can currently have any hotkey action linked to it, so we'd have to find a way to bypass that action (from a place of not necessarily knowing what the action is) as well as implementing the new framestepping behaviour and ensuring that other mousewheel event handling isn't affected. Not trivial, and tbh not worth the effort.

Let's add the framestepping behaviour as a modifier-accessible action of zoom in/out, then. I imagine that the vast majority of users keep zoom in/out linked to the mousewheel anyway. The framestepping, then, is a nice added bonus.

So, ensuring that zoom in/out remains linked to the mousewheel, we have:

Wheel only = zoom in/out
Ctrl+Wheel = step +1/-1
Shift+Wheel = step +10/-10
Alt+Wheel = step +100/-100

Let's give this a try in CE 1.1 and see what we think.

Implemented in commit 2b75880.

It's in the title.  I always uncheck "post redirection topic" and I imagine that other mods do the same (since we don't see a lot of redirection topics, but we do see a lot of topics being moved). Maybe the check should be un-ticked by default?

Quote from: Simon on January 20, 2026, 07:56:00 AMDoes the trouble arise from the design of the keybinding dialog?

No. I don't think the program is able to distinguish between "keydown" and "keyheld", at least not currently.

Wouldn't "keyheld" necessarily have to fire "keydown" anyway? I could be incorrect in this assumption.

Anyways, what would be possible without changing or adding any existing modifier key logic would be to simply implement "Ctrl + zoom hotkey in/out = frame step +1/-1." I'm happy to add that. Most users are likely to leave zoom in/out linked to the mousewheel, and it seems a good idea to also be able to framestep like this by default.

A thought occurs though. Using the mousewheel to framestep is a good idea, but maybe the increments should be slightly larger than 1. I'd suggest somewhere between 5 and 10 as a good alternative. It makes movement forwards & backwards more what you'd expect from mousewheel use.

Quote from: Guigui on January 17, 2026, 02:08:32 AM* CTRL + mousewheel up = chosen number of frames step forward
* CTRL + mousewheel down = chosen number of frames step backward

Hm. I agree, but this would mean treating the modifier keys only as modifiers. They could no longer be used on their own as single-fire key events.

I'm pretty sure a hack exists where you can use a modifier with itself (so, Ctrl+Ctrl) to get essentially the same behaviour as a single keypress, but I wonder if the key has to be held for a certain amount of time for that to work.

So, would anybody mind this being changed? Allow the modifiers to be used as modifiers, but no longer as hotkeys by themselves?

Quote from: daniel on January 19, 2026, 11:05:55 PMthe mouseovers of the six right-hand buttons are not correct.

Thanks for letting me know, I'll take a look at this soon and get it fixed for the proper release.

Quote from: kaywhyn on January 15, 2026, 08:09:31 PMAh, yea, the issue you're seeing is that for some very odd reason in SuperLemmini and its forks doing it one direction is impossible whereas in the other it is but still very precise.

I tracked this down to the mask images themselves. The left-facing Builder mask is offset by some number of pixels (I've yet to figure out exactly how many), and I'm pretty sure this was either done deliberately to match OG physics, or else it's a Win95 developer oversight.

Anyways, the next RetroLemmini update will have this fixed once and for all. Builders should provide the same pixel coverage no matter which direction they're facing, I think we can all agree on that.

+1 for an additional Brick tribe. Either recolour the brick set, or add a Remix tribe which remixes any additional levels into other style sets.

Additional Brick levels - Dolly Dimple, Oh No! It's the 4th DIMENSION! and Five Alive.

Quote from: Ron_Stard on January 15, 2026, 10:12:41 PMWhat backroute are you referring to in "If at first you don't succeed"? Using one basher under the three pillars?

Yes. I also believe that there is an intended solution which can be somewhat enforced by adding a left-facing OWW to the middle pillar. That, plus steel blocks underneath the middle pillar, should fix it.

I challenged myself to only pick 3 of each:

Crystal - POOR WEE CREATURES!, The Art Gallery and Don't Make The Wrong Choice!
Dirt - Watch Out There's Traps About, Steel Works and Rendezvous At The Mountain
Fire - Mary Poppins' Land, X Marks The Spot and Take A Running Jump (with backroute fix for the latter of these; it should be necessary to take the MAD DAM DMA route)
Marble - Compression Method 1, Tribute To M.C. Escher, No Added Colours or Lemmings
Pillar - If At First You Don't Succeed... (with backroute fix), The Great Lemming Caper and Save Me
Brick - LeMming ToMato KetchUp fAcilitY, There's Madness In The Method and AAAAAARRRRRRGGGGGGHHHHHH!!!!!!
Bubble - Down The Tube, It's The Price You Have To Pay and Flow Control
Rock - ROCKY VI, ROCKY ROAD and Where Lemmings Dare
Snow - The Stack, Chill Out! and The Race Against Cliches
Christmas - Merry Christmas Mr. Lemming, Get The Point? and Presents Of Mind II