here're the solutions to my own levels
https://www.youtube.com/watch?v=cRdHVcEym9k&list=PLYzhWZf5q4HtJ9Une6MN-vW_WY1tLo4iN&index=7

afaik, 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. (Previously, Lemmings were able to step up higher than 6 pixels under very specific conditions.) Fortunately, that bug was fixed before the deadline, but since the level had been created before the fix, this issue occurred.

QuoteAnother 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.

To 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.

I don't intend to release all solutions at the same time I publish my levels. (For all my previous level packs, I've always released the solution replays after some time had passed.) So I also don't want my levels to be marked as "Unverified" just because I didn't include the solutions right away.

QuoteBetter yet, adapt the .nxlv format to contain replay data.

To me, this basically means the same thing: requiring authors to provide a solution together with the level, unless the replay data is somehow encrypted.

People 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.

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.

That was a backroute actually!  Updated the level, and keeping with the original contest rules, updated "Outside the box" part 1 too (although it doesn't change your solution on that one).

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?

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.

Cheers! That was a tricky one, @Crane! As with all your levels, it really gets the old grey matter working Neat design again!

I have a solution for Outside the Box Part 2 as well.