And done (commit ff5616e).
- Welcome to Lemmings Forums.
This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.
#1
Community Edition / Re: [?][SUG][PL] Bake physics masks into the .exe
January 29, 2026, 11:20:28 PM #2
Community Edition / Re: [?][CE] Running CE and NL 12.14 from the same directory
January 29, 2026, 07:32:46 PM
Option 4 has now been implemented (commits 4165202 - 4a634f3).
Here's how the file system now works:
It's possible to place the NeoLemmixCE.exe directly into a NeoLemmix 12.14 directory and everything will just work, no need to copy any files across!
The idea of an "assets-ce" folder has been abandoned as it creates unnecessary clutter for NL users, and potential confusion for CE users who want to run CE from its own directory. Instead, all CE-specific/updated assets have been renamed with a "ce-" prefix, and are placed into the same folders as their NL counterparts.
In order to support author/user mods, CE will load assets in the following priority order:
First Priority: Level Pack
CE will first check the level pack root folder for the expected asset. Both the NL-named asset (e.g. 'background.png') and the CE-renamed asset (e.g. 'ce-background.png') will be accepted, with no preference either way. The only exception to this is the level select checkmarks, which bypass this first priority stage.
Second Priority: File System
CE will then check the root directory file system for the expected asset. If it's a ce-specific asset, it must have the "ce-" prefix to be accepted at this stage. All assets that are the same for both NL and CE will be accepted as normal.
Third Priority: Embedded Resource
Finally, if all else has failed, the embedded resource will be loaded. For this to happen, the expected CE resource must be missing from both the level pack and the file system.
Overall, this seems to be the simplest and most future-proof way to handle this. I'll mark this topic as resolved and we'll give the new system a try in the next update.
Here's how the file system now works:
It's possible to place the NeoLemmixCE.exe directly into a NeoLemmix 12.14 directory and everything will just work, no need to copy any files across!
The idea of an "assets-ce" folder has been abandoned as it creates unnecessary clutter for NL users, and potential confusion for CE users who want to run CE from its own directory. Instead, all CE-specific/updated assets have been renamed with a "ce-" prefix, and are placed into the same folders as their NL counterparts.
In order to support author/user mods, CE will load assets in the following priority order:
First Priority: Level Pack
CE will first check the level pack root folder for the expected asset. Both the NL-named asset (e.g. 'background.png') and the CE-renamed asset (e.g. 'ce-background.png') will be accepted, with no preference either way. The only exception to this is the level select checkmarks, which bypass this first priority stage.
Second Priority: File System
CE will then check the root directory file system for the expected asset. If it's a ce-specific asset, it must have the "ce-" prefix to be accepted at this stage. All assets that are the same for both NL and CE will be accepted as normal.
Third Priority: Embedded Resource
Finally, if all else has failed, the embedded resource will be loaded. For this to happen, the expected CE resource must be missing from both the level pack and the file system.
Overall, this seems to be the simplest and most future-proof way to handle this. I'll mark this topic as resolved and we'll give the new system a try in the next update.
#3
Community Edition / Re: [?][SUG][PL] Bake physics masks into the .exe
January 28, 2026, 10:09:14 PM
Compromise, after overthinking this less:
Bake the physics masks into the .exe, but also provide them in the usual folder for visibility's sake. They just simply won't be used from there.
Bake the physics masks into the .exe, but also provide them in the usual folder for visibility's sake. They just simply won't be used from there.
#4
Community Edition / Re: [?][SUG][PL] Bake physics masks into the .exe
January 28, 2026, 12:23:10 AMQuote from: IchoTolot on January 27, 2026, 05:55:43 PMLooked inside the folder and I can maybe see somebody wanting to swap the highliter or countdown.
Yes, this stuff should remain visible and editable. We'd only bake in the physics masks.
Quote from: Simon on January 27, 2026, 07:38:46 PMAllow editing the file, but checksum on load and warn nonintrusively on mismatch.
Good suggestion, but hard pass. For this, I'd rather just commit one way or the other.
Quote from: IchoTolot on January 27, 2026, 09:01:34 PMI do not have a strong opinion about it, when you wanna hide them for CE, do it. I just remembered why we actually went away from the big exe blob and I feel like that could be a frist step back to it.
I doubt we'd ever go back to a fully-loaded .exe. Certainly not whilst I've got anything to do with it. It's clear that users want to be able to mod their copies, and we should continue to support that.
Quote from: Simon on January 27, 2026, 07:38:46 PMIcho's position is interesting. What do you think about externalizing even more physics?
Important question. If we want to allow users to potentially play with the physics, why not splat height? Builder/Stacker/Platformer brick width? Lem walking speed? etc... If the intention is to allow users access to the physics for modding, where do we stop? If we'd rather not allow access for the sake of simplicity, then the gfx/mask files shouldn't exist in the directory.
#5
Community Edition / Re: [?][CE] Running CE and NL 12.14 from the same directory
January 27, 2026, 11:36:01 PMQuote from: Guigui on January 27, 2026, 10:42:10 PMIt looks like I launched this whole idea of booting CE from the same directory as NL, so I'm giving my vague 2 cents here : either solution 2) or 4) sound fine to me.
Agreed. I'll probably go with 4. It's a bit more work for a lot more benefit.
Quote from: Guigui on January 27, 2026, 10:42:10 PMI'm just an end user who likes to keep things kind of tidy on my machine.
This actually makes you the perfect person to provide feedback, and I'm very grateful for it!
#6
Lemmini / Re: [RELEASE] RetroLemmini 2.7
January 27, 2026, 09:33:36 PM
Version 2.7 hotfix update
N.B. If you're on 2.5 or earlier, please get this update.
Following very quickly on from 2.6, some replay loading bugfixes and a hotfix for the Editor.
Replay Loading Bugfixes
• If the exact pack, rating and level can't be determined, we fallback to search by level name only. This should help to avoid a lot of false negatives when loading replays.
• When checking for compatibility, if a replay is determined as 'possibly incompatible', we now avoid the annoying popup and simply show compatibility info in the window caption. This way, if a replay actually is incompatible for any reason, we can ask users to check the compatibility info in the window caption (which is visible at all times) and this should help to diagnose the issue.
• Compatibility checking now tracks the last physics update. At the time of writing this, that's version 2.6 (which should at this point be considered the last major update).
RetroLemmini Editor 1.1.1
• The (brand new!) level editor has had a small update to better handle styles loading errors.
A reminder of what's new as of 2.6.
Get the latest version here.
N.B. If you're on 2.5 or earlier, please get this update.
Following very quickly on from 2.6, some replay loading bugfixes and a hotfix for the Editor.
Replay Loading Bugfixes• If the exact pack, rating and level can't be determined, we fallback to search by level name only. This should help to avoid a lot of false negatives when loading replays.
• When checking for compatibility, if a replay is determined as 'possibly incompatible', we now avoid the annoying popup and simply show compatibility info in the window caption. This way, if a replay actually is incompatible for any reason, we can ask users to check the compatibility info in the window caption (which is visible at all times) and this should help to diagnose the issue.
• Compatibility checking now tracks the last physics update. At the time of writing this, that's version 2.6 (which should at this point be considered the last major update).
RetroLemmini Editor 1.1.1• The (brand new!) level editor has had a small update to better handle styles loading errors.
A reminder of what's new as of 2.6.
Get the latest version here.
#7
Lemmini / Re: [RELEASE] RetroLemmini Level Editor 1.1.1
January 27, 2026, 09:17:51 PM
Version 1.1.1 hotfix
Out first hotfix for the Editor!
Bugfix
• If the styles cannot be loaded for any reason, an error message is shown and the Editor closes.
Get the latest version here.
Out first hotfix for the Editor!
Bugfix• If the styles cannot be loaded for any reason, an error message is shown and the Editor closes.
Get the latest version here.
#8
Community Edition / Re: [?][CE] Running CE and NL 12.14 from the same directory
January 27, 2026, 05:45:16 PM
Here's a transcripted Discord conversation between myself and Dullstar regarding NL/CE directory organisation:
Following this conversation, it's been decided that CE-specific assets should be uniquely-named, especially if they also exist in NL. Allowing CE to modify/rename any files/folders also used by NL is clearly a bad idea, so the next version (1.1) will at the very least have all CE-specific files and folders marked with a "ce-" prefix. Anything that can be used by both NL and CE (such as levels, sounds, music, etc) or that hasn't been modified for NL will be stored and named exactly as it is in NL 12.14.
From here, we then need to decide how CE-specific files should be stored. From the conversation above, I can figure 3 clear options:
1) Only rename the files, and store them in the same directories as NL. So, for example, the "data/title.nxmi" file has been modified for CE. We'd keep it in the data folder as normal, but rename it to "ce-title.nxmi".
Advantages: File system will look identical to NL | Internal loading is identical to NL, all that needs to happen is renaming the files.
Disadvantages: Harder to keep track of what has been changed/updated | Users might only copy NeoLemmixCE.exe into their NL 12.14 directory and find that things don't work because they haven't copied across the other files they need (so, we're relying on users merging directories correctly whenever there's an update). This could get messy.
2) Provide a single "ce-assets" folder which contains everything that CE needs to run. This is placed into the root directory of NL 12.14 along with the .exe, and can be modified if desired.
Advantages: Very easy to migrate CE stuff to the NL directory | Very easy to keep track of what has been updated | Very easy to debug.
Disadvantages: A bit of extra code (more possibility for loading issues) | User still has to manually copy additional stuff from CE to the NL directory (but at least it's all in one folder).
3) Bake all CE-specific assets into the .exe itself, don't provide any additional folders at all. All the user has to do to run CE from their NL directory is drop the .exe into the root folder. That's it!
Advantages: By far the simplest and easiest solution for the end user.
Disadvantages: Significantly more code (and, I'd have to learn how to embed assets in the .exe) | User cannot mod the CE assets.
4) A mix of options 1 and 3. Bake the CE assets into the .exe, but also provide the individual assets (with "ce-" prefix) in their usual folders so that users can mod files, graphics, etc. Then, only the CE.exe is necessary for allowing CE to run from the NL directory. Users would only need the individual files if they wanted to modify something.
Advantages: Best of both worlds in terms of portability and modifiability.
Disadvantages: The most code, so the most chance for things to go wrong program-side. I'd probably create a new resource management class and run everything through that when loading assets. That should help to at least make debugging easier.
Thoughts?
Discord conversation
Quote from: Discord conversationWill — Yesterday at 12:04 PM
@namida Regarding CE/NL directories, how difficult is it to embed resources into the .exe itself? After giving it some thought, maybe the best option would be to make CE completely compatible with a 12.14 directory, and instead of shipping it with an additional assets folder, just bake those into the .exe and make it fully portable
...
Dullstar — Yesterday at 8:04 PM
I would personally advise against it, as it makes it difficult for users to modify them.
Better to just make sure the CE resources have unique names.
...
Will — Yesterday at 8:15 PM
Hmm, this is a good idea actually 👍
...
Instead of an "assets-ce" folder, which could get messy, look for a "-ce" suffix on the item itself
Dullstar — Yesterday at 8:17 PM
Personally I'd suggest prefixing
...
Reason: sort by name will put same-prefix together
Will — Yesterday at 8:18 PM
Ah
Yes, that's good
...
The only thing with separate and unique data files is that users then have to hunt through the directories to grab the stuff they need (that is, if they're running CE from NL)
The thinking behind a separate "assets-ce" folder is that they could move everything in one go
...
It just makes it that bit more instantly portable
Dullstar — Yesterday at 8:22 PM
As long as anything that's different between a CE and vanilla NL installation has a unique name, they'll merge cleanly -- the OS might ask about overwriting files, but if the shared files are identical it doesn't matter which ones they keep
Will — Yesterday at 8:22 PM
It's also easier to keep track of what has been updated or added
With a single "assets" folder, that is
Dullstar — Yesterday at 8:23 PM
Particularly if you have a lot of them
Will — Yesterday at 8:24 PM
Hm, it's difficult to decide now. Unique names for individual files should probably happen anyway, but then it's do we just mix it in with NL stuff or keep it in its own directory...?
Dullstar — Yesterday at 8:24 PM
Another option might be a ce subdirectory
...
So, instead of having an "assets" and an "assets-ce" (both in the root folder) you'd have a "ce" folder inside of "assets"
Will — Yesterday at 8:26 PM
That could work, sure
We're adding more folders though, then
Dullstar — Yesterday at 8:26 PM
well both options add a folder 🙂 but the advantage of a subdirectory is that it doesn't add a folder to the root
Will — Yesterday at 8:27 PM
Yes, but NL has many subdirectories
Dullstar — Yesterday at 8:27 PM
There's nothing wrong with that though
Will — Yesterday at 8:28 PM
So, if we update a menu image, do we simply add the menu image with a "ce" suffix, add it to a "ce" folder inside of "gfx/menu", or add it to a "ce" folder in the root
...
All have advantages and disadvantages I suppose
What I essentially want is for it to be as easy as possible for someone to drop CE into a NL directory and it just work
But, we do need to be able to update assets or there's not really much point in continuing development
Dullstar — Yesterday at 8:30 PM
Here's a question: by this, do you mean dropping CE into a NL directory to do an in-place upgrade, or do you mean running NL and CE from the same directory?
(i.e. should the vanilla NL installation remain intact?)
Will — Yesterday at 8:31 PM
So, Guigui on the Forums has started a topic about running both from the same directory. I think this should definitely be possible
...
Dullstar — Yesterday at 8:33 PM
In that case, the only important thing is ensuring that all changed files have unique paths; how they're organized between them doesn't matter too much (though I suggest against adding new folders to the root to avoid visual clutter).
In order to install it, you can pretty much just drag and drop, and the OS should handle merging everything properly.
Will — Yesterday at 8:35 PM
The advantage with a single folder in the root is that everything ce needs can go into that folder. Portable, tidy, easy to maintain
Any time anyone's having issues I can simply pass them a copy of that folder with all the updated assets
It's likely to never be more than a few MB
Dullstar — Yesterday at 8:36 PM
If it's mostly gfx I'd say put it in that folder.
(ce folder with everything is fine)
Will — Yesterday at 8:37 PM
It's a mix of text files, images and sounds
Dullstar — Yesterday at 8:37 PM
Now the big "don't do this" is "Oh hey, someone's running me on Linux! I'm going to make a hidden folder in the user's home directory!" (alongside 3,000 other applications that had the same idea)
Will — Yesterday at 8:38 PM
Yeah I won't be doing that. Cba with trying to manage that mess
For me it's either: everything in one folder if possible, or bake everything into the exe
We could even have a combination of the two, where people who aren't bothered about mods can just use the exe, and those who want to mod stuff can add the assets folder
...
Dullstar — Yesterday at 8:40 PM
I feel like the assets folder is mostly stuff a user might reasonably try to reskin.
Will — Yesterday at 8:41 PM
The more we talk, the more I'm realising that's how I'd want to do it. Bake everything ce-specific into the exe, but also check for an optional "ce-mods" or "ce-assets" folder which overwrites the default
Dullstar — Yesterday at 8:41 PM
Embedding defaults can be reasonable.
Will — Yesterday at 8:42 PM
That way, anyone who isn't bothered about modding everything can just drop the exe into an NL directory and they're good to go
...
Dullstar — Yesterday at 8:44 PM
Of course, do keep in mind that "select all the stuff in the zip, and drop that in the NL directory" isn't any more complicated either.
Following this conversation, it's been decided that CE-specific assets should be uniquely-named, especially if they also exist in NL. Allowing CE to modify/rename any files/folders also used by NL is clearly a bad idea, so the next version (1.1) will at the very least have all CE-specific files and folders marked with a "ce-" prefix. Anything that can be used by both NL and CE (such as levels, sounds, music, etc) or that hasn't been modified for NL will be stored and named exactly as it is in NL 12.14.
From here, we then need to decide how CE-specific files should be stored. From the conversation above, I can figure 3 clear options:
1) Only rename the files, and store them in the same directories as NL. So, for example, the "data/title.nxmi" file has been modified for CE. We'd keep it in the data folder as normal, but rename it to "ce-title.nxmi".
Advantages: File system will look identical to NL | Internal loading is identical to NL, all that needs to happen is renaming the files.
Disadvantages: Harder to keep track of what has been changed/updated | Users might only copy NeoLemmixCE.exe into their NL 12.14 directory and find that things don't work because they haven't copied across the other files they need (so, we're relying on users merging directories correctly whenever there's an update). This could get messy.
2) Provide a single "ce-assets" folder which contains everything that CE needs to run. This is placed into the root directory of NL 12.14 along with the .exe, and can be modified if desired.
Advantages: Very easy to migrate CE stuff to the NL directory | Very easy to keep track of what has been updated | Very easy to debug.
Disadvantages: A bit of extra code (more possibility for loading issues) | User still has to manually copy additional stuff from CE to the NL directory (but at least it's all in one folder).
3) Bake all CE-specific assets into the .exe itself, don't provide any additional folders at all. All the user has to do to run CE from their NL directory is drop the .exe into the root folder. That's it!
Advantages: By far the simplest and easiest solution for the end user.
Disadvantages: Significantly more code (and, I'd have to learn how to embed assets in the .exe) | User cannot mod the CE assets.
4) A mix of options 1 and 3. Bake the CE assets into the .exe, but also provide the individual assets (with "ce-" prefix) in their usual folders so that users can mod files, graphics, etc. Then, only the CE.exe is necessary for allowing CE to run from the NL directory. Users would only need the individual files if they wanted to modify something.
Advantages: Best of both worlds in terms of portability and modifiability.
Disadvantages: The most code, so the most chance for things to go wrong program-side. I'd probably create a new resource management class and run everything through that when loading assets. That should help to at least make debugging easier.
Thoughts?
#9
Community Edition / [?][SUG][PL] Bake physics masks into the .exe
January 27, 2026, 05:12:57 PM
This came up during a Discord conversation between myself and Dullstar yesterday. We were discussion baking resources into the .exe, and it was mentioned that the physics masks (currently in gfx/mask) should probably not be in the root directory, but part of the .exe itself.
I'm currently thinking it's worth going ahead with this for CE.
Thoughts?
Quote from: Discord conversationDullstar — Yesterday at 8:39 PM
There WERE a few files in there that I'm surprised AREN'T baked into the .exe, because if they're actually used you definitely don't want to edit them.
Will — Yesterday at 8:39 PM
Such as what?
Dullstar — Yesterday at 8:39 PM
Basher masks, bomber masks... that kind of thing
If those are actually used, editing them would break physics.
Will — Yesterday at 8:39 PM
Yeah, they should definitely be baked in
I'm currently thinking it's worth going ahead with this for CE.
Thoughts?
#10
Lix Main / Re: Newbie with very basic questions
January 27, 2026, 04:06:57 PM
Welcome to the Forums, Ken! No question is too dumb, we're glad to have you here and you're welcome to ask anything you like.
I'll let Simon field these questions as he's Lix dev.
EDIT: A workaround for hatch spawn order is to have multiple hatches overlap each other. So, you could have 5 hatches in the same place, and 1 in another place. Then, 5 Lix would spawn in succession from the overlapped hatches, then 1 would spawn from the single hatch, and then this cycle would repeat. A bit of a hack, but it does work
No question is too dumb, we're glad to have you here and you're welcome to ask anything you like.I'll let Simon field these questions as he's Lix dev.
EDIT: A workaround for hatch spawn order is to have multiple hatches overlap each other. So, you could have 5 hatches in the same place, and 1 in another place. Then, 5 Lix would spawn in succession from the overlapped hatches, then 1 would spawn from the single hatch, and then this cycle would repeat. A bit of a hack, but it does work
#11
Community Edition / Re: [RELEASE] NeoLemmix Community Edition 1.0.1
January 27, 2026, 03:15:13 PMQuote from: Simon on January 27, 2026, 12:05:04 AMThe link for CE 1.0.1 is broken.
Apologies, the download .zip has been removed.
Let's direct people to the RC in the meantime. 1.1 proper should hopefully be ready in a few weeks.
#12
Game Bugs & Suggestions / Re: [✓][SUG][PL] Support for modifier (Ctrl, Shift, Alt) + hotkeys
January 27, 2026, 02:19:27 PM
I disagree to be honest. Wheel up is a forwards motion, so it feels like that should also be "forwards in time", and vice versa. Probably best to implement both and make it optional, since everyone is likely to have a different preference.
For now, I've swapped the direction as Simon suggested, but I would like the option to have it the other way.
What are the alternatives to hardcoding? More menu options?
Meanwhile, whilst looking at this again, I've managed to get the framestepping behaviour hard-coded to the mousewheel itself (rather than the zoom in/out actions). It still relies on modifiers to work.
So, if Ctrl/Shift/Alt are pressed, we get +/- 1/10/100 framesteps, with the wheel determining the direction. If the modifiers are not pressed, the mousewheel performs its user-configured hotkey action (zoom in/out by default, but could be anything).
This is soft-implemented (in commit 9ef191c). I say "soft" because the thought occurs that, since we're also allowing modifier keys to be used as one-shot hotkeys, pressing the modifier to get the mousewheel framesteps also fires up whatever action is linked to Ctrl, Shift or Alt (depending on which modifier is pressed). This is obviously not ideal.
So, really, if a user wants the modifier + wheel behaviour, they need to not be using the modifier keys to perform any other action. I can't think of a sensible way around this.
For now, I've swapped the direction as Simon suggested, but I would like the option to have it the other way.
What are the alternatives to hardcoding? More menu options?
Meanwhile, whilst looking at this again, I've managed to get the framestepping behaviour hard-coded to the mousewheel itself (rather than the zoom in/out actions). It still relies on modifiers to work.
So, if Ctrl/Shift/Alt are pressed, we get +/- 1/10/100 framesteps, with the wheel determining the direction. If the modifiers are not pressed, the mousewheel performs its user-configured hotkey action (zoom in/out by default, but could be anything).
This is soft-implemented (in commit 9ef191c). I say "soft" because the thought occurs that, since we're also allowing modifier keys to be used as one-shot hotkeys, pressing the modifier to get the mousewheel framesteps also fires up whatever action is linked to Ctrl, Shift or Alt (depending on which modifier is pressed). This is obviously not ideal.
So, really, if a user wants the modifier + wheel behaviour, they need to not be using the modifier keys to perform any other action. I can't think of a sensible way around this.
#13
Lemmini / [RELEASE] RetroLemmini Level Editor 1.1.1
January 26, 2026, 10:44:45 AM
RetroLemmini Editor Release Topic
The latest version (1.1.1) is attached to this post. To use, place the .exe into your RetroLemmini directory and run it from there.
This level editor is based on the NeoLemmix Editor, and has been designed specifically to make levels for RetroLemmini. It features many of the Lemmini-specific controls you may be familiar with from the earlier NL 1.43 Editor such as support for steel areas, variable max fall distance, superlemming mode, etc. It expands upon this by adding support for direct playtesting (via F12)*, custom skillsets, visible trigger areas, level hints, and many other QOL features from the more recent versions of the NeoLemmix Editor.
*(N.B. You need RetroLemmini 2.6 or later for this to work).
RetroLemmini Editor supports .ini level files as well as the brand new .rlv format which can be used to file-associate level files with the RetroLemmini Editor (file-associating .ini files is not recommended due to how widespread the .ini file format is on Windows systems). The .rlv format is internally identical to .ini, and is fully supported in RetroLemmini 2.6 onwards.
If you wish to mass-convert between .ini and .rlv, use the Cleanse Levels feature (which can also update your levelpack.ini file to list the levels in the correct format).
Happy level creating!
The latest version (1.1.1) is attached to this post. To use, place the .exe into your RetroLemmini directory and run it from there.
This level editor is based on the NeoLemmix Editor, and has been designed specifically to make levels for RetroLemmini. It features many of the Lemmini-specific controls you may be familiar with from the earlier NL 1.43 Editor such as support for steel areas, variable max fall distance, superlemming mode, etc. It expands upon this by adding support for direct playtesting (via F12)*, custom skillsets, visible trigger areas, level hints, and many other QOL features from the more recent versions of the NeoLemmix Editor.
*(N.B. You need RetroLemmini 2.6 or later for this to work).
RetroLemmini Editor supports .ini level files as well as the brand new .rlv format which can be used to file-associate level files with the RetroLemmini Editor (file-associating .ini files is not recommended due to how widespread the .ini file format is on Windows systems). The .rlv format is internally identical to .ini, and is fully supported in RetroLemmini 2.6 onwards.
If you wish to mass-convert between .ini and .rlv, use the Cleanse Levels feature (which can also update your levelpack.ini file to list the levels in the correct format).
Happy level creating!
#14
Lemmini / [RELEASE] RetroLemmini 2.6
January 26, 2026, 10:44:00 AM
Version 2.6 update 
2.6 is a major update to the RetroLemmini platform, and should ideally be run from a brand new directory to ensure problem-free operation.
Here's what's new:
Dedicated Level Editor!
• RetroLemmini now ships with a dedicated level editor based on the NeoLemmix Editor, with plenty of controls and QOL features to make creating levels for RetroLemmini a breeze.
• It's possible to playtest levels directly from the Editor!
• The Level Pack Compiler can also be run from within the Editor, and can be used to compile your levels into packs.
New Level Format
• RetroLemmini now has its own level format (.rlv) which is interally identical to .ini, but can be used to file-associate level files with the new Editor (much more preferable than doing so with .ini files, as .ini is a commonly-used format on Windows systems). The Editor can open both .rlv and .ini levels, and can easily convert between the two.
• The legacy formats .ini, .lvl and .dat will of course continue to be supported by RetroLemmini itself.
DMA Levels
• All DMA levels have been converted to .rlv format.
• The bonus levels have been regrouped into a new pack called "Yippee! Even More Lemmings".
• Set classicSteel to False for all levels.
Physics
• Basher and Miner steel checks have been relaxed, so that the lemming can tunnel all the way up to the steel block. N.B. Although a worthwhile update, it's one that is very likely to affect existing replays. Apologies for any inconvenience this may cause!
Customisable Hotkeys
• A fully customisable hotkey configuration has been added. You can now map any keypress you wish to any of RetroLemmini's controls.
UI Updates
• Middle mouse button now toggles pause.
• It's now possible to load packs and groups (as well as individual levels) from the Choose Level menu.
• Preview screen now shows "N Lemming(s)" (or "N Superlemming(s)!) rather than "Number of Lemmings N". Also added preview screen support for variable max fall distance (if it's different from the default of 126, it's displayed on the preview screen).
Level Mods
• Mods can now be set per-level as well as per-pack. Per-level mods take priority when both are applied. TIP: Use the Level Pack Compiler to set per-pack mods, and the Editor control to set per-level mods.
Styles
• DMA and special styles have been merged into a single style called "special". This should (in theory) only affect the OG levels which ship with RetroLemmini anyway, but it may be something to be aware of if you happen to have used any of these styles (apple, covox, beast, awesome, etc) to create your own levels.
• Reduced support for "specialStyle" level property to backwards-compatibility only.
• Fixed indexing gaps in Fire, Pillar and Snow.
• Removed accidental pink square (used to measure trigger area when compositing the image) from bubble zapper trap.
• Set default exit sound to "boing".
• Moved one-way-arrow triggers down 8px (so that they match the image itself).
• Pieces can now be marked as deprecated.
Bugfixes
• One-way-arrows are now only ever drawn on terrain (this is also reflected in the Editor).
• "Christmas"/"xmas" style name is now handled gracefully; either is recognised as being the same style.
• Stats are no longer shown on Postview if the level was cheated.
• Framestepping and scroll wheel options are now positive rather than negative bools (opt-in rather than opt-out).
• Further improvements to resource exception handling. More can be done here, but it's a step up from previous behaviour. My goal is to eventually get rid of all stack-trace-style popups and replace them with more user-friendly onscreen messages that inform the user of what has gone wrong, and what they can do about it.
A reminder of what's new as of 2.0.
Get the latest version here.
2.6 is a major update to the RetroLemmini platform, and should ideally be run from a brand new directory to ensure problem-free operation.
Here's what's new:
Dedicated Level Editor!• RetroLemmini now ships with a dedicated level editor based on the NeoLemmix Editor, with plenty of controls and QOL features to make creating levels for RetroLemmini a breeze.
• It's possible to playtest levels directly from the Editor!
• The Level Pack Compiler can also be run from within the Editor, and can be used to compile your levels into packs.
New Level Format• RetroLemmini now has its own level format (.rlv) which is interally identical to .ini, but can be used to file-associate level files with the new Editor (much more preferable than doing so with .ini files, as .ini is a commonly-used format on Windows systems). The Editor can open both .rlv and .ini levels, and can easily convert between the two.
• The legacy formats .ini, .lvl and .dat will of course continue to be supported by RetroLemmini itself.
DMA Levels• All DMA levels have been converted to .rlv format.
• The bonus levels have been regrouped into a new pack called "Yippee! Even More Lemmings".
• Set classicSteel to False for all levels.
Physics• Basher and Miner steel checks have been relaxed, so that the lemming can tunnel all the way up to the steel block. N.B. Although a worthwhile update, it's one that is very likely to affect existing replays. Apologies for any inconvenience this may cause!
Customisable Hotkeys• A fully customisable hotkey configuration has been added. You can now map any keypress you wish to any of RetroLemmini's controls.
UI Updates• Middle mouse button now toggles pause.
• It's now possible to load packs and groups (as well as individual levels) from the Choose Level menu.
• Preview screen now shows "N Lemming(s)" (or "N Superlemming(s)!) rather than "Number of Lemmings N". Also added preview screen support for variable max fall distance (if it's different from the default of 126, it's displayed on the preview screen).
Level Mods• Mods can now be set per-level as well as per-pack. Per-level mods take priority when both are applied. TIP: Use the Level Pack Compiler to set per-pack mods, and the Editor control to set per-level mods.
Styles• DMA and special styles have been merged into a single style called "special". This should (in theory) only affect the OG levels which ship with RetroLemmini anyway, but it may be something to be aware of if you happen to have used any of these styles (apple, covox, beast, awesome, etc) to create your own levels.
• Reduced support for "specialStyle" level property to backwards-compatibility only.
• Fixed indexing gaps in Fire, Pillar and Snow.
• Removed accidental pink square (used to measure trigger area when compositing the image) from bubble zapper trap.
• Set default exit sound to "boing".
• Moved one-way-arrow triggers down 8px (so that they match the image itself).
• Pieces can now be marked as deprecated.
Bugfixes• One-way-arrows are now only ever drawn on terrain (this is also reflected in the Editor).
• "Christmas"/"xmas" style name is now handled gracefully; either is recognised as being the same style.
• Stats are no longer shown on Postview if the level was cheated.
• Framestepping and scroll wheel options are now positive rather than negative bools (opt-in rather than opt-out).
• Further improvements to resource exception handling. More can be done here, but it's a step up from previous behaviour. My goal is to eventually get rid of all stack-trace-style popups and replace them with more user-friendly onscreen messages that inform the user of what has gone wrong, and what they can do about it.
A reminder of what's new as of 2.0.
Get the latest version here.
#15
Closed / Re: [?][BUG][PL] Lemminas sprites not working
January 26, 2026, 09:10:04 AM
Glad to hear it, I'll mark this as resolved and close the topic.