[0.17.44] Lamp light color does not consider condition signal color

[Bonaducci]

I expected that light color depends on all signals matching condition specified in the lamp settings.

It actually uses probably highest color index of any positive signal if condition is met instead of considering only signals matching condition. In other words, it should behave like that only if signal with asterix (any/all) was used.

It's simple to reproduce. Just send two color signals with positive value to the lamp and light it up if the one with lower index is positive.
Eg. Sending blue 1 and yellow 1. Lamp should light up when yellow is present. Instead blue is visible despite this lamp should not react on blue.

GYRt8tR[1].png (288.56 KiB) Viewed 2339 times

It would be more convenient and also more flexible if in case of condition expecting color lamp would consider only this color.

I know you have covered case in which you provide color and control signals separately via separate networks. In this case it will be expected behavior as you provide color signal explicitly. In this case if you expect control signal to be a color, it would be nice to have exception from this rule.

- If you want the lamp to have different color than signal controlling it, then base condition on anything but color.
- If you want the lamp to have color of control signal, then you don't have to do anything.

Example scenario.
Create control board which sends different signals with colors to run different pumps. Now you place lamp at each factory block with the same condition as pump fueling it. In solution I propose here it would light up factory block with color that is condition to run it. No matter that the same network controls all other pumps with different signals.

In current implementation you'd have to create one network with non color signals for controls and several separated networks with constant combinators to send color signal to each sector. Otherwise they will still light up with higher color index present in common network.

There is no drawback in this solution as using color signal as both control and color is inconsistent. If you want to light the lamp only when yellow signal is positive, then sometimes you will have yellow light (of all other signals have lesser priority) and sometimes you will have different color. In proposed solution you would always have the same color as the one that should trigger this light or current behavior if condition is based only on non color signals.

You are aware of this mechanism so maybe it should become feature request (I found more information after creating this report).
Simply said, if condition contains explicit color signal, use this one. Otherwise use current order of any input signal color.

[Optera]

Lamps behave like filter inserters, taking the first signal they can use, aka that has color information.

I'm not 100% happy with how hidden this mechanic is and the way color signals are sorted.
For example green will override yellow. When building lamps to indicate problems overriding green with yellow and yellow with red is more useful.

[sepharim]

you could use a comparator in front of your lamp to filter out only the yellow color.

I prefer it the way it is now, because it is really helpful in a lot of cases to overwrite the color

[Bonaducci]

After all, there could be simple checkbox under lamp condition "apply to lamp colors" that would show up if "use colors" is checked.

Whole point is that current solution gives more flexibility but also requires using it. You can't just put lamp to see if there is yellow signal in circuit and see it as yellow. Either you will have different color than lamp meaning or you have to use one combinator more and that's the problem.

The other thing I'd like to propose is to display in information window signals received by lamps or pumps if they are in circuit (the same way combinators do) but that would be separate topic.

[Theikkru]

There are cases where overwriting colors is useful, but are there any that also use one of the colors as the condition on the lamp? I can't think of any instances where flexibility would be lost with the proposed implementation, because it would have to be a situation where
① the lamp is exposed to multiple color signals,
② the lamp uses one of those colors for its enable/disable condition,
③ the desired color to be shown is NOT the color the lamp is using for its trigger, and
④ the desired color precedes the trigger color in the current arbitrary color priority order.
I can't think of a good reason all of these would be true in a case where alternate circuitry is not warranted.

[macdjord]

There are cases where overwriting colors is useful, but are there any that also use one of the colors as the condition on the lamp? I can't think of any instances where flexibility would be lost with the proposed implementation, because it would have to be a situation where
① the lamp is exposed to multiple color signals,
② the lamp uses one of those colors for its enable/disable condition,
③ the desired color to be shown is NOT the color the lamp is using for its trigger, and
④ the desired color precedes the trigger color in the current arbitrary color priority order.
I can't think of a good reason all of these would be true in a case where alternate circuitry is not warranted.

I actually had this exact problem with my nuclear reactor system. When I started designing it, I chose [Red] as the signal to indicate 'not ready to load more fuel cells' based on the simple association of 'red = stop'. However, when I later decided to add indicator lights to the control circuitry, I realized that while some of the conditions which would inhibit loading were problems for which a red lamp was suitable (e.g. 'not all reactors have a new fuel unit ready'), there were also some non-error conditions which nonetheless inhibited loading and which I'd prefer to signal with a yellow lamp (e.g. 'steam buffer not empty'), but there was no way to get a yellow lamp from a [Red] signal condition without using an extra combinator as a filter.

I ended up having to redesign my reactor circuitry to use [X] as the 'not ready' indicator, but it would have been nice if I could have just set the lamp colour independently.

[ssilk]

So you had fun in redesigning? I also tapped into this one, but you make those errors only once.

All I would add here is a specific explanation of the color-switch.