[?][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.