NLCEPlayer commit a7ff72b.

This is the color scheme for the next version. We can test it to see what we think and fine-tune it later if necessary:

Use GREEN for everything except the following:

TEAL/CYAN = save requirement is met | 'cut X tasks' | only neutrals remain*

YELLOW = level has a time limit

RED = not enough lemmings remain | time has run out (alongside Simon's red sand timer)

BLUE = panel button hints

*Decided to keep this in because it is useful info which might not be obvious by looking at the gameplay area (e.g. if the lems are in a bunch). Shall we change the lem icon to neutral colors as well...?

There are some inconsistencies here, but we are using less colors, and when color changes happen, it's now more obvious why. So, we're closer to the goal, but more could be done.

NLCEPlayer commits 280c8bf - f583fdb.

Added some extra spacing, recolored the lines, and removed the 'Release Rate' line:



The 'Release Rate' line not being there does look better if the level has a time limit. Without either (and especially if the level doesn't contain Neutrals or Zombies), the Preview screen suddenly looks a bit barren:



I prefer the button text being blue.

Thoughts?

Quote from: Guigui on August 19, 2026, 08:45:35 AMit just make more sense to have author not between level and pack name : you give all infos on the level and its position, then you give credits to its author

Putting the author immediately after the level title makes more sense because the level author and the pack author might be different.

Quote from: Simon on August 19, 2026, 07:05:55 PMTitle is important, and time limit is important (hide the entire line if no time limit). And the buttons along the bottom are important. Maybe reserve green for those buttons?

Green pops more and should be reserved for level info. I was thinking the buttons should be blue, and then nothing else in the level info should be blue.

Quote from: Simon on August 19, 2026, 07:05:55 PMTime limit line on preview is yellow ... Therefore time limit during play should be yellow, no?

OK

OK... here's an example of what the Preview screen looks like with:

'Title' and 'Author' in GREEN
'Pack title - Group #' in BLUE
'Save N of N' in GREEN
'N Zombies, N Neutrals' (if present, not shown) in TEAL
'Release Rate / Spawn Interval' in BLUE
'Time Limit' in YELLOW



Honestly, I now think this looks a bit bland.

Note that it's now possible for users (and pack authors) to set their own Preview screen colors. Here are the possible basic colors (we can do all shades in-between, of course):

# EXAMPLE_COLOURS
# 0.300 = PINK
# 0.350 = RED
# 0.450 = ORANGE
# 0.550 = YELLOW
# 0.750 = GREEN
# 0.900 = TEAL
# 0     = BLUE (DEFAULT)
# 0.100 = INDIGO
# 0.250 = VIOLET

Thanks for reporting. The paint check was previously only looking for the 'No One Way' flag; Steel bricks have now been added to this check.

Fixed in RLPlayer commit 842c673.

Many thanks for the responses!

Maybe we could implement this in stages.

We could start off with a checkpoint system. The game state could auto-save at some arbitrary interval (15 seconds?). 'Rewinding' would then simply jump back to the most recent checkpoint.

If we can get this working, there may be the possibility of then utilising the checkpoints as places to jump forward from to reach a particular frame, similar to NeoLemmix's savestate-based framestepping system.

To be clear though: such a measure would be used as the basis of a fast-rewind control rather than a backwards framestepping system, which I do not want to add to RetroLemmini (for the reasons given in the OP). The goal here is simply to make it quicker for the player to move back to some point in the level before a mistake was made, not to grant fine-tuning control over the replay.

Also, this is a long-term goal. There are a few other things that need to be sorted out in RetroLemmini before we can get to this.

It's good to have the feedback, though. Thanks again

Implemented in NLCEPlayer commit 3489449.

'Nudge Viewport' hotkeys can nudge the minimap view up, down, left and right by a user-specified number of pixels.  This can be set up in Hotkey Configuration.

Fixed in NLCEPlayer commit 6797a1d.

This is fixed using a bool flag. I'd rather find a cleaner way to eat Post/Preview Screen inputs at the start of the game. But, for now at least, behaviour is as expected.

I'm going to just make a call on this one. Turning a Miner with a Blocker is relatively uncommon, and guarding against clipping trumps preserving replays.

Let's reset the Miner to frame 0 after being turned by a Blocker. This is the cleanest and most elegant solution to this bug.

To be clear: this is a physics update that may break replays, but we do now have the Batch Replay Check feature! It should be relatively easy to find and fix and replays that might be broken by this bugfix.

Fixed in RLPlayer commit ac7c69b.

Should RetroLemmini have a Rewind button? I'm currently about 50:50 on this.

On the one hand, RetroLemmini has a replay system which can be used to backtrack when the player makes a mistake anyway; from one point of view, it seems unnecessary for the player to have to wait for the replay to fast-forward to the part of the level they're trying to get to.

On the other hand, RetroLemmini currently represents the best way to experience the original games on a modern PC (in my opinion), and the replay feature is there as a pleasant bonus rather than an integral part of the way the game is played, like it is in NeoLemmix. I'd be wary of beginning to introduce the ability to fine-tweak replays, and essentially ending up with yet another 'Lemmings replay editor'.

If we do include any sort of 'Rewind' feature, it certainly shouldn't be a frame-by-frame backstepping sort of feature. The possibilities I imagine are these:

1) 'Fast-rewind' (similar to the current fast-forward but moving in reverse)

2) A checkpoint system, which allows the player to jump back to the most recent checkpoint

3) Jump back to the last skill assignment

All of the above provide a way to quickly undo mistakes without introducing the kind of granular replay editing that NeoLemmix and Lix offer (which, again, I'd much rather avoid).

I'm very hesistant to do even this to be honest, because I like the fact that RetroLemmini has higher gameplay stakes. However, it's difficult to ignore the fact that the replay system already exists and already means that players can just fast-forward to the part of the level that they need to redo. Why not, then, allow them to get there a bit more quickly.

One other possibility here is to implement a super-fast-forward, which allows the player to advance very quickly through the replay; as fast as the rendering will allow, I imagine.

Please share your thoughts.

I need feedback on this. If I don't hear back from anybody, I'll assume that people are happy with RetroLemmini as it is and I won't take any action.

Quote from: Proxima on August 14, 2026, 07:00:05 PMFor the save requirement ... NLCE adds a tick to the flag, which is also good. (I would still prefer the negative numbers, as "-5" conveys "5 short of the requirement" a lot more easily than just "5" does, but maybe there's already an option for this?) Anyway, no colours needed here and that's great.

There is an option to count up from 0 then display '+n' once the save requirement is met. Some users (myself included) prefer this to the negative save count.

Yes, no colours are needed here, but I like the idea of using teal to bring attention to this part of the display once the save requirement is met - let's give this a try and see if it's OK. Certainly, the save count should be green whilst the SR is unmet. We all agree here.

Quote from: Proxima on August 14, 2026, 07:00:05 PMThe timer needs to indicate (at least) three possible states: infinite; time limit counting down; overtime
...
Will argues that red shouldn't be used for overtime because red conveys urgency, while you can remain in overtime as long as you want; but the same is true for "not enough lemmings left" and we're fine using red for that. (Or should we change it to blue for both?)
...
Completely agree with Simon that there is no need for any "15 seconds left" indication.

Red for both is fine, let's give that a try. And OK, we'll do away with the 15 seconds 'warning'. Nobody has piped up in support of that, so... let's get rid of it and see if anyone complains later.

Quote from: Simon on August 15, 2026, 12:49:23 AMAlternative to minus sign: The yellow hourglass (that has sand in both halves) turns red (together with its number) and has all the red sand in the bottom half.

This is a great idea!

Quote from: Simon on August 15, 2026, 12:49:23 AMThe satisfied save requirement is a flag with a checkmark. Consider removing the flag and have only a checkmark in this icon. Makes it easier to see the checkmark, and the switch into the winning state will pop a little better.

Let's see if using teal to make this pop is good enough. Flag-with-checkmark works nicely, I'd personally prefer to keep this as it is.

---

Current proposal, then:

Use GREEN for everything except the following:

TEAL/CYAN = save requirement is met | level has a time limit

RED = not enough lemmings remain | time has run out (alongside Simon's red sand timer)

BLUE = panel button hints

I think this could work nicely. Let's give it a try in the next update.

There are 2 possible fixes here:

1) After being turned by a Blocker, suppress the next 4px horizontal movement.

2) After being turned by a Blocker, reset the action/animation to frame 0.

Both of these fixes guarantee that the Miner will either not clip through terrain, or will destroy the terrain directly in front of them (after turning). However, neither looks quite right (the 2nd is definitely the better of the two in this regard), and both will likely break replays involving turning a Miner with a Blocker.

All other fixes (checking ahead for terrain, checking for during-movement terrain) interact poorly with existing physics, which often has the Miner stepping through existing terrain anyway.

NOTE: It seems worth mentioning that this bug is also present in SuperLemmini. So, it's not being caused by any changes to Miner physics made in RetroLemmini.

The only other option I can think of is to completely refactor the Miner's movement cycle so that it moves across-then-down rather than down-then-across. This could interact poorly with the sprite, though, and still wouldn't guarantee no clipping.

OK... so, the bug reported by Flopsy is actually not related to the 2px vertical movement, it's related to the 4px horizontal movement that the Miner takes at physics frames 6 and 30. This is responsible for clipping a Miner through terrain in the very specific case that:

(a) There is no more than 4px horizontal terrain in front of the Miner (in this instance, a Builder brick)

and

(b) The Miner has been turned by a Blocker at some point prior to (or at) frame 6 or 30, but not on a destruction frame (which would destroy the terrain anyway)

So, a particularly nasty bug with no immediately obvious fix.

I think this might be a symptom of a bugfix (NLCEPlayer commit 8dbba16) intended to prevent Preview/Postview Screen key presses and mouse clicks from making their way into the game when auto-skip is active. You'll probably find that if you start up Playback Mode and un-check 'Auto-skip Preview & Postview Screens', this bug will disappear. Or, press F1 to restart, skip forward 1 frame, then you'll be able to unpause using the [Space] bar (or whatever key Pause is linked to).

This is clearly not ideal. I'll try out a different fix for the 'delayed input' bug, ensuring that frame 0 will allow key and mouse presses again (when in Playback Mode + Auto-skip).