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.

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.

So... the Forum, then!

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.

Added latest Editor version (2.9.2) to the download folder. See Editor release topic for more details.

2.9.2 Hotfix Update

A quick update with the following features/bugfixes:

Refresh Styles - It's now possible to refresh the styles without closing and re-opening the Editor. So, if a style is modified during a level editing session, it can be refreshed without interrupting workflow! This feature is accessed via a menu item and customizable hotkey (Ctrl+Shift+F8 by default)

Missing Pieces Handling - Much improved handling of missing pieces. The status bar now gives 3 options (Show, Keep or Delete missing pieces) - no more auto-deletion of pieces, and no more need to auto-save with an appended filename. See this topic for more details

Missing Pieces Handling - Bugfix - Status bar is once again shown correctly (it wasn't appearing in 2.8.9b and 2.9)

Custom Trigger Area Colours - Bugfix - Fixed transparency for the non-default colours

---

Get the latest version here.

Finally got this one working. We now have a menu item and hotkey which performs a full styles refresh:



This re-loads the entire styles folder and refreshes the level. In the event of missing pieces following a styles refresh, they're handled in the same way as opening an existing level with missing pieces (see this topic for details).

Please note that it's been decided not to add a button to the Piece Browser for refreshing styles, since it's not something that will likely be reached for very often. The customisable hotkey should be enough for quick access to this feature.

Implemented in commits 4efb55d - 21f3f19.

OK, we now have much better handling of missing pieces. The status bar informs the user that the level contains missing pieces, and offers 3 options (via the "lemming" button):



Show missing pieces - Opens a dialog with a list of the missing pieces
Keep missing pieces - Closes the status bar and returns session to normal (NOTE: the missing pieces will remain in the level file, and will be flagged as missing again next time the level is opened in the Editor)
Delete missing pieces - Removes the missing pieces from the level

So, importantly, the Editor no longer auto-deletes missing pieces and instead gives the user complete control over the session. N.B. It was also decided to remove the behaviour of auto-creating a "_MissingPieces" version of the level. If the user wishes to create a new save of the level with a different filename, they can do this manually.

I'm fairly happy with this as a final version of missing pieces handling. I'll keep the topic open for now, but this should be considered resolved.

Implemented in commit 0fe3481.

Following feedback, the transparency has been improved:


Pink


Yellow


Green


Blue


Purple

Implemented in commit d8dca98, with improvements to the code in 6f74492.

2.9 Hotfix Update

A quick fix for the following bugs:

Piece Browser Window - Bugfix - The Piece Browser window is now re-drawn correctly after minimizing and then restoring the Editor

Piece Browser Window - Bugfix - Minimising the Piece Browser window to the taskbar no longer creates an unhandled exception error

Piece Browser Window - Bugfix - Fixed focus for the piece dropdown control, so hotkeys should now work fully as expected when the Piece Browser window is active

---

Get the latest version here.