I can't replicate this. Lemminas sprites work fine in my test directory running CE 1.1 RC-1 and NL 12.14.

The fact that the sprites aren't working in either NL or CE suggests it's more likely to be a problem with the style rather than the engine. Here's the latest copy of the willlem_lemminas style. Try adding this to your styles directory and see if it resolves the issue.

OK, this should be fixed once and for all.

CE will now ship with an "assets-ce" folder which will contain all of the CE-specific graphics, data files, and overrides. CE-only users will actually not need this, but anyone wanting to run CE and NL side-by-side can do so simply by placing the .exe and the assets-ce folder into the NL root directory.

It works a treat, and is set up for future-proofing should we need to add or update any more assets in CE.

Implemented across commits 8e91234 - 7f0256b.

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.

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.