"Perfect" solution for circuit network system

[Factoruser]

Although Factorio is outstanding good in all aspects of a game, there's still a flaw till these days: the circuit network system. It's not matching the practical needs resp. to achieve some goals you've got to create very awkward constructions that go worse because it's hard to comprehend the wiring. I've contemplated a lot and came to the following conclusions, what has to be changed in the vanilla game.

⚙︎ 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}}
    }

[Tertius]

My circuit network wishlist doesn't contain any of your wishes, they are too high level or too specialized. Not generic and not universal enough. My wishlist has only one item:
- the feature of optionally negating any input or output, i. e. multiply input with -1 before processing or output after processing, for red and green wires separately. This saves not only 1 combinator but, more important, 1 tick latency - the one tick that really drives me crazy sometimes.

Ok, I have a second item.
- the feature to declare any signal as "existing", even if it has value 0. For example, if I output signal A with value 0, it should be different to the EACH/ANY/ALL operators than no signal A. This can be set with a constant combinator. If a constant combinator is set to output A with value 0, A is existing. (However, I have no hope for an implementation, since !=0 is already the information "is existing", and there is no additional information channel to transfer an additional bit beyond the current 32 bit)

[DaleStan]

⚙︎ Combinators shouldn't require current and circuit_wire_max_distance should be 28 for all wireable entities.

It should be easy to create a mod that does this, though I'm not aware of any.

⚙︎ 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.

The constant combinator can already be turned on and off from its UI. There's also https://mods.factorio.com/mod/Switch_Button-1_0 and https://mods.factorio.com/mod/pushbutton

[robot256]

Nice list!

⚙︎ 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.

Understandable.

⚙︎ 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.

This would be convenient for some things, but breaks the convention of one atomic operation per combinator. Normally I want to know whether the value is too high or too low and react differently based on which. If you want a lamp to show when it's in the "green zone", right now you only need two decider combinators outputting A=1 and a lamp that turns on when A==2.

⚙︎ 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.

If this is something you need frequently, why not blueprint an arithmetic combinator set to "Each + 0 -> Each" and keep the blueprint in your quickbar? Same convenience to use, but no extra entities to assemble and store.

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.

This seems like a complicated behavior for a single combinator. A new combinator with a programmable delay line would be enough to simplify those types of operations, and it would be easier to control what the gating conditions are.

⚙︎ 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.

Agreed that the constant combinator on/off functionality could be made more obvious. For controlling, some mods give an example of what is possible: Remote Constant Combinator and Combinator Toggle.

⚙︎ Optional: you may set the colour of lamps directly instead of interpreting incoming signals, therefore the on/off condition only turns it on.

This is a really nice idea!

⚙︎ Optional: condition "day/night" for lamps, i.e. true/false, just like ordinary lamps are turning on/off. Maybe default behaviour without (visible) condition.

Do you mean a daylight sensor that outputs a signal? Or do you mean a lamp that can respond to both signal on/off and daylight?

⚙︎ 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.

Agreed. Dectorio adds a proper rainbow of signals, and I can't play without it anymore!

[Nidan]

⚙︎ 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.

You could use constant combinators instead of power poles to avoid the hiding problem.

[Factoruser]

⚙︎ Combinators shouldn't require current and circuit_wire_max_distance should be 28 for all wireable entities.

It should be easy to create a mod that does this, though I'm not aware of any.

Changing everywhere circuit_wire_max_distance is easy and I put it in my mod. But it should be vanilla behaviour. Changing whether an entity is power-requiring or not is much more complicated...

⚙︎ 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.

The constant combinator can already be turned on and off from its UI.

But this would be better done "from the enviroment". Also a possible benefit for the vanilla game.

[Factoruser]

⚙︎ 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.

This would be convenient for some things, but breaks the convention of one atomic operation per combinator. Normally I want to know whether the value is too high or too low and react differently based on which. If you want a lamp to show when it's in the "green zone", right now you only need two decider combinators outputting A=1 and a lamp that turns on when A==2.

It's pseudo-atomic of course, but with one signal and 2 constant values it fits logically in the scheme. It's even a kind of comparsion that would make sense for a machine code.

If you want some coloured level indicator, the best would be, each colour is only activated in a distinct range, maybe fluid <5000, 5000-8000, 8000-16000, 16000-22000, >22000. - Of course you'll get an intersection with ≥8000 ≤16000 and ≥16000 ... - but only for one value.

Sometimes the colour's priorities are superimposing the wrong colour, and then you need at least a second combinator, red and green wire... - circuitous...

⚙︎ 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.

If this is something you need frequently, why not blueprint an arithmetic combinator set to "Each + 0 -> Each"

I already have, but need the timer function. Currently you'd have to build some ugly stuff like inserters and chests to get a timer circuit, that would become even more tricky if the delay should increase with a new start signal.

⚙︎ Optional: condition "day/night" for lamps, i.e. true/false, just like ordinary lamps are turning on/off. Maybe default behaviour without (visible) condition.

Do you mean a daylight sensor that outputs a signal? Or do you mean a lamp that can respond to both signal on/off and daylight?

No, just the "signal" daylight, resp.: a coloured lamp should simply turn on/off like an ordinary lamp with no wires.

[robot256]

I already have, but need the timer function. Currently you'd have to build some ugly stuff like inserters and chests to get a timer circuit, that would become even more tricky if the delay should increase with a new start signal.

I'm curious what kind of applications for timers you have? I have never needed to use items in circuits before. It's definitely possible to make a combinator-based counter that starts, stops and resets based on particular signals. Or one that waits for an input pulse of sufficient length before providing an output, or one that produces a certain length pulse output in response to a trigger. Only more complicated things, like delaying a whole group of signals by 10+ ticks, really become impractical with the current system.

[Tertius]

Application for timers? I use a timer of 12000 ticks (200s) for inserting fuel into a nuclear reactor. Together with a steam buffer check, it's an extremely simple circuit with 1 decider and 2 constant combinators.

There are also interesting applications that use a timeout. You can reset the timer (or better: counter) to 0 on some event, then regularly check if the counter is above some threshold and do something if it is above. This way you can detect for example if some belt is empty for more than x seconds.

[Factoruser]

I'm curious what kind of applications for timers you have? I have never needed to use items in circuits before. It's definitely possible to make a combinator-based counter that starts, stops and resets based on particular signals. Or one that waits for an input pulse of sufficient length before providing an output, or one that produces a certain length pulse output in response to a trigger. Only more complicated things, like delaying a whole group of signals by 10+ ticks, really become impractical with the current system.

- this means 167+ms... 1 tick are 16.7 ms.

One use would be for example the nuclear reactors. But also other processes/actions like a well-timed railway crossing, and fun stuff with coloured lamps. An alert may sound only every few minutes and so on. Therefore I'd say a delay might start with 100 ms and reach in 100 ms steps up to 10 minutes, at least one game's day - 7 minutes.

Annotation: added another suggestion above in the OP for the Power Switch.

[robot256]

One use would be for example the nuclear reactors. But also other processes/actions like a well-timed railway crossing, and fun stuff with coloured lamps. An alert may sound only every few minutes and so on. Therefore I'd say a delay might start with 100 ms and reach in 100 ms steps up to 10 minutes, at least one game's day - 7 minutes.

Producing a timed pulse (to trigger fuel injection or reset a train crossing) is very different from delaying a signal. Producing a timed pulse is easy with a simple counter-timer like Tertius mentioned. You don't need any new entities to do that (the Wiki gives a good example). You can count up to 2147483647 ticks (414 days), and produce a pulse at any point you desire. We can debate whether a more compact timer circuit would be desirable, but you don't need items and inserters to do it right now. (I only use item-logic if it needs to remember state when power is lost.)

When I said "delay", I meant something that remembers the input at every tick, and replays that exact sequence a number of ticks later. If you put ten "repeater" combinators one after another, that is what they will do. Delays are mainly used for synchronizing very complicated circuit contraptions, and are memory-intensive compared to simple timers, so timers should be used instead whenever possible.

[Factoruser]

The "Repeater" Combinator would start a timer or hold a signal for the determined time. Delaying a signal in your meaning is the timer mode: the respective signal is sent after the timer ran out. But this is only for "slow" delays of 6 ticks and longer, if you'd need a tick-precise timing, you'll have to use combinator chains.

[Tertius]

This repeater combinator is not yet completely defined. Consider a not fully compressed belt, where items pass randomly, with random space between them. Connect one belt piece to the input of this combinator. It gets a random input of 0..8 each tick depending on the fullness of the belt. The condition in the repeater is ANY > 1, i. e. more than 1 piece on the belt. What should the repeater do with all the signal changes that will happen after it has been triggered but before its timer runs out? Start the timer again or wait until the timer runs out? Throw away all changes in between? You need an additional setting to define timer start on first or on every match.
I guess you want the trigger similar to the condition in a lamp: if a light is turned on, the same condition in your repeater combinator would trigger the timer start. But a decider combinator has the EVERY wildcard, while the lamp cannot have it, because it generates different true/false for every signal, Should it trigger on any matching or only if all match? Or leave out the EVERY wildcard, making it a crippled decider?

Don't get me wrong, but I see this a too complicated circuit entity. It's too compex. There are too many variants to handle, too many edge cases. If you expose all possible decisions as configuration options, it's a super convoluted entity, and if you build it with hard coded choices, it's not a generic device for all players but a device tailored to your individual circuit network build style.

[Factoruser]

It's not necessary to cache the input signals when starting the timer. If you are "routing" the signals, you are intuitively expecting that they are actual values, rather than their former state. Normally you would use the "Repeater Combinator" with a constant value of 1 anyway.

The timer should start everytime newly, when the starting condition is met. Especially in "hold" mode, when it e.g. closes a gate, the gate will stay closed if the starting signal comes again and again.

There's also no doubt, how EVERY has to be treated => just like in the Decider Combinator. The difference between both combinators is in principle just the timer. You get signals for or after a longer period than the usual one tick. If you don't use the starting condition, it "routes" the specified signals from the input network to the output's network but not in backward direction.