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.

Reading back over this topic, it's my opinion that the best solution is to keep the existing styles.ini file, and have a GUI-based Style Manager with which the user can easily re-order, rename, add to, and ultimately save the style list as they wish.

I've made some progress with this already. Here's what we have so far:



It's fairly basic at the moment, but can absolutely be used to quickly and easily edit the styles.ini list. It's also coupled with the new Refresh Styles feature, so the dropdown lists are updated on-the-fly without having to close and re-open the Editor.

A "Group by Author" button could probably be introduced, as well as a "Sort Alphabetically" button. There may be a way to implement style pinning as well, so that the position of any pinned styles is preserved when performing an auto-sort. Note that, as has been agreed throughout this topic, the OG styles will continue to appear at the top of the default list (of course, user-pinned styles would supersede these).

In terms of keeping the list up to date without it overriding preferences, a master copy of styles.ini could be hosted on the Editor's GitHub repo page. An "Update Styles" button could then read from the master copy and auto-insert any missing styles into the user's copy, by author first, then alphabetically. We can show a list of which styles have been added using this process. NOTE: This would only add the style to the list, it wouldn't actually download the style itself.

Thoughts? Is there anything else we're missing here?

Fixed in commit a8071f6.

Since there have been no replies in a while, and SLX Editor now has horizontal-only and vertical-only piece movement (via hotkey + drag action), this one can be marked as resolved.