- Welcome to Lemmings Forums.
Recent posts
#11
Lix Main / Re: Newbie with very basic que...
Last post by Silken Healer - January 27, 2026, 09:27:45 PMQuote from: Simon on January 27, 2026, 09:11:48 PMC) More control over entrance hatches is interesting. I feel that the existing system is too simplistic: Round-robin across all hatches from the same initial count of lix.I definitely feel as if being able to adjust the ratio of initial Lix for each hatch would be a good, low-hanging fruit-type suggestion which could maybe be added within the next few updates
. I'm surprised no one has thought of it already honestly. #12
Game Bugs & Suggestions / Re: [?][SUG][PL] Modifier + Mo...
Last post by Simon - January 27, 2026, 09:24:19 PMI'm not sure either whether wheel-up or wheel-down is better for rewinding. Option is sensible.
I think it's correct to continue offering one-shot LCtrl, RCtrl, LShift, ... If it clashes with that rewind, so be it. I assume the wheel-rewind will eventually be optional altogether (not merely which direction, but whether the wheel rewinds at all).
No idea yet for how to reconcile the feature with the remaining hotkey mappings.
-- Simon
I think it's correct to continue offering one-shot LCtrl, RCtrl, LShift, ... If it clashes with that rewind, so be it. I assume the wheel-rewind will eventually be optional altogether (not merely which direction, but whether the wheel rewinds at all).
No idea yet for how to reconcile the feature with the remaining hotkey mappings.
-- Simon
#13
Lemmini / Re: [RELEASE] RetroLemmini Lev...
Last post by WillLem - January 27, 2026, 09:17:51 PMVersion 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.
#14
Lix Main / Re: Newbie with very basic que...
Last post by Simon - January 27, 2026, 09:11:48 PMWelcome!
Happy to see Lix working well on Fedora, and that you aren't running into any problems even with your grand level designs.
None of A, B, C are possible in Lix 0.10. Silken has already explained it well while I was typing, but I'll post the full answer nonetheless.
A) I have no satisfactory explanation for why there is no upwards digging. The best argument is historical. I reimplemented the 8 skills from Lemmings 1 and then a few things from Lemmings 2, and that is it so far.
B) Splat height is fixed. Even a fixed height is hard to eyeball. It needs the splat ruler in play, and I still have an open bug report for how the editor lacks the splat ruler. It's the nastiest part of running physics mentally, and I'd prefer not to exacerbate.
What exactly do you want to do with adjustable splat height? Do you need falls survivable in specific places? You can catch lix at the bottom of a long fall with steam (the white steam clouds, or the blue transportation beam, both are in the traps dialog) and it resets the lix' fall distance.
C) More control over entrance hatches is interesting. I feel that the existing system is too simplistic: Round-robin across all hatches from the same initial count of lix. At the very least, it should become possible to place a single lix into a level outside of the existing round-robin.
You can already have different shirt colors by making multiplayer levels. You can run them in singleplayer, you control every team. You can't make puzzles in this way (multiplayer levels don't have a goal number of lix to save), but you can still make pretty paths.
-- Simon
Happy to see Lix working well on Fedora, and that you aren't running into any problems even with your grand level designs.
None of A, B, C are possible in Lix 0.10. Silken has already explained it well while I was typing, but I'll post the full answer nonetheless.
A) I have no satisfactory explanation for why there is no upwards digging. The best argument is historical. I reimplemented the 8 skills from Lemmings 1 and then a few things from Lemmings 2, and that is it so far.
B) Splat height is fixed. Even a fixed height is hard to eyeball. It needs the splat ruler in play, and I still have an open bug report for how the editor lacks the splat ruler. It's the nastiest part of running physics mentally, and I'd prefer not to exacerbate.
What exactly do you want to do with adjustable splat height? Do you need falls survivable in specific places? You can catch lix at the bottom of a long fall with steam (the white steam clouds, or the blue transportation beam, both are in the traps dialog) and it resets the lix' fall distance.
C) More control over entrance hatches is interesting. I feel that the existing system is too simplistic: Round-robin across all hatches from the same initial count of lix. At the very least, it should become possible to place a single lix into a level outside of the existing round-robin.
You can already have different shirt colors by making multiplayer levels. You can run them in singleplayer, you control every team. You can't make puzzles in this way (multiplayer levels don't have a goal number of lix to save), but you can still make pretty paths.
-- Simon
#15
Community Edition / Re: [?][SUG][PL] Bake physics ...
Last post by IchoTolot - January 27, 2026, 09:01:34 PMQuoteIcho's position is interesting. What do you think about externalizing even more physics? E.g., create a physics configuration text file. Let people set custom splat height in it. Warn nonintrusively about custom physics when it contains anything else than 63 safe, 64 dead.
Yeah you are right, I think at that point it would create more confusing stuff than do any good. I would be against that.
I rather would agree to put the masks in the exe instead of externalizing even more physics.
I just like really like having files visible instead of big data-blobs hiding them from me. Flashbacks to old games where I wanted to listen to the soundtrack only to see that all tracks where hidden in data-blobs. Sad times!
I 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.
Just be careful!
#16
Lix Main / Re: Newbie with very basic que...
Last post by Silken Healer - January 27, 2026, 08:55:26 PMQuote from: ac4rd on January 27, 2026, 02:55:04 PMA.) I'd like Lixes that could dig *upward* on an angle, that is, miners going up on an angle instead of down, if they exist.Such a skill does not exist. Simon is open to suggestions for Lix however (Simon being open to suggestions also applies to pretty much all your points here).
Quote from: ac4rd on January 27, 2026, 02:55:04 PMB.) Can "splat height" be adjusted somewhere, such that falling X onto steel kills the little Lix but falling the same X height onto a tree or bush does not? (this may exist but I don't find it)No. You can use the transportation beam (edit: after reading Simon's reply I learnt also the white steam clouds have this effect) item to reset the Lix's fall height mid-way during a fall to get the same effect, but you'd have to put it the same height above every single tree and/or bush, and the item is not invisible so it might ruin the effect. There may? be a way for you to copy this item and make it invisible so you could give a seamless effect. If it is, I'm not sure if other people need to have the copy item downloaded and place in the ...\lix\images directory to play your level (which would be more of a problem for multi-player levels). I have to admit this one of the few aspects of Lix I'm unsure on. Simon will probably clarify this for me and you when he sees this post.
Quote from: ac4rd on January 27, 2026, 02:55:04 PMC.) Is there a way to control how many Lixies emerge from each entrance hatch? Or control spawn speeds for individual entrances?You cannot adjust the ratio of total lix each hatch gets. The spawn interval is a per-level setting which is the same for all hatches and can't be adjusted during normal gameplay in Lix. This is unlike Lemmings where it could be adjusted during gameplay.
Quote from: ac4rd on January 27, 2026, 02:55:04 PMOr to give our Lixes different colored shirts or something for different entrance hatches?Only in multi-player.
#17
Community Edition / Re: [?][SUG][PL] Bake physics ...
Last post by Simon - January 27, 2026, 07:38:46 PMI would bake this into the executable.
But there are alternatives. Allow editing the file, but checksum on load and warn nonintrusively on mismatch.
Icho's position is interesting. What do you think about externalizing even more physics? E.g., create a physics configuration text file. Let people set custom splat height in it. Warn nonintrusively about custom physics when it contains anything else than 63 safe, 64 dead.
-- Simon
But there are alternatives. Allow editing the file, but checksum on load and warn nonintrusively on mismatch.
Icho's position is interesting. What do you think about externalizing even more physics? E.g., create a physics configuration text file. Let people set custom splat height in it. Warn nonintrusively about custom physics when it contains anything else than 63 safe, 64 dead.
-- Simon
#18
Community Edition / Re: [?][SUG][PL] Bake physics ...
Last post by IchoTolot - January 27, 2026, 05:55:43 PMLooked inside the folder and I can maybe see somebody wanting to swap the highliter or countdown.
But yeah the other stuff would break physics and I understand the reasoning behind this, but all the files are there and visible so everything could easily be swapped out or modified if desired.
But what if somebody accidentally deletes/edits them? Well, what if somedody deletes/edits files in system32? Here just re-download the NL files and fixed.
I also really like to see where the actual files are instead of just big data blops, but that's preference.
This would seem like going a step backwards to me.
But yeah the other stuff would break physics and I understand the reasoning behind this, but all the files are there and visible so everything could easily be swapped out or modified if desired.
But what if somebody accidentally deletes/edits them? Well, what if somedody deletes/edits files in system32? Here just re-download the NL files and fixed.
I also really like to see where the actual files are instead of just big data blops, but that's preference.
This would seem like going a step backwards to me.
#19
Community Edition / Re: [?][CE] Running CE and NL ...
Last post by WillLem - January 27, 2026, 05:45:16 PMHere'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?
(Your silence = I'll probably go with option 4).
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?
(Your silence = I'll probably go with option 4).
#20
Community Edition / [?][SUG][PL] Bake physics mask...
Last post by WillLem - January 27, 2026, 05:12:57 PMThis 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?
(Your silence = this will probably go ahead).
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?
(Your silence = this will probably go ahead).