Thank you for the guide WillLem. Now I am still waiting for green checks to disappear again, but it did not happen recently.

One thing I thought about : I set up a process on my machine that kills NL regularly, to prevent me from playing too much  This process brutally does "kill NeoLemmix.exe" if it is running late at night for instance.

Maybe the green checks issue could happen if the kill occurs when the game is accessing userdata.nxsv for instance ? I could not reproduce it though, no matter when I try to manually kill NeoLemmix.exe, my green checks survive.

OK, solved updated versions again.

Spoiler

RE: Your hint, still not sure which level it refers to, but it seems to me to imply an Oh Noer - that would refer to a blocker in a different state, i.e. in the process of exploding. If so, I suppose that must relate to The Lemming Ledger, but I can't see why that would be beneficial unless the explosion is also creating a path that was previously inaccessible.

My thoughts on my solutions, so you can see my working, as it were:

R1:

Spoiler

This is a solution I haven't tried before for The Lemming Ledger. From very early on, I always thought that thin piece of steel half way up the cliff face must serve a purpose and I believed that purpose was for a miner to mine backwards towards therefore closing off any way back. Until now though, I couldn't see a way to put it into practice - the lemmings were too close together and once I started bashing, a couple would always pass by before the miner tunnel was deep enough. What I've done here is extremely fiddly and precise though, which leads me to believe it's still a backroute but hopefully closer to your intended solution.

R3:

Spoiler

When you said I was close a couple of attempts ago, I took that to mean that my initial move of blocking the builder and immediately digging him out so that two lemmings go in opposite directions is correct. That would also tie into the title of Reverse the Polarity! This time I did need the additional digger because if the miner had continued on his trajectory, he would have landed on the platform and therefore, the newly added trap.

No worries! I understand it can be frustrating to spend time on fixing your levels only to watch people backroute them again - not intentionally, by the way, I want to stress that. I just try to find what seems like the most optimal, logical solution to my mind, which I guess doesn't always necessarily coincide with the author's intent. @Guigui's suggestions for fixing your Sour 2 level sound good, I'd definitely try to implement some of those!

On a more general note, I'd just add (from watching other authors fix my backroutes) that some other good tips for enforcing an intended solution are adding strategically placed steel elements, making terrain elements one-way (left, right, up or down arrows, depending on your purposes), reducing the amount of available terrain in key spots, locking release rate lower and adding more traps (both of which Guigui mentioned). I get that not all authors enjoy fixing backroutes, but if it's seen as part of the level creation process maybe it can be an enjoyable challenge in itself: outwitting the solvers, and making them dance to your tune!

Sorry if I'm being dense, but is your hint supposed to be for R1 or R3, since both levels contain blockers?

I'm also sorry to cause you frustration; it might be better to admit that I'm simply just not on your wavelength for these two levels - it can happen. Mostly I am (even if it takes a while to get there a la Outside the Box 2), which is why I like your levels and persist with them, but I think my repeated attempts and failures at The Oubliette also showed that occasionally I just ain't gonna get there!

Nevertheless, I'll take a look at your updated levels, if only to check I can't backroute them for your peace of mind Not actually asking for any hints, it would just be good to know whether I've ever been on the right track with The Lemming Ledger, or whether every single attempt has been far from what you intended!

Quote from: WillLem on November 30, 2025, 04:10:18 AMIn theory, if we wanted to go down this route, could I 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.

You probably could, but hosting it on your own home internet connection is not the best idea. Firstly - in order for people to be able to access it, you need to at least slightly open up your network. If you aren't careful, this can create major security risks. Secondly - you may not have a static IP address, and/or may have a shared IP address. The former makes this setup difficult, while the latter makes it impossible. Thirdly - is your internet connection (and where applicable, power) fast enough, reliable enough, and always-on enough for the job?

The better way to go would be to get a paid plan from a cheap hosting provider. You definitely want one that supports at least PHP (and probably offers a MySQL database too - you might not need it right away, but you likely will want one eventually if you do much with the web hosting). If you want to get a bit more in-depth and more DIY-y, look into a VPS provider.

Where the Pi could come in handy for this is as a development / testing environment. Install a web server on that and use that for development and testing; while opening up a device like this on your home network to the wider internet can quickly get risky, doing so simply between two of your own devices is pretty safe. As a bonus - if you can manage to set this up as such, you most likely will have learnt (at least most of) the skills you need to be able to use a VPS rather than a managed host.

I'd suggest using Debian or Ubuntu (or a fork thereof) as your OS, preferably a version with no "desktop environment" (ie: your Pi won't have a GUI like Windows; if you attach it to a screen, you'll just see a DOS-like prompt. This has two benefits - firstly, that's going to be far more in line with how using a VPS will be; and secondly, far less overhead being used for the GUI, meaning all the device's power can be used for the web server and other servers you might choose to run on it). I'd actually advise - set up a "LAMP" setup first and play around with it a bit; this is for the sake of the understanding it'll give you of the underlying workings. Then when you're comfortable with that, nuke the whole thing (server-wise; you can definitely backup and keep any sites you were working on - and if you don't want to erase the working server just in case, it's a Pi, just get a second microSD), and this time, look into VirtualMin and install that; VirtualMin makes it much more convenient to do a lot of management tasks. For reference: The Lemmings Forums server is a VirtualMin setup (on a DigitalOcean VPS, but as mentioned, I'm planning to move it... it's just a matter of actually picking one, and getting it done).

EDIT: I should clarify that "no GUI on the Pi itself" doesn't mean you're stuck with command line for every web development task you do. You'll use the command line a lot while initially configuring the server (especially the non-VirtualMin one), and might need to occasionally pop out the command line after that (probably remotely via an SSH connection, rather than physically using a keyboard and screen attached to the Pi), but you're mostly going to be working with GUI tools - you're just going to be using those GUI tools on your PC, not on the Pi itself, then uploading your work to the Pi (or, the web server / VPS, once your site is ready to go live).

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

My apologies for the bitterness, that was uncalled for I need to learn to step back from the keyboard for a bit when I get frustrated.

I appreciate the kind words from you both. And Guigui, that is indeed essentially the intended solution for Sour 2. Thank you SO MUCH for your suggestions, genuinely. I'll be sure to try them out tomorrow and see what works.

Quote from: WillLem on November 29, 2025, 04:10:38 PMEven 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.

One 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. This is basically the same sort of setup currently used for falling back to low-res graphics in styles if no high-res graphic is available (except of course, no upscaling is necessary in this case, just loading a different file).

This would be viable for NLCE too, without breaking drop-in compatibility.

I admit I'm getting frustrated that I overlooked so many things, so much that even my V2 change for Lemming Ledger reopened a backroute that my playtester found before the playing phase.  I've streamlined things a bit for the V8 release.  As for Reverse the Polarity, the level is somewhat broken now, and the only fix I could think of was a rather ugly extra platform with a trap on it that probably opens up even more backroutes, knowing my luck!

I suppose to give a hint:

Blockers reverse the direction of lemmings regardless of what state they're in

Lemming Ledger - V8:

Changelog

- V2: Terrain under rightmost brazier is now steel to prevent backroute from JawaJuice
- V3: Removed some of the steel above the exit to prevent backroute from JawaJuice
- V4: Retracted steel above exit slightly to prevent backroute from JawaJuice
- V5: Added a brazier inside a hole in the terrain to patch a backroute from JawaJuice (they're getting good a this!)
- V6: Added left-facing one-way arrows to the terrain above the middle brazier to prevent backroute from JawaJuice
- V7: Thickened wall above exit to prevent backroute from JawaJuice
- V8: Reverted the V7 and improved the V2 and V6 changes to prevent backroutes from JawaJuice

Redneck Redemption - V4 (unchanged):

Changelog

- V2: Bad version (shrunk terrain to the left of the exit, rejected it as a fix, but uploaded it by mistake instead of what is now V3!)
- V3: Added a steel plate to the left of the bottom exit to patch a backroute from JawaJuice
- V4: Reduced the height of the terrain above the steel to patch a backroute from JawaJuice

Reverse the Polarity - V7:

Changelog

- V2: Moved pickups on bottom platform slightly to prevent backroute
- V3: Reshaped the steel under the rightmost Digger pickup to prevent backroute from JawaJuice
- V4: Steel plate and decoration added to upper platform to prevent backroute from JawaJuice
- V5: Reverted change of V4 and moved second Blocker pickup instead
- V6: Added a steel tip to the top platform to prevent backroute from JawaJuice
- V7: Added a lower platform with a trap to prevent backroute from JawaJuice