[?][SUG][PL/ED] Change Color/Transparency of trigger area

[GigaLem]

Gonna be real here, the pink color for the trigger area is starting to get a bit too bright. It's my least favorite to keep turned on while making levels simply for its intensity. Its the most apt issue in editor. and I did notice it on Icho's videos for the contest (the one contest level with the new objects)

I get the color needs to contrast from the level, but it might be prone to eye strain.

[Simon]

Do you put large water areas?

Another solution, then, is to draw only the outline of the trigger rectangle in the contrastful color. The inner area can be fully/mostly transparent.

-- Simon

[GigaLem]

Do you put large water areas?

Another solution, then, is to draw only the outline of the trigger rectangle in the contrastful color. The inner area can be fully/mostly transparent.

-- Simon

Well, there is the problem of one way arrows, and when used one way fields. im sure your solution could be applied the same way.

[Simon]

I still think that this is important. I don't build NL levels; if others see potential problems with these ideas (outline instead of filled pink rectangle), please bring up those problems.

It's conceivable to draw the areas of only some gadgets as outline. When a gadget affects terrain (e.g., one-way arrows), you can, e.g., fully fill the matching terrain, and not paint the air. The important fix will be that huge water areas don't generate huge pink blobs that are hard on the eyes.

I'd like to prod WillLem to consider this. People activate these helper tools when they need to know the details, therefore you want maximally clear helpers.

-- Simon

[WillLem]

Outline wouldn't be the best idea for water and/or OWWs because in both cases the trigger area affects whatever it overlaps, including any added terrain:


Left: The water continues behind the terrain pipe / Right: The OWW is still active in the area of the block that has been removed. The builder's bridge enters that area, and so is affected by the OWW.

The idea of CPM is to make it clear where the triggers are, pixel by pixel. Outlining is at best asking the player to work it out instead of just showing it, and at worst could even render some trigger areas invisible (if the outline is outside the terrain piece, for example):



As for the colour, I see no reason not to allow users to specify whatever colour they like. I'll look into whether this is feasible.

[WillLem]

I've now added some examples to the previous post to show why outline-only trigger areas could be problematic. Let's agree to continue to show trigger areas on a pixel-by-pixel basis and address the OP's concern regarding the colour of the trigger areas as they are currently shown.

I'm happy to look into allowing the user to enter a hex code (or perhaps add a simple colour-picker if it's possible in Delphi) to specify the colour of trigger areas. For simplicity, let's have them continue to all be the same colour (in CPM, hovering over the trigger area already shows which gadget is which; this feature provides sufficient clarify without the need to allow different colours for different gadgets, which could get messy. I realise that isn't what's being suggested, but I'm pre-empting it just in case!).

@namida - Is there a reason why the trigger areas are all that very specific shade of pink (#F000F0)? I've noticed that Lemmini uses a very similar shade (#FF00FF), and that DOS variants of Amiga colours follow the pattern indicated by these colours (so, for instance, #4422FF in Amiga would become #4020F0 in DOS, and vice versa). I wonder, then, if the choice of shade for trigger areas is simply what was used in the base game that each clone was based on (so, #F000F0 for Lemmix's DOS base and #FF00FF for Lemmini's WinLemm/Amiga base).

If that's indeed the case, then the trigger area colour could potentially be anything we wish.

[Simon]

User-configurable color for the filled fectangle, okay.

1. This is both for game and for editor, right? Giga says "least favorite to keep turned on while making levels" and "most apt issue in editor". But WillLem is talking about builders that build into the trigger area.

2. You'll push a design task to the user that we should instead solve for the user. At least reconsider the default then, too. Is the pink default still good for 95 % of the levels?

3. You'll inflict Schopenhauer's porcupines:

• If user picks too bright a color, he runs into eye strain (OP's problem).
  
• If he picks too dim or too transparent, edges will be harder to see (where exactly does the water start behind multicolored terrain). Giga said: "needs to contrast from the level".
  

The first hunch is to combine both ideas: Fill the rectangle at 10 % or 20 % opacity, and draw an 80-%-opaque 1-pixel-thick rectangular outline.

-- Simon

[WillLem]

1. This is both for game and for editor, right?

Yes, I'll aim to implement the same option in both.

2. You'll push a design task to the user that we should instead solve for the user. At least reconsider the default then, too. Is the pink default still good for 95 % of the levels?

3. You'll inflict Schopenhauer's porcupines:

...

The first hunch is to combine both ideas: Fill the rectangle at 10 % or 20 % opacity, and draw an 80-%-opaque 1-pixel-thick rectangular outline.

OK. Perhaps we keep the rectangle pink and allow the opacity to be adustable instead of the colour? Keep the default as it is now, and allow 5% increments in both directions to make it more (or less) opaque depending on preference. Less opacity makes it darker, then.

I'm not in favour of the outline idea. Messy, more code, more maintenance.

[GigaLem]

my suggestion would be the freedom of changing the RGB value at will with the default being the fuchsia it is.
The other part of the suggest would be Trigger area opacity or brightness, choosing how much of it to be opaque

[WillLem]

my suggestion would be the freedom of changing the RGB value at will with the default being the fuchsia it is.
The other part of the suggest would be Trigger area opacity or brightness, choosing how much of it to be opaque

Right, but let's not lose sight of what the program is: it's a lemmings engine, not an image editor. We'd be better off keeping the options as simple as possible rather than making the user spend too much time in menus.

[namida]

Outline wouldn't be the best idea for water and/or OWWs because in both cases the trigger area affects whatever it overlaps, including any added terrain:

This is true for almost all trigger areas - and ironically, at least on the player side of things, OWWs are actually one of the few exceptions. In DOS/Lemmix it's indeed the case that they affect anything they overlap, but in NL (and presumably SLX by extension), when the physics map is generated at the start of gameplay, OWW data is baked into it at that point. If a pixel is erased (by an eraser piece, or during gameplay, by a destructive skill), the OWW flag is erased with it; if a new solid pixel is later placed in that same location, it's just a normal pixel with no OWW flag. If the pixel wasn't solid at the time of generating the physics map, it didn't get the OWW flag in the first place.

(And by extension, yes, this does mean that SLX could theoretically add a constructive skill that creates one-way walls, with no changes to any wider object / terrain physics. Whether it's a good idea is a very different question, but it's very possible on a technical level.)

@namida - Is there a reason why the trigger areas are all that very specific shade of pink (#F000F0)? I've noticed that Lemmini uses a very similar shade (#FF00FF), and that DOS variants of Amiga colours follow the pattern indicated by these colours (so, for instance, #4422FF in Amiga would become #4020F0 in DOS, and vice versa). I wonder, then, if the choice of shade for trigger areas is simply what was used in the base game that each clone was based on (so, #F000F0 for Lemmix's DOS base and #FF00FF for Lemmini's WinLemm/Amiga base).

It's very likely I chose to intentionally go with a color that's within DOS's color depth, hence #F000F0 instead of #FF00FF. The choice of using "death magenta" in the first place is simply because it tends to contrast well with a lot of other colors, and in particular, it itself tends to be a less-frequently-used color in actual graphics (as opposed to UI). It's a pretty common choice in general for this sort of purpose, not just Lemmings-specific.

[WillLem]

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.

[GigaLem]

I've said my input that the magenta is a bit eye searing at point were I have to turn it off when im making the levels. I'm standing on these choices for what i'd suggest.

Basic RGB value - default it to the original color, change it by sliding the values to something more easy on the eyes, include presets via a dropdown menu if you're worried about those spending time in the options

A softer contrasting color - While colors like magenta and yellow are contrasting, finding a contrasting color that's visible enough without it being blindingly bright would be a better solution, colors like Purple or Light Teal (think the color of baja blast) may be more easy on the eyes