A step or two closer. We can now preview pieces when building a translation table, and it's possible to add the ID for each piece directly (if known), or by browsing to find the corresponding piece in the RetroLemmini styles folder (directory is remembered for each browse, so the process is fairly quick):

Preview

The next step is to account for transparent pixels at the edge of the linked pieces. We can calculate this and generate an offset value for x, y, flipped x and inverted y. After that it's just making sure piece flags are correct (Erase, No Overwrite, etc).

A dedicated level editor for RetroLemmini may well happen someday (ar, at least, the ability for the current Editor to handle both formats), but for now I've decided to have a go at implementing a simple "Export to INI" tool built-in to the current Editor which spits out a Lemmini-compatible .ini file:

Preview

It's working well so far, just need to finish the translation tables for the default styles (these tables can be built via the GUI so users can add their own styles) and fix up a few other cross-platform quirks and it's ready to go! This means that some* .nxlv levels can now be back-ported to the Lemmini family.

*Those which only use a single Lemmini-compatible style set, only OG skills and objects, and no pre-placed lemmings, zombies, etc. I'll publish a full list once this feature is finished. For now it's still a WIP.

Quote from: namida on November 30, 2025, 01:15:09 AMOne thought that comes to mind is having a "user-gfx" folder, with the same structure. If a file is present in that folder (or the appropriate subfolder) it's used; if not, the default one is used.

The Lemmini family uses this very same system via a "mods" folder. This setup works nicely to preserve user gfx for sure, but it's not without its issues. For example, let's say we needed to add a new icon to levelinfo_icons.png. We can drop the new one into the default location, but if the user has a modded copy in their user-gfx folder, they'll be missing the added icon and might never know.

Having said that, if updates ever went online and were done on a file-by-file basis, I suppose one way around this would be for the engine to detect the presence (or not) of an updated file in the user-gfx directory, and alert the user when they first run the updated program.

In theory, if we wanted to go down this route, is it possible to run a server from a Raspberry Pi 5 just for hosting the necessary files? I have one that I've not really been using much, and it would be fun to learn about file hosting, especially if it might help to make engine updates much easier for everyone.

(Apologies this has gone way off topic btw, please do split this off into its own topic).

Quote from: Armani on November 29, 2025, 10:02:23 AMIdeally players who have online features enabled could access level-pack data in a way similar to the style manager: they'd be able to browse available packs and download whichever packs and whichever optional extras they want.

I had the same idea a few years ago. I've always thought a dedicated downloader (which hosts all packs) would be a good idea. You'd just select the ones you want, hit "download", and get the latest versions of each. The same system can also then be used to keep all of your packs up to date (in a similar way to the style manager).

Even more ideally, engine updates would be handled via online downloads as well. The only issue with this is that players like to modify the gfx in their own copies, and there may be times when it would be necessary for a graphic to be updated, thus overwriting the user's copy. We'd need some way of detecting whether the target graphic is a mod. But anyways, that's for another topic.

Quote from: WillLem on November 26, 2025, 12:13:53 PMI'll add to that by saying we should also advise players to indicate which platform their level is intended for, particularly since SuperLemmix and NeoLemmix currently share a level file format.

To help with this, the SLX Editor now marks levels as "NeoLemmix Level" when in NL mode, and "SuperLemmix Level" when in SLX mode (see topic). The Editor auto-detects the platform to set the mode by default; so, even if authors don't actually select the mode themselves, in the vast majority of cases the level should be marked correctly.

(In SLX and CE, we could even ask the engine to check the level file for the correct format marker, and warn the player if it's incorrect).

Some things to note:

1) .nxlv files are identical in both NL and SLX. Any differences in how the level plays will be down to physics, and nothing to do with the Editor (or the file format) itself.

2) Authors could still make a level for SuperLemmix, mark it "NeoLemmix Level", and release it for NeoLemmix (and vice versa). And, this could (in theory) be done accidentally - the author could have the SLX Editor in their NL directory, and build an SLX level from there. So, it's not a completely foolproof system, but it should help fewer levels to slip through the net.

(The logical next step is simply to create the .sxlv format, to which .nxlv must be converted in order to be played on SLX. Since the text formatting is identical, this should be a doddle to get sorted.)

Implemented in commit 3df088d.

Note that, when in SuperLemmix mode, the level will of course continue to be marked as "SuperLemmix Level".

From GigaLem, on Discord:

Quote from: GigaLem

Code Select Expand

# -----------------------------
#        SuperLemmix Level       
#   Created with SLXEditor 2.9.2
# -----------------------------
I feel if a level is made for neolemmix with the SLXEditor it should say NeoLemmix Level

Progressed further with this today. We can now pin styles (to both ends of the list) as desired, we have an auto-pin for the SLX OG styles, a button to sort all unpinned styles alphabetically, and a search bar to help quickly locate an author or style:



This is working quite well as-is, I've used it to build the master copy styles.ini file and I'm confident it's ready for release. We can always tweak as necessary once it's in use.

Implemented across commits a9c6fb4 - 67b8933.

Brilliant this, thanks for sharing @Crane

Quote from: Armani on November 27, 2025, 04:02:38 AMIncluding replays or not has nothing to do with whether we trust players or not.

Yea, I know. I was joking, hence the lemoji. I can completely understand your reasons for not wanting to share solution replays up front, just to be very clear about that.

Quote from: Armani on November 27, 2025, 04:02:38 AMwhat if ... we created a dedicated website where users could voluntarily upload all sorts of assets related to each level, including styles, solutions, music, previous versions of the levels and so on so that players could download as much or as little as they want.

How would this differ from the platform we already have (i.e the Forum)?

Quote from: Armani on November 25, 2025, 04:49:44 PMI want to emphasize again that this incident began with the level of one specific user.

Sure, but I'm widening the view out to all such incidents and offering a potential solution.

Quote from: Armani on November 25, 2025, 04:49:44 PMIn fact, despite having played countless levels over the years, this is the first time I've ever encountered an unsolvable one.

Agreed, it is relatively rare. I think I've only seen it once or twice in the six years I've been active. I suppose if it was a regular problem there might be more need for an in-built solution.

Quote from: Armani on November 25, 2025, 04:49:44 PMFor me the marker actually would matter. It's true that long-time forum members wouldn't doubt the solvability of my levels but new users join from time to time, and I would not want my levels to carry a label that might unintentionally suggest something is wrong with them. The word "unverified" can easily create the wrong impression, even if that's not the intention.

I see, fair enough.

Quote from: Armani on November 25, 2025, 04:49:44 PMI prefer not to release all solutions at the same time I publish my levels because I enjoy seeing how far players can get without having the answers available from the start.

Surely if we can trust users to make solvable levels, we can trust them not to look at solution replays for spoilers!

Quote from: Armani on November 25, 2025, 04:49:44 PMMy approach is very much in line with that long-standing community standard.

Just because something is "long-standing", and a "standard", doesn't mean that (a) it's the right way to do things, (b) it's the best way to do things, or (c) it shouldn't be subject to scrutiny, review, and potential updating.

In other words, "it's always been that way" shouldn't be a strong argument not to try something different.

But yeah, in this particular instance I'll concede that a built-in verification system probably is a bit drastic, and we can simply continue to advise that people ensure their levels are playable.

I'll add to that by saying we should also advise players to indicate which platform their level is intended for, particularly since SuperLemmix and NeoLemmix currently share a level file format.

Quote from: Armani on November 25, 2025, 05:24:53 AMafaik, the impossible talisman that kaywhyn pre-tested wasn't because the author intentionally added an impossible talisman to their level, but rather because a bug fix ended up breaking the talisman.

Whatever the reason, the level was unsolvable, causing the player unnecessary annoyance and wasting a significant amount of their time. If there's a simple way to help prevent this, we should do it.

Quote from: Armani on November 25, 2025, 05:24:53 AMTo me, this sounds like: If you don't provide solution replays when publishing your level, your level will be given a "Unverified" label on the preview screen.

Yes, exactly. If you fail to provide verification for your level, it should be marked as unverified.

Quote from: Armani on November 25, 2025, 05:24:53 AMI don't intend to release all solutions at the same time I publish my levels.

Why not?

Quote from: Armani on November 25, 2025, 05:24:53 AMPeople on the Lemmings Forum have done a great job ensuring that their published levels remain solvable. The honor system has worked well so far.(outside of the broken talisman, it's just one person so I think it's more likely on their end) I believe we should continue trusting level authors to ensure their own levels are solvable, rather than enforcing something systematically.

You're right that it works the majority of the time, but there will always be examples that slip through even when it isn't the author's fault. Unsolvable levels have been a problem since the beginning of custom level creation; if we can introduce a way to ensure that levels are solvable, we should do it. And as others have pointed out, there are other benefits to ensuring a solving replay is provided/available (i.e. documenting the intended solution).

Authors who (for whatever reason) don't want to provide verification can choose not to, but their levels should then be marked as unverified. They would still be playable, and if it's a well-established author such as yourself, I imagine the "Unverified" marker wouldn't really matter so much.

If people dislike the idea of it outright saying "Verified/Unverified", we could make it a symbol that's either monochrome (when unverified) or full color (when verified) like when a talisman is completed, and put it in the top left corner of the preview screen out of the way but visible.

---

I suppose the counterpoint would be: if the author doesn't provide a replay, the player can simply choose not to play the level. This in itself might help to incentivise authors to provide solving replays.

But, as we've seen, in practice this doesn't really happen. Players like to have new levels, that's what the custom engines are for. Built-in failsafes should really be an expected part of this.

The three engines I currently maintain (SuperLemmix, RetroLemmini and NeoLemmix CE) can all be hard-coded to autosave successful replays. It's already default behaviour for all, but maybe we should just go a step further and make it non-optional?

Another idea might be to require the presence of a working .nxrp file in order to load a level. On first loading the level, we run the MRC for just that level and its detected replay (this would take milliseconds and would happen silently). If it passes, we can display "Verified Solvable" on the preview screen. If it fails or the replay is missing, we display "Unverified" instead. The user can still play the level if they wish.

Better yet, adapt the .nxlv format to contain replay data. The loading procedure then reads this data directly, and tests it to see if the level (and its talismans) are solvable. Getting the data into the level file would be easy enough: each time the level is played and solved, add the data to the level file. If data exists already, overwrite it. Create new sections for talisman data. Don't overwrite if the level isn't solved.

Implemented in commit 834bc1b2.

OK, I've gone ahead and added a zoom factor indicator to the corner text (where the X/Y co-ordinates are displayed):



It's relatively unintrusive so there's probably no need to make this optional. It shows the current zoom level (and users will get to know what is the min/max possible allowed by their monitor/screen res), so this should serve as an indicator of whether zoom in or out is possible from the current factor.

I'll keep the topic open in case anyone has any ideas/suggestions, but this should otherwise be considered resolved.

Implemented in commit 8d1441b.