Added text, button and popup in commit c69a09c.

Quote from: Simon on November 04, 2025, 05:09:24 AMHow urgent are different trigger area color in the game anyway? All the time, I thought Giga's bug report here was about the editor only

Good point, the topic is indeed marked for the Editor. That would be an easy change. Maybe we simply leave the Player as it is?

Quote from: Simon on November 04, 2025, 05:45:30 AMThe ideal UI widget for the single list will then be a table, not merely spaces/tab characters

Not a bad idea. I'll look into this.

At the very least, we'll have a label explaining what the blue text is, and a "?" button with a dialog explaining Replay Insert mode for sure.

Quote from: Simon on October 27, 2025, 09:13:01 PMIIRC we have refactored that into its own side-effect-free question. All the hard work is already done, and it's clear what happens if you ask twice.

Yes, this is the stuff we worked on together It's nice and clean, and could be used for this purpose if necessary, but I'd rather find a better way tbh.

Quote from: Simon on October 27, 2025, 09:13:01 PMIt can also be natural to move the decision later.

This feels like the best thing to do. It could even be the very last check before moving on to the next frame; we will already have determined whether or not time has run out, so can call the sound once all other processing is complete.

Quote from: Simon on October 27, 2025, 09:13:01 PMI wouldn't cue the effect one physics frame later, unless that's what you always want; i.e., even if we continued play, you'd want the effect exactly one frame later.

There may actually be good reasons to have the sound cue on the "-1" frame as opposed to the "0" frame. At frame 0, we're technically still in "lemmings can be saved, all actions count" territory. Why does the sound need to be cued on this frame, then?

Does L2 provide any further context than just their names? I imagine they're both in the Highland tribe...?

Quote from: Simon on November 02, 2025, 01:46:54 PMSpeculation: It means that the assignment entered the replay during insert mode.

This is correct. I agree, we could do more to make this clearer.

Quote from: Simon on November 02, 2025, 01:46:54 PMWrite static explanatory text in the tweaker.

This is my preferred solution of the ones you've suggested. A separate column negates the benefit of seeing all replay actions in frame order, which is the most useful way to present them. Ditching the blue isn't completely out of the question, but then we'd need some other way of denoting these actions (prepend "[R]" to the action? Hm, we'd still need explanation, and there's no reason we couldn't keep the blue text as well).

So, we can simply add some text at the top which says "Actions in blue added during Replay Insert mode" or something similar. We could even add a "?" button next to this text which would open a dialog explaining Replay Insert mode in more detail.

Thoughts?

Quote from: Simon on November 02, 2025, 02:59:32 PMArmani and I have already argued for this in Improve same-frame assignment behaviour in Replay Insert mode, which is now closed.

Not sure why the topic was closed as it hasn't yet been resolved and is still in the Bugs & Sugs board. Anyways, I've re-opened it.

Quote from: Simon on November 02, 2025, 02:59:32 PMFirst erase the future of A in the replay (erase all assignments to A at N+1, N+2, N+3, ...), then assign to A.

...

CE 1.0.1 blocks same-frame-same-lemming, which is the most annoying type of failed assignment because the intention is clear.

My instinct with this is (and always has been) that we shouldn't erase replay actions invisibly; if the player wishes to erase all future actions for this lemming, it should ideally be done via the replay editor where the player can see exactly what's happening.

Regarding the second point, IMO the benefit of {not accidentally overwriting a previous action unintentionally} outweighs the annoyance of having to either (a) move to another frame to make the desired assignment, or (b) manually delete the existing action (and future, if desired) via the replay editor.

The whole point of Replay Insert mode is that it preserves all existing actions. The OP is suggesting a third mode, which preserves all existing actions {except these}. Further complication of the replay system, more for new players to learn, potential for mess/bugs in the code.

Bottom line is that the engine is ultimately meant to be a game. The replay editing features are a nice bonus, and should of course be as sophisticated as we can possibly make them. But in-game actions such as skill assignments should have completely visible (or audible) results; nothing should be happening that the player doesn't know about (i.e. deleting future assignments).

Possible solution:

A hold-during-assignment hotkey which means "I want to delete" might be the best compromise here? We'd also change the cursor whilst it's held.

Had a look at this one today. The problem is that the behaviour is technically not a bug. The lemming is saved and time runs out on the same frame, so the lemming counts as saved (thus completing the level) and/but the "time up" sound is also cued (correctly).

It's possible to ask the game to wait another frame before cueing the sound, which seems to "fix" the reported bug, but is essentially cueing the sound 1 frame too late, which itself is a bug.

Not entirely sure what to do about this one.

---

EDIT:

It may be possible to ask at the current frame "do we need to play the sound?" and check for certain conditions, but I'm not entirely sure what those conditions should be. Ideally, they'd be anything that would cause the game to exit to postview. However, we're then making a check for "exit to postview" twice per frame purely for the purposes of cueing the "time up" sound: this is clunky.

Another idea might be to move the "time up" sound cue to later in the same frame. The hope, then, is that the game will have finished and exited before the cue is reached. I'll check for this later.

OK, finally got around to having a look at the code for this today.

Editor:

This is very easy. The Editor simply draws a semitransparent magenta pink rectangle. By swapping which of the ARGB channels are drawn at 255, we can have semitransparent cyan, yellow or mint green.

I'm sure that by messing about with this value, other colours could possibly be achieved. We choose one that works, implement the option. Not a problem.

Game:

This is much more convoluted. The trigger area is drawn pixel-by-pixel in a chequered grid pattern, and so is actually composed of at least 2 colours. The first colour is the #FF00FF pink, and the second is dynamically calculated from this (but is hue-dependent). Then, triggers can overlap terrain, steel, and other triggers. In each of these cases, the colour is either re-blended or simply drawn as a new colour.

So, it wouldn't be a simple case of just changing the #FF00FF value as I'd hoped, and would in fact require a more detailed recalibration of all the various overlapping and intersecting pixel colours. Granted, there are only a few to consider, but it would have to be done for each individual base colour.

For that reason, I'd be happy to consider implementing a single alternative colour option (as opposed to several alternatives) for the game engine, but I'd ideally want that colour to be chosen and specified by the OP (GigaLem) so that I can simply go about working it into the various required sub-colours to make sure it works as a viable option.

Multiple colours are unfortunately out of the question. Even if I could find some way to automate every possible configuration from a single base colour, that goes way beyond the desired scope of this feature, which is (as I understand it) simply to provide a less harsh-looking alternative to the pink. This can simply be agreed upon beforehand, worked in to the existing code, and presented to the end user as an A/B option.

Meanwhile, drawing unfilled rectangles would require significant re-writing of the code that draws the trigger areas, which is not something I'd be happy to take on at this point. I'd prefer to rule that out altogether and go ahead with a comparatively simpler trigger recolouring.

So, Giga, we need to know what would work for you as an alternative colour. Ideally, please present it either as a .png image or a hex code (e.g. FF00FF) and I can take it from there.

---

(Note to self: Editor - BmpModify.cs line 188)
(Note to self: Game - LemRendering.pas line 2834)

Only the original Amiga/DOS tunes will be bundled with NeoLemmix / NeoLemmix CE. I'd be happy to include better versions of those tunes (i.e. "better" in terms of audio quality and/or file size), but any other music will always be an optional extra.

For that reason, I've moved this topic to the NeoLemmix Main board (from Bugs & Suggestions). The OP is welcome to upload the listed files for anyone to use in NeoLemmix / NeoLemmix CE, but they will not be bundled along with the program itself. Again, this goes for all music files other than the original Amiga/DOS tunes; the simple reason being that music files tend to bloat the size of the download.

EDIT: The second post is merged from another similar topic.

Quote from: GigaLem on August 26, 2025, 02:42:56 AMinclude presets via a dropdown menu if you're worried about those spending time in the options

This is probably the way to go with this. I'm thinking 3 colours:


Original Pink


Baja Blast Teal (good suggestion, GigaLem)


Banana Yellow

And, another possible alternative for a slightly darker colour that should still contrast well:


GameCube Purple

Another option would be to simply have a toggle that switches between two shades of pink:


Original (left) and Dark (right)

This could keep things simple whilst providing a solution.

Quote from: Simon on September 28, 2025, 08:47:13 PMLook at who's using the editor the most: That's Giga, and the other pack authors, and the other authors in the level design contests. The bug priority opinions of serious long-term users carry weight.

It's always a possibility to bluntly implement whatever roughly fits the requirement, ship it, and then reinvestigate

Agreed. Let's decide on which option to go with (3 colours, or a Light/Dark toggle), and then implement it for the next RC.

---

Hm. Something to keep in mind is that trigger areas are already darker where they overlap with terrain or other trigger areas. I'm hoping that this is dealt with in code by auto-adjusting the original FF00FF shade by some value. It probably is, but just making a note of this concern here in case it becomes relevant.

Just giving this a bump. Could be worth trying it for a few months over the Autumn period, see what we think?

Hi all, apologies I've been a bit quiet over the summer. Been spending time doing IRL stuff and haven't been at my laptop so much. I'm hoping I'll be able to get back into NLCE and SLX over the next couple of months and get caught up with everything.

Thanks to everyone who's been supportive of the projects so far, it means a lot.

Looking forward to getting back into my Lemmingology studies!

WL

It seems that the easiest and best solution to this is simply to add the erasers to the styles collection as "erasers". Then, like "default", they can be a standard set that is supplied along with NLCE.

The benefit of this is that anyone can add pieces to it as they wish, so it can be collaborative and as-needed.

Pieces would of course need to be agreed upon before they are added to the set. If existing erasers can reasonably be used to create the desired shape, there shouldn't be any need to add more and more pieces exponentially.

Thoughts?

Currently unsure what to do about this. This one feels like it might get into "too many options" territory; I agree with Simon that this is a design choice that should be solved program-side. We don't want users spending too much time in the options menu.

Then again, it would be easy enough to add the option, and I imagine that for most people it would be a set-and-forget kind of thing. Maybe a choice of 3 options, whether it be different colours or different brightness/opacity, would suffice for this one?

Input needed. As it stands, nothing will change.