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

Quote from: IchoTolot on July 24, 2026, 02:19:04 PMI think having the 'Replay-single-mode' as an optional setting could be the best thing here

Agreed: new players and those not fully accustomed to the Replay features need to be able to tailor their experience. We should provide options.

However, adding a 'Single Mode' option would inadvertently create three replay modes: 'Red R', 'Blue R', and the proposed 'Single Mode', all of which must be maintained.

I'd suggest that a simpler solution here would be to abandon the proposed 'Single Mode' as its own thing and instead offer players the option to have 'Red R' or 'Blue R' as their default (they'd still be mutually togglable in-game).

Then, we'd fine-tune the 'Blue R' mode to be more like the proposed 'Single Mode'.

Quote from: Simon on August 16, 2026, 04:58:00 PMI'm beginning to feel that airclick-to-cut is a fundamental design dead-end

In what way? And, why?

Quote from: Simon on August 16, 2026, 04:58:00 PMAlong the bottom of the screen, always show the replay as a timeline, like what a video player displays.
...
Tweaker always open, which is practically the timeline, but bigger and with all the bells and whistles.

Initial reaction: Hm. This would push NeoLemmix even further into 'Replay Editor' territory (as opposed to 'Video Game' territory) than it already is.

On second thoughts, though, these are good ideas. Perhaps the Replay Editor (currently a list-based Windows dialog) could be ditched in favour of this sort of thing. It shouldn't be displayed by default though, even in Replay mode; let the user call it up via a hotkey/panel button. We need to keep the UI as clear and clutter-free as possible.

In any case, this needs its own topic.

Quote from: Simon on August 16, 2026, 04:58:00 PMOver each lemming who will receive a replay assignment in the next 5 seconds, we paint a large arrow with the skill on it and a countdown. You can click an [X] on that arrow to cut the lemming's future.

Another good idea, let's put this into its own topic as well though.

This topic is about whether or not we should merge/revise the existing replay modes. UI-related stuff is important, of course, and we can certainly keep small tweaks within the scope of this topic, but more extensive overhauls belong in their own individual topic(s).

Quote from: namida on August 16, 2026, 10:20:20 PMThis might feel "good enough" that the periodic demands for reintroducing timed bombers finally die out for once and for all.

How so?

And, I doubt that this particular aspect of the game will ever be resolved. As long as we have users who experienced any one of the original Lemmings ports, timed bombers will be a thing that people remember and possibly miss (if they're absent from a particular clone engine). And, the community will always be split between those who like them and those who don't.

SuperLemmix, IMHO, does it best: the engine includes both types of Bomber as separate skills. Level designers can choose which to put in their level, and can even use both side by side, so that the player can decide which ones to use where (and, this can of course be built into the fabric of the level's puzzle).

But, that's also another topic!

Most likely related to this bug.

The Miner is moved down 2px at frame 0. I haven't been able to figure out why this is, but I imagine it's so that the sprite lines up correctly with the movement.

It probably does warrant further investigation if this is what we're seeing again and again (i.e. Miners clipping through terrain). In the case reported by Flopsy, the movement takes the Miner's foot position into the water trigger and they transition to Drowner. The terrain clip, then, is actually built into Miner physics. I need to find out what the exact reason is for this 2px adjustment.

This topic should have it own board (seriously). It should ideally be the first thing Forum users see.

A quick suggestion for the OP whilst I'm here:

In the SuperLemmix section:

Change this:

"A fork of NeoLemmix tailored towards those who prefer a more traditional gameplay style"

To this:

"A fork of NeoLemmix featuring a Classic Mode, making it suitable for those who prefer a more traditional gameplay style"

Quote from: weirdzod on August 12, 2026, 09:21:42 PMHi WillLem, first of all, I wanted to thank you for your work in the Lemmings community.

Hi wierdzod, thank you for your kind words. It's my pleasure to contribute to this community and it's always good to hear from new players.

Quote from: weirdzod on August 12, 2026, 09:21:42 PMI realized that SuperLemmix is actually the best way to play these levels ... Perhaps it should be suggested somewhere prominent that SuperLemmix is a better option for playing the DMA levels.

As Proxima mentioned, this topic features SuperLemmix quite near the top. The topic should be way more prominent on the Forums, though. It should arguably have its own board!

Regarding SuperLemmix, I haven't actually done anything with it for quite a while now. I certainly will come back to it at some point though. It's by no means perfect but it's tons of fun. Meanwhile, if you're after a truly OG experience with only a handful of modern features and a polished UI, RetroLemmini is also worth a look. It's the only engine I use to actually play Lemmings (as opposed to create levels or experiment with solutions: NeoLemmix/SuperLemmix is better for both).

Quote from: weirdzod on August 12, 2026, 09:21:42 PMOff-topic: The PS3 Lemmings version has a broken music index file, so the music doesn't play... and in one of the packs I mentioned earlier, the *Shadow of the Beast* Mega Drive level plays random music... at least from what I've seen so far.

Thanks for mentioning this. I've put it on the to-do list to get sorted.

Quote from: Simon on August 10, 2026, 06:50:30 AMIt's normal to not have yet met the save requirement. Keep it green, it shouldn't stand out.

I hadn't thought of it that way, but you're absolutely right. In fact, making it green when the SR is met is a reversion to 'default green', which doesn't seem right. So - agreed, let's make it green for 'not met' and change it (and/or use icons) when it's 'met'.

Quote from: Simon on August 10, 2026, 06:50:30 AMI value non-screaming panel colors more than avoiding such a clash.

As well as improving the colour scheme, we could also add an option ('Use colour scheme for panel text' or something). Unchecking it keeps everything green. We make sure that symbols, icons, and the text itself conveys all the important stuff (which it mostly already does).

Do we think such an option is necessary? Or would improving the colour scheme to be 'quieter' be sufficient?

Quote from: Simon on August 13, 2026, 04:38:41 AMOvertime is one case of having insufficient time to win.

I disagree. Overtime is not so much 'you don't have enough time left to win' as it is 'the game is already over'. It's a subtle but important distinction that I don't think red text would convey as clearly as something a bit more neutral (like purple/blue).

Overtime in NL serves 2 primary purposes:

1) Allow the player to continue exploring the level

2) Allow the player to rewind into 'playable' time

In either case, we need to let the player know that they are in Overtime. Purple/blue does this without conveying urgency (which red arguably does more so) or normality (for which we are using green).

Quote from: Simon on August 10, 2026, 06:50:30 AMFix the design bug where the engine guesses that 15 seconds is somehow an important threshold. Ditch the entire threshold feature. Zero is the important threshold. Either you can win (depending on other things) or you can't win. When you can't win anymore based on the clock alone, you have a reason to recolor from yellow to red.

It's a fairly standard design practice for a descending timer to change to red, or orange, or some other 'urgent' colour, when time is close to running out, but not actually fully run out yet. Another design choice I've seen is to make the timer flash, but - let's not do that!

15 seconds is somewhat arbitrary, agreed, but we do need to provide the player with some visual feedback that the timer is close to running out, especially since time limits only tend to be used in custom levels when they're an actual feature of the level - most levels use infinite time. The player therefore needs to be reminded that the time limit (a) exists - the icons do this, and (b) is critical - if not with colour, and definitely not with flashing, then... what would you suggest?

Quote from: Simon on August 10, 2026, 06:50:30 AM#3 But what is confusing with this?
yellow > 0 seconds
red < 0 seconds

If I see a timer turn red, I'm more likely to think 'time is about to run out' rather than 'I'm out of time'. Indeed, most games just end when time is up (the only other video game (than NeoLemmix) that I can think of that uses Overtime is Tetris!).

Also, the use of red arguably conveys urgency, as previously mentioned. There is nothing necessarily urgent about the 'Overtime' state. Quite the contrary: the timer no longer matters once it's run out. This is why purple/blue is better.

Quote from: Simon on August 10, 2026, 06:50:30 AMPrint a minus sign!

IMHO, this is more visually noisy than colour. I'd honestly rather not do this if we don't absolutely need to.

We need others to chime in.

Thanks to those who attended the meetup. It was great to see everyone again, even if the group was a bit smaller than usual.

Perhaps we could arrange another one for the Autumn, somewhere further south (someone mentioned Bristol which I think would be a great place to meet) so that it's a bit more central for everyone to travel to.

I'll post a topic for it soon (or, anyone else is of course free to create one in the meantime).

This bug has arisen again. The newly-implemented check is in the correct place, but didn't account for 2px vertical movement at frame 0*. This has now been fixed.

Fixed in RLPlayer commit bd398f8.

*Note to self: Why is the Miner moved 2px downwards at frame 0?

Hi all, I'll probably be arriving at around 12:30. No need to wait at the station for me, I'll text Flopsy when I arrive and can go to wherever you are.

See you there!