- Welcome to Lemmings Forums.
Recent posts
#21
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
#22
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.
#23
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?
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?
#24
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?
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?
#25
Lix Main / Re: Newbie with very basic que...
Last post by WillLem - January 27, 2026, 04:06:57 PMWelcome 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
#26
Community Edition / Re: [RELEASE] NeoLemmix Commun...
Last post by WillLem - 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.
#27
Lix Main / Newbie with very basic questio...
Last post by ac4rd - January 27, 2026, 02:55:04 PMGreetings from a Lix neophyte, and thanks for making this website possible and keeping the Lemmings family alive. I didn't know how deeply the Lemmings fanbase was! Like most of you probably did, I loved the original Lemmings. I'm an absolute Lix newbie and, looking at the Lix general postings, I feel like a first-grader listening to an algebra class.
Quick intro: My name is Ken, I'm an old retired guy, playing "Lix" casually, mostly designing long paths without traps, and sending the little Lixes off marching. The fiddling with designs is my favorite part. I'm using Lix 0.10.30 on a Fedora laptop from the official (I think) repository. Zero problems.
My questions will seem dumb to you tech folks, but I'm wondering if there's a patch or modification or update that might have any of this--advice welcome, thanks in advance!
A.) 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.
B.) 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)
C.) Is there a way to control how many Lixies emerge from each entrance hatch? Or control spawn speeds for individual entrances? Or to give our Lixes different colored shirts or something for different entrance hatches?
I rarely add traps; I mostly make little pathways for my little Lix amigos, watch them marching around as I fix paths and think of new things, and then usually get tired of any one level and start a new one before finishing or refining the first. I rarely get one level really finished. If it's OK i'll include a link to screenshots; if not allowed, please delete and my apologies. ("It's my first day!")
https://kuzenski.org/lix_levels
Thanks! --ken ac4rd
Quick intro: My name is Ken, I'm an old retired guy, playing "Lix" casually, mostly designing long paths without traps, and sending the little Lixes off marching. The fiddling with designs is my favorite part. I'm using Lix 0.10.30 on a Fedora laptop from the official (I think) repository. Zero problems.
My questions will seem dumb to you tech folks, but I'm wondering if there's a patch or modification or update that might have any of this--advice welcome, thanks in advance!
A.) 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.
B.) 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)
C.) Is there a way to control how many Lixies emerge from each entrance hatch? Or control spawn speeds for individual entrances? Or to give our Lixes different colored shirts or something for different entrance hatches?
I rarely add traps; I mostly make little pathways for my little Lix amigos, watch them marching around as I fix paths and think of new things, and then usually get tired of any one level and start a new one before finishing or refining the first. I rarely get one level really finished. If it's OK i'll include a link to screenshots; if not allowed, please delete and my apologies. ("It's my first day!")
https://kuzenski.org/lix_levels
Thanks! --ken ac4rd
#28
In Development / Re: The Tomato Watcher's Next ...
Last post by weirdybeardy - January 27, 2026, 02:25:36 PMThese look brilliant. I'm really looking forward to playing them.
I can feel another Lemmings binge coming on... I feel it in me waters...
I can feel another Lemmings binge coming on... I feel it in me waters...
#29
Game Bugs & Suggestions / Re: [✓][SUG][PL] Support for m...
Last post by WillLem - January 27, 2026, 02:19:27 PMI 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.
#30
Lemmings Main / Re: Atari 2600 Lemmings - in d...
Last post by twiggy - January 27, 2026, 07:52:16 AMThis is fascinating. Looking forward to further updates on this