It would almost be better to incorporate the splat ruler into the cursor somehow, in the same way that arrows can be displayed for direction select. The only issue there is that the cursor is resizable.

Sure, we can look at the source together. If we can find anything obvious, let's fix it. I'll add the suggested meet up time to my calendar, see you then

Let's keep the default as simple as possible; a simple stick with triangles at each end is the best design IMO. Anything more complex than that is likely to cause similar problems to the current Status Quo that we're aiming to replace.

Besides, rulers can be custom-created and used in place of the default anyway. People are always welcome to create their own rulers and share them on the Forums in the graphics sharing topic, which I'm happy to sticky to bring more attention to it.

The next update will feature Simon's ruler as the default, and the old ruler as an option.

Finally got around to testing this on Windows. I can't get CE to outright freeze, but on larger levels (such as Turrican's, which are massive) there is noticeable lag when using the splat ruler, especially in hi-res. In my personal opinion, it's not that much of an issue; it's comparable to the lag experienced when running enormous levels on NL/CE in general. It may be much worse on Wine, but I have no way to test this and I'm unsure as to why it would be significantly different in that setup.

My instinct here is to simply display a warning to users when a level is above a certain size or uses more than a certain amount of animated resources. It doesn't fix the behaviour, but would likely discourage level designers from making levels that are big enough (or busy enough) to end up triggering the warning.

Ultimately, NL/CE is limited by its 32 bit graphics engine. It's not something I'd be interested in updating without signifcant help from another developer, as I imagine it would involve extensive re-writes to a lot of the rendering code. We'd almost be better off creating a new engine that can handle higher resolution sprites and levels if that's what people want. Something like a PS2 Lemmings clone with an emphasis on graphical fidelity from the getgo would be better for supporting larger and more graphics-intensive levels. As it is, NL/CE just simply isn't set up for that sort of thing.

I realise that might not be the answer people were hoping for, but it's something I too have had to accept about the engine during my own adventures with it. SuperLemmix pushes the graphical capabilities to the absolute limit, and I've had to reign in a lot of my own ideas to keep them workable.

So... go low res & low quality minimap when running larger levels, and perhaps avoid them altogether on Wine if they're causing the program to freeze. I'm happy to put in a warning so that players know that the level they're about to play is above and beyond the recommended graphical limits; that's really the best I can do without rewriting the entire engine (which isn't going to happen!).

Same here, I'd be happy to check out this game. Thanks!

It seems worth including your ruler in the next update at least for trial purposes, pending further tweaks you may wish to make in the meantime.

The old ruler will remain available as a toggleable alternative. The colour cycling will also be available as an optional extra.

By all means test your new ruler and see if it could be improved. I trust your judgement, and I find it unlikely that anybody would have any objections to at least giving your ruler a try.

Let us know what (if any) issues you find with the new design during playtesting and we'll see if we can brainstorm some solutions.

Quote from: Simon on May 27, 2025, 07:30:52 PMThe color cycling is fundamentally problematic ... there will be clashing colors in the cycle, i.e., stuff looks temporarily the same. Exactly what his design should have avoided.

Whatever colour we make the ruler, it will always clash with any tilesets in that colour.

If we make it blue (for example), any blue tileset will clash 100% of the time. The colour cycle means that tilesets of any colour will not clash 90% of the time.

So, do we want one colour to clash 100% of the time and all other colours to clash 0% of the time, or all colours to clash 10% of the time?

Anyways, it's something of a moot point tbh. It can be turned off in settings for those that don't like it (N.B. The colour-cycling ruler is only in SuperLemmix, it's not yet been implemented in NeoLemmix CE). Besides, your striped (or dotted) ruler solves the above problem, so perhaps should be the default. The colour cycling is (and always will be) an optional extra.

The default ruler probably does need to be updated.

We can provide a new default ruler alongside the old one and either ask the user to rename the images according to preference (the old one would have "_alt" appended to it in the file system) or, at a push, have a toggle for it in the F2 menu.

Simon's triangle-ended ruler is best. I'm personally not too keen on the stripe, but if others like it then sure, we can go ahead with that design. I wonder: would black & white (as opposed to rainbow) colour cycling suffice here instead?

Colour cycling would always be optional either way:

Version 2.3 update:

Several updates this time around, including updates to the OG styles, Physics and UI.

Styles

• Added additional pieces to Crystal, Dirt and Rock styles - it's now no longer necessary to use the modded versions which include these pieces

Physics

• Climbers now bypass the "oh no" phase when assigned a Bomber (so, they explode immediately)

UI Features

• Updated Debriefing (Postview) screen:
  • Moved "needed" and "rescued" onto one line
  • Added lines to show "time taken" and "skills used"
  • Changed score color to green
  • Centered all lines that can & should be centered

• Bugfix - When all levels in a group are completed, the "Congratulations" message is now shown on the last level of the group (after the previous fix, it was being shown on any level except the last)

• Skill Panel status - The 'total lems from start' count is now appended to the hatch number

• Skill Panel status - The lemming head icon now shows 'total active in level' / 'maximum possible that can still be saved'

• The current commit ID is now automatically shown on the "About" window (this may come in useful in the future for debugging purposes)

A reminder of what's new as of 2.0.

---

Get the latest version here.

Since more than 2 months have passed since the release of 1.0 and there hasn't been much in the way of feedback (and all feedback so far is either in active discussion or has been addressed/resolved), it seems appropriate to start thinking about the next version.

The main thing I'd like to focus on this time around is the replay system, beginning with the following proposed features/updates:

Animate Replay "R" icon and make it clickable to cancel the replay (including during Replay Insert mode)

Add Playback Mode - this can auto-play an entire folder of replays for a selected levelpack, with various playback options

Update Replay Renamer (now known as Replay Manager in SLX) to include additional replay renaming options (including the ability to append the pass/fail result of each replay) when performing a Mass Replay Check

Add .nxrp Windows-File-Association; when associated, clicking a replay file will open NeoLemmix and load the level & replay, ready to be played back immediately!

I'd also like to propose the following skill panel updates for 1.1:

Make negative save count optional; the alternative would be to count upwards from 0 with the number in yellow until it reaches the save requirement, at which point it would become green

Add (optional) mouseover hints to all skill panel buttons

Cap Lemming counts at '999' ('-99' for negative numbers) across the panel to avoid visual bugs when the lem count exceeds this number

That should be enough to be going on with. Please post a reply with any suggestions/questions/comments you may have. Work on this will likely be very slow compared to my usual rate, but sooner replies are always better than later ones.

Quote from: CrazyAfroAli on May 20, 2025, 08:54:06 PM(with classic mode enabled, of course).

Glad to hear it!

Playing without Classic Mode is the norm on the Forums and you'll likely switch to that eventually (as we all do!), but it's great that you're choosing to experience the game as originally intended for your first playthrough

Quote from: Simon on May 18, 2025, 11:20:32 PMBetter in what way? The click succeeds; it queues, which is what I want. Before, successful queuing played no sound, which was odd indeed. But now, the success sounds like failing, and it feels buggier than before, not better.

It's probably a matter of opinion to be honest. I think it's good that we hear the assignment audibly fail, even if it gets queued. If we have a choice between nothing and an audible fail, the latter is preferable. It's difficult to say exactly what's better about it, I suppose it just makes the game more tactile.

There may be a way to see whether the queue frame is >= 1, and if so then play a different sound as opposed to the regular fail sound (assuming we figure out a way to "know" the reason for the failed assignment).

Quote from: Simon on May 18, 2025, 11:20:32 PMIf the queue fizzles due to time-out ... well, should it ever time-out in the first place? The queued shimmer should stay in the queue until the climber is at a ceiling. If he falls/hoists, then we can clear the queue.

At present, the queue length can be customised up to a maximum of 20 frames. I guess we could make it a maximum of 100 frames if you'd prefer a longer queue time?

Quote from: Simon on May 18, 2025, 11:20:32 PMIt's conceivable to lie in the skill panel, and show fewer skills on the skill button even though they're unspent in the physics. Can't tell from the outside how elegant that would be. Can be fertile ground for bugs.

I'm 50/50 on this. On the one hand, if the game is paused at the point of assignment and we assume that the queued skill will be successfully assigned, the pre-deducted skill is more useful UI to the player. On the other, yeah this sounds like bug city. I suppose we could show the number in a different colour for the duration of the queue; if the skill doesn't get assigned, revert colour and skill count. If it does, simply update the colour to default (the skill count having already been deducted as per your suggestion). This way, there's more state tracking going on and debugging becomes easier.

Some interesting ideas here, but I still think that this particular part of the UI (i.e. skill assignment feedback) is good enough as it is. Perhaps this is one to sit with for a while and see if it comes up regularly enough to be a problem worth solving. Better and more specific ideas may come up later.

Hi CrazyAfroAli, welcome to the forums!

Which version of Lemmings 1 are you playing (Amiga, DOS, Genesis, etc)?

Keep up the good work! The levels only get better from the start of Taxing onwards

There are 5 main reasons an assignment fails:

1) Same-frame assignment whilst in Replay Insert mode
2) Lemming already has the skill, or is already performing the skill
3) New skill is incompatible with current skill action
4) Lemming is adjacent to steel
5) Lemming is adjacent to incompatible OWW

For the purposes of audio feedback, I'd suggest that 2 and 3 could keep the same, current assign fail sound. 4 should be a steel "dink", 1 and 5 could each be something else entirely.

That's 4 sounds. Let's say steel and OWW could have the same sound to get it down to 3 (I can't remember the reason people didn't want the steel sound, but we could just give it the same sound as OWWs, whatever that ends up being).

This should add further clarification to what's going on when an assignment fails. The "incompatible with current action" sound would, to some extent, become a "this skill assignment has entered the queue" sound by proxy (and, in fact, that's exactly what's happened). As long as it's different from "same frame" and "steel/OWW", this provides enough user feedback and addresses the original bug, albeit not exactly as suggested.

Conversely, if we remove the sound altogether for successfully queued assignments, we're back to the problem that the assign fail sound is there to fix in the first place, i.e. no feedback at all, no successfully assigned skill, click seems to have done nothing. The dual effect of "fails here" and "is eventually assigned here" each providing audio feedback works much better, and that's what we already have anyway.

Quote from: namida on May 17, 2025, 07:17:50 AMFor SLX, I would even go as far as suggesting changing this behavior - allow Climber->Shimmier whenever the climber is less than one animation cycle away from hitting his head
...
Slider->Shimmier is trickier, but perhaps ... introduce a "dangler" state which it can be assigned during.

Both of these ideas are already implemented in SLX. Shimmiers can now be assigned to Climbers at any time (even if the shimmy action itself would fail, it remains useful as a cancelling/turning action), and the Dangler state was one of the earliest additions to SLX (implemented primarily to aid Shimmier assignability to Sliders in Classic Mode). Interesting that you'd come up with the exact same idea, up to the point of giving the state the same name; it certainly seems the most natural thing for the Slider to do.

Quote from: namida on May 17, 2025, 07:17:50 AMIt's not trivial, but I don't think it's quite as hard as you're thinking ... the way I'd approach this is - instead of returning a Boolean, make these functions return an enum, with values for the various failure types (and one for success, of course).

Yes, an enum or record is probably the best way go with this for sure, but I'd still want to see significant support for the idea before starting with it. Having many new sounds can be off-putting for some users, even if those sounds provide necessary clarification and feedback.

I suppose for future-proofing and code-streamlining purposes, the enum could be implemented anyway (even without the additional sounds). If doing this, I'd probably want to completely refactor the assigning of skills in general. Currently, there are 3 (or 4?) separate methods/functions that determine the assigning of a skill. I'm sure these have become necessary as skill assignment has become more complex (due to the replay system, highlit lems, etc), but the code has become more cumbersome to work with as a result. The assign fail sound, in particular, has had to go through several revisions and re-writes to get it to play nicely with the existing skill assignment system.

Ideally, a single method would take care of the whole thing, perhaps with functions to determine things like lemming state, priority, etc. But the result of any enum related to skill assignment should be easily accessible from a single place. So, there would be a lot of work to do. It's one for the long-term to-do list.

IMHO, the bug here is not the assign fail sound (which correctly plays because the skill cannot be assigned on this frame), but the queued assignment itself. It's always felt like buggy behaviour to me (although I do generally choose to play with it toggled on for the few times it's useful vs. the times I have to rewind and clear the queue).

To be clear, I'm not suggesting that we get rid of queued assignments (just in case anyone is thinking that's what I'm getting at), but rather that we don't necessarily need to do anything here.

Reasoning:

1) The assign fail sound is not a bug; the assignment cannot happen on this frame, so feedback is correct. I see no reason to mess with that tbh.

2) When the assignment happens, the assignment sound plays. The user is provided with feedback correctly in both the attempted assignment (where it fails) and its eventual happening (where it happens only because queued assignments are a thing); all good. If anything, the fact that both sounds are played adds further clarification to exactly what's happened; the queued assignment is a courtesy to prevent the player having to click again at the point that the assignment becomes possible. In that light, the previous click (that created the queued assignment) is arguably irrelevant, at least for the purposes of providing immediate feedback.

Perhaps for shimmiers specifically, we could simply treat the assignment as not failed if it's made within the allowed climber>shimmier range, and play the assignment sound at the point of attempt. The only issue with this is that ideally the skill would also be deducted at the point of assignment, and since that messes with physics & replay timing, it would render CE incompatible with NL 12.14 content. So, we probably shouldn't mess with that either.

If anything, the only thing that may need to be addressed is your point here:

Quote from: SimonFor the same-frame problem, I'd like explicit feedback that the new assignment fails because of the existing same-frame assignment. The CE 1.0.1 fail sound doesn't tell me that; it merely tells me that there was some whatever reason to fail.

Perhaps, along with making the assign fail sound optional, we could also allow the user to specify different sounds for different assignment fail types. It's one of the reasons I want to play the steel sound when the assignment fails because steel, but this was ruled out as undesirable. If we allow a fully customisable sound set, we can potentially allow different sounds for different fail types.

The problem would then be determining why the assignment has failed code-side: this is not trivial. I'd probably need to see significant community support for the idea before embarking on it. There's already plenty to be getting on with CE-wise so it'd be a fairly low priority at present.