Menu

Show posts

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.

Show posts Menu

Messages - WillLem

#1
Quote from: Guigui on January 30, 2026, 11:26:29 PMBut do you sleep sometimes ?

Like a cat! I get about 9 hours per day on average :lemcat:

I spend a lot more time indoors during the winter so generally have more laptop time. Plus, I work very fast and I use AI to help with a lot of it. Programming is my favourite thing to do at the moment, the problem solving is basically addictive.

Thanks for your concern, though :)
#2
Finally managed to get a clean refactor of this feature (in commit d5bbf0e).

Rather than parsing the level and replay files to match IDs and hack-load the level that way (yuck!), the existing ID matching logic in the mass replay check (thanks, namida!) has been harnessed to grab the correct level object from the already-loaded library.

We still handle multiple matches by displaying a list and letting the user select the correct level to load. No more uninitialized level object warnings :forehead:, all good to go!
#3
This has now been implemented (commit 14fe26d).
#4
Quote from: Simon on January 27, 2026, 09:24:19 PMI'm not sure either whether wheel-up or wheel-down is better for rewinding. Option is sensible.

Having had a chance to play around with it, up=forwards and down=backwards makes the most sense (to me, anyway). I've added an option for it anyway, so that the direction can be inverted.

I'll mark the topic as resolved for now as I think this feature works well as-is. We can test and tweak in the next release.
#5
OK, went ahead and added Cycle Zoom as well. It's a ping-pong zoom action which first zooms in to the maximum possible factor (usually 9), then zooms back out to factor (0), and then this cycle repeats with each hotkey press.

When using the hotkey, the current zoom factor is shown in the minimap so that the user knows if they've reached (max zoom) or (0):



The hotkey is not mapped to anything by default, it must be user-assigned.

Implemented in commit 44ff52e.
#6
Having tested both, ping-pong is definitely the better of the two. Reset looks like a bug, and only goes in one direction.

Quote from: Guigui on January 30, 2026, 04:22:53 PMWhy not add a visual indication on screen or on skill bar when you have reached min or max zoom to prevent from going too far ?

This could optionally be added to the corner of the minimap, I'll look into it.
#7
Quote from: Guigui on January 30, 2026, 01:24:38 PMjust add a "zoom cycle" function.

Not the worst idea. You could, as you've said, then simply configure the time/zoom hotkeys as desired. Would ping-pong (>>> MAX <<<) or reset (>>> MAX >>>) be better?
#8
And done (commit ff5616e).
#9
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.
#10
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.
#11
Quote 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.
#12
Quote 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! :thumbsup:
#13
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.

:lemming: 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).

:lemming: 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.

#14
Lemmini / Re: [RELEASE] RetroLemmini Level Editor 1.1.1
January 27, 2026, 09:17:51 PM
Version 1.1.1 hotfix

Our first hotfix for the Editor!

:lemming: Bugfix

• If the styles cannot be loaded for any reason, an error message is shown and the Editor closes.



Get the latest version here.

#15
Here's a transcripted Discord conversation between myself and Dullstar regarding NL/CE directory organisation:

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?