⚙︎ Combinators shouldn't require current and circuit_wire_max_distance should be 28 for all wireable entities. It's annoying to build extra poles just to connect rather close standing entities and it might cause failures because you don't see always very good if an wired entity is connected with a pole or its neighbour behind the pole. This is simply not a challenge, just harassment.
⚙︎ New condition for Decider Combinator: BETWEEN resp. FROM-TO, setting at least 2 constant values for a signal i.e. e.g. "steam >9000 <11000" resp. "steam ≥9000 ≤11000". A decider combinator with "condition1 AND/OR/XOR condition2" isn't necessary except for this case. It's also not necessary to compare with signals in this case like "steam ≥A ≤B", just constant values.
⚙︎ New combinator: "Repeater" Combinator. It has an input and output like the Decider Combinator. Primarly it's working like a diode, separating its input from the output network. - Like the D.C. with "anything≠0 => output=everything" but with the convenience, that you don't have to edit anything. The "Repeater" Combinator could further start a timer by condition from 100ms up to e.g. 600 seconds. This leads to sending/forwarding a determined signal until the timer runs out (mode "hold") or only sending the signal for a short time (mode "pulse") after the timer ran out. In short: you can send a signal for a distinct time or after a distinct time.
⚙︎ Optional: "big lever" - the Constant Combinator may represent a big lever or at least a switch, that can be operated by the player using his climb-vehicle-hotkey.
⚙︎ [Addendum] Optional: Power Switch: should also be operable like a big lever. Further, the Power Switch would be an ideal entity where you could read the input's power network informations. Like the "Power Meter Combinator" mod, the power values are using the signals "Solar Panel", "Steam Engine" and so on for the respective power source amount and e.g. "D" for demand/drainage, "P" for current production. The values might also only be available internally, although it won't likely cause errors in confusing the power productions values with item counts.
⚙︎ Optional: you may set the colour of lamps directly instead of interpreting incoming signals, therefore the on/off condition only turns it on.
⚙︎ Optional: condition "day/night" for lamps, i.e. true/false, just like ordinary lamps are turning on/off. Maybe default behaviour without (visible) condition.
⚙︎ Signal and light colour orange: it's just inconsistent. A grey or brown signal may not make sense, but orange is used very often, part of "every" rainbow, more important than cyan or pink.
While we are at it, feel free to use these light colours:
Code: Select all
data.raw["lamp"]["small-lamp"].signal_to_color_mapping =
{
{type = "virtual", name = "signal-red", color = {r = 1, g = 0, b = 0}},
{type = "virtual", name = "signal-orange", color = {r = 1, g = 0.75, b = 0}},
{type = "virtual", name = "signal-yellow", color = {r = 1, g = 1, b = 0}},
{type = "virtual", name = "signal-green", color = {r = 0, g = 1, b = 0}},
{type = "virtual", name = "signal-cyan", color = {r = 0, g = 1, b = 1}},
{type = "virtual", name = "signal-blue", color = {r = 0.375, g = 0.375, b = 1}},
{type = "virtual", name = "signal-pink", color = {r = 0.75, g = 0.25, b = 1}},
{type = "virtual", name = "signal-white", color = {r = 1, g = 1, b = 1}},
{type = "virtual", name = "signal-grey", color = {r = 0.5, g = 0.5, b = 0.5}},
{type = "virtual", name = "signal-black", color = {r = 0.375, g = 0, b = 0.3125}}
}
