Discuss: Power Switch should not "Blink"

[fandingo]

Suggestion #1: put two different circuit or logistic conditions into the power switch: one to turn ON and one to turn OFF.

This ^^ is a best solution to prevent switch from jiggling around exact condition.

It's worth pointing out that the latch solution doesn't accomplish the same thing. It causes overproduction to avoid a cosmetic problem with the power graphs, which seems like a backwards way to design something to me. Additionally, all you're doing is controlling the period of the oscillations. They still very much exist, and even worse, the oscillation point is above what the player wants the setpoint to be.

[fandingo]

This gets back to the age-old problem with Factorio: If X requires maintenance, why don't belts and everything else with moving parts also need maintenance? Following that, what gameplay mechanic can the player reasonably use to service that many entities?

Simple answer: Cause that is not interesting. If a belt fails it will just stop. Nothing serious.
If a switch fails the power of your factory will eventually drained to the max and you get power fails.
Or something else. I mean in most cases "interesting" stuff, sometimes a complete fuck-up.

So why don't belts fail? Why don't inserters fail? Why don't turrets fail (from use not damage)? Is the car going to get a "check engine" light? Even stationary entities like walls and power poles need maintenance. This seems like a capricious proposal to make the power switch a lot less useful in a way inconsistent with everything else in Factorio. I'm still wondering how you're going to tell the players that this one and only one item needs maintenance.

I also disagree with the notion that a belt failure is not that serious if it stops. When that belt (or inserter or boiler or steam generator or water pump) fails delivering coal to your power system, tell me it's nothing serious. That's not much solace to the person who invested heavily in laser defenses.

It is for example the old principle of a tiny vicious circle: Need repair packs to maintain switch, switch turns maintenance-production on/off (with others).

There's also a more practical concern. I run a steam and solar/accumulator power grid. Before 0.13, there was no practical way to get accumulators to actually be used if there was sufficient steam capacity.

Sorry, that is wrong. We had since 0.6 dozens of working solutions to do exactly that (and they are still working).

I'm not aware of any that allow the player to set a singular setpoint based on accumulator charge. Perhaps you can share one? All of the solutions with which I'm familiar involve a ranged setpoint, which is not desirable.

EDIT: I had another idea now, that will solve that problem also (but is a much deeper change to now): What if the switch himself cannot switch faster than each 10 seconds? Think of it, that he needs some kind of reload before he can be used again.

For example: In reality they blow out the high-voltage flash, that remains after switching of some very high-voltage (it doesn't go out itself, cause once air is in ionized state it can conduct electric power very well, which makes it self-sustaining) with pressured air. The pressured air needs first to be created before switching. Sorry for my English.

This doesn't address the problem. The issue is that closed loop control systems cannot use an instantaneous value, even if time-boxed, and reach stability. They will always oscillate. All this change does is increase the period of oscillations. As I said originally, oscillating systems are fine in video games. It's computationally prohibitive to implement stable control algorithms. I'd rather see a "delay combinator" (or even better a moving mean combinator) with a configurable period instead of it being built into just one circuit network entity. It would be broadly useful in lean factories.

I still think the power switch issue is merely cosmetic on the power graphs. There's no functional problem. Change the power graphs to always include solar power production if either solar is reasearch or there's an entity anywhere on the map. The graphs will still show oscillations, but that's an accurate representation of what happens, and to be honest, absolutely what should happen.

[mattj256]

Wow, a lot to think about here.

After some discussion the maintenance part of this suggestion should be cancelled; for the underlaying problem we can use also better aproaches. See end of first page -- ßilk

With an RS latch the problem is solved easily, but inside the power switch it wouldn't be all that obvious why it is chosing one signal over the other. But in the end that's worth its own topic anyways because this one is basically about duabillity and/or maintenance.

ssilk this is your thread. Are you going to change the title? Should we start new thread(s) to discuss some of the other ideas that don't relate to maintenance? It seems like right now we have a number of suggestions that are each intended to make the power switch oscillate less frequently:

• Require maintenance on power switch
• Allow two separate circuit conditions for the power switch: one for ON and one for OFF.
• Make it easier to build things that are currently difficult, like latches or timers or delay mechanisms.
• Require a delay before the circuit network can switch on or off.
• Do nothing; things are fine as they are and this is only a cosmetic problem.

My opinions:

• Require maintenance: I don't like this, it adds to complexity without adding to gameplay. As fandingo says, it's inconsistent with the way other items work in Factorio.
• Separate conditions for ON and OFF. Could be ok, needs work. MeduSalem raises an excellent point: what if the ON and OFF conditions are both true? That needs more discussion, either in this thread or a different thread.
• Make it easier to build latches or timers or general delay mechanisms. This is already possible with combinators or with a mod. I'm not convinced it belongs in vanilla.
• Require a delay before the power switch can switch on or off. This is my favorite right now. But I reserve the right to change my mind tomorrow.
• Do nothing. fandingo says this is only a cosmetic problem, not a functional problem. I don't have a good counterargument. What I will say is that someone who wants to avoid these oscillations should be able to do so without having to use advanced features of the circuit network.

[Neotix]

Do nothing. fandingo says this is only a cosmetic problem, not a functional problem. I don't have a good counterargument. What I will say is that someone who wants to avoid these oscillations should be able to do so without having to use advanced features of the circuit network.

To be honest I also think that way. If power switch oscillate that's menat the control design is bad. The same way player can build rail network witch tones of deadlocks or bots swarm that roam around entire map or moving everything on belts even from far outposts. There is many bad designs that can kick performance in the ass of cause serious problem in factory but it not mean that devs have to develop complicated features to avoid that.

[MeduSalem]

To be honest I also think that way. If power switch oscillate that's menat the control design is bad. The same way player can build rail network witch tones of deadlocks or bots swarm that roam around entire map or moving everything on belts even from far outposts. There is many bad designs that can kick performance in the ass of cause serious problem in factory but it not mean that devs have to develop complicated features to avoid that.

Not everything should require ridiculous combinator contraptions to get a meaningful control.

I for example tried measuring Accumulators and turn Steam Engines on/off with the Power Switches based on demand, which sounded pretty much straight forward... but turned out in splitsecond oscillation because of how there is no cooldown for the power switch.

That's why I'm not going to measure anything from Accumulators again as input for Power Switches for the time being because if you turn on steam engines they will immediately refill the accumulator, but once it hit the threshold the power switch will turn off, but then the accumulator will lack energy again and the power switch will turn on again. And then it will be stuck in the on/off oscillation and you can't do anything about it except maybe trying to add a virtual delay with combinators which is a workaround almost as counterproductive and non-intuitive as having no power switch was before 0.13.

So either Power Switches get a delay/cooldown for switching on/off, or we get something like a Timer combinator to avoid having to use weird combinator contraptions. Maybe someone can come up with an even better alternative on how to measure power demand etc altogether.

Also we shouldn't forget that not everyone is a circuit logic geek but they may still want to do some basic stuff like power management.

[Neotix]

SR-latch is not ridiculous combinator contraption. It's easy and very handy ON/OFF switch.
I don't know how work acc signal (i still don't use acc and solar panels in v0.13) but in previous game I used sensor that send signal based on acc power level. I divided steam engines on sections and turn them on/off depend of acc power level. I newer encounter power switch oscillations (i had power switch from mod) because acc newer was filled or drained witch high speed.

[ssilk]

Ok, I changed the topic of this thread and rewrote the first post a bit.

I think it should be much more clear now, what is meant.

So why don't belts fail? Why don't inserters fail? Why don't turrets fail (from use not damage)? Is the car going to get a "check engine" light? Even stationary entities like walls and power poles need maintenance. This seems like a capricious proposal to make the power switch a lot less useful in a way inconsistent with everything else in Factorio. I'm still wondering how you're going to tell the players that this one and only one item needs maintenance.

That idea with the maintentance is in my eyes dead, cause there have been made better suggestions here. [Maybe I thought a bit it would be a nice idea to introduce maintenance as a concept into Factorio at all. But the maintenance concept is already discussed in many threads. My conclusion: It needs to be much more clever than this. We are far away from this point.]

We had since 0.6 dozens of working solutions to do exactly that (and they are still working

I'm not aware of any that allow the player to set a singular setpoint based on accumulator charge. Perhaps you can share one? All of the solutions with which I'm familiar involve a ranged setpoint, which is not desirable.

Well, they are currently still in the wiki, https://wiki.factorio.com/index.php?tit ... old.22_way
And many can be found in "Show my Creations" board. I think it's not relevant for this discussion, so I won't go deeper here.

The issue is that closed loop control systems cannot use an instantaneous value, even if time-boxed, and reach stability. They will always oscillate. All this change does is increase the period of oscillations.

Well, then you misunderstood the intend of this: It is a graphical issue/glitch, which (I think I can say that) just feels "wrong".

More explained: Currently we have the issue, that there is no difference between a power failure and a network, that is switched off. I'm sure that will be fixed soon. The fix is in my eyes to show a new symbol on the devices. And it makes also no sense then to have that symbol blinking.

Now if the power switch constantly switches on/off this symbol begins to blink or flashes. That is, what feels completly wrong, cause "blinking" is something, that a Factorio player has learned to pay much attention on, and I really think, that should keep like so.

The issue is this: It will distract you from your game, if you have a more or less large part of a factory, that constantly turns on/off. By minimum it will be quite hard to get used to that.

And it is not good from other perspectives, like CPU-load (I know, bad argument), cause I think flashing such a network needs to constancly reinitialize all the devices inside (O.K. I cannot know, how that really works).
And I think it's also some kind of not useful gameplay, to have power switches that work like transistors. You see the discussion around this topic and you have the circuit network for such things.

There's no functional problem.

Right from the technical side: It's a pieces of software. But everyone, which knows a bit about electricity knows: Your light-switch in the kitchens breaks at some point, if you switch too often/fast. That's why many think "this feels wrong": You cannot switch megajoules of power with a device, where you constantly see flashes and cracks...

Now I to mattj256. I will comment here into his quote:

• Require maintenance on power switch
  I think we can call this cancelled, again: See first post
• Allow two separate circuit conditions for the power switch: one for ON and one for OFF.
  Yes.
• Make it easier to build things that are currently difficult, like latches or timers or delay mechanisms.
  Maybe we need that, but I think it's something, for the circuit network, has nothing to do with this issue.
• Require a delay before the circuit network can switch on or off.
  Yes!
• Do nothing; things are fine as they are and this is only a cosmetic problem.
  Is for me no good option, cause I think it's clear, that this problem will appear.

So now to my current opinion:
It should be a combination two conditions plus a delay. And I will explain and argue about it below.

I also think it increases gameplay, if this kind of "flashing" will minimized, cause it removes useless distraction from the player. I think that last one is a very good argument (even knowing, that some players will deny it ).

Separate conditions for ON and OFF. Could be ok, needs work. MeduSalem raises an excellent point: what if the ON and OFF conditions are both true? That needs more discussion, either in this thread or a different thread.

Well, THAT was an important comment, cause I thought it was clear, how a switch must work, if he has two conditions. But then I realized, that most of you haven't learned much about how common electric switches work.

The switch - as it is now - has many similarities with a relais or better a "contactor". Inside of a contactor are two windings: One to put put the switch to "ON" state and one for the "OFF" state.
I know them looking like so:

But (and here comes the similarities) for Factorio it looks more like so:

You need to know to prevent the windings (or here the motor) from blowing up, the switching turns of the winding, that switches it into this state. So the windings get a short impulse of power, just enough to surely switch the contactor into the other state.

For me it was clear, that with two conditions in the power switch, the power switch works similarly:
* If switch is OFF, only the ON-condition is checked and it switches only once.
* Then the switch is ON and then only the OFF-condition is checked.

This is super-common electric switching. It enables players for example to press one button for a short moment and the switch will turn on. And to turn it off you need to press another button.
But this kind of switching (just one impulse is needed to switch) is useful for many, many more things, much more usages than the power switch has currently. I won't like to say endless, but that kind of logic is "different" to all the other logic we currently have and it is so super useful! I mean this is the key for players to say "I want my combinator behave like a switch. What Do I need to do?" and then they come automatically to solutions with an SR-latch and other useful things. For me this element is a key for players to bring them to a point that they are willing to dig deeper into this subject of circuits etc.


This alone doesn't prevent it from circulating of course.

So there is a second rule with the delay after switching.

But I had an new inspiration. The duration of this delay depends on the amount of power, that flows through that switch.

So, why that? Some quite simple thoughts: The issue is more or less a graphical issue. I don't want to have a big field of miners, which constantly turn on/off. That will distract me quite a lot.

But for some devices I think it would be quite o.k. to have switched them a bit faster. And for one single device: Why not each tick? That is not such a problem.

So the rule is simple: The power usage when you turn on or before you turn off should be relative to the delay afterwards (a "real" cooldown), cause the more devices are in that switched network, the more power they will probably need and the more distraction they induce to the player.
For very small networks, the switch behaves like now, but if you switch a really big cluster of furnaces you need a different strategy. For example: It's then much more useful to switch your furnaces on/off in smaller groups, more regulated. Example: if iron below 1000 turn on first group, below 900 turn on second and so on, until all furnaces will work.

Hope that makes sense.

[Neotix]

Real power switch (mid voltage) have three state: OFF, Armed/Ready, ON.
Before you turn power switch ON you have to arm spring and that need time (you can do it manually or electric motor can do it). When spring is ready, you can press ON. OFF switch can be used any time and it also disarm spring. So when you hold OFF you can't arm spring and if you can arm it, you can't turn switch ON.

So if we want to implement that behawior in Factorio we need:
1. Cooldown after turning OFF (no cooldown after turning ON).
2. OFF signal witch higher priority then ON signal.

[bobucles]

Isn't there a really cool animation for the switching process? It makes sense for the actual elecricity to be delayed a split second for this animation. That also helps to hard cap how often the switch can toggle.

[siggboy]

Here's the description of how to set up an S-R latch:
viewtopic.php?t=14556

Please don't make an S/R-latch like this, it's just bad.

If only GopherAtl would change his guide so people would stop copying this S/R-latch.

SR-latch is not ridiculous combinator contraption. It's easy and very handy ON/OFF switch.

Yes, it's probably the easiest non-basic contraption you could make after figuring out feedback loops. A proper S/R-latch is one combinator and one wire, it does not even qualify as a "contraption" in my book.

[Neotix]

It's not bad, just can be done better.
viewtopic.php?f=18&t=14556&start=30#p111192

[siggboy]

It's not bad, just can be done better.
viewtopic.php?f=18&t=14556&start=30#p111192

I say it's pretty bad, because it uses two combinators where one would suffice, it can't handle single-tick inputs, and it can go into an unstable state, even right after blueprinting. The two-combinator latch is really, really bad.

(Not the one that you linked here, that one is fine. It can be even simpler by doing "S > 0 => S 1" if you only want one signal.)

[ssilk]

Back to subject, plz!

[aRatNamedSammy]

should not blink.. or an other icon , not blinking but a steady icon , which mean "this entity is behind a closed switch".. then also we could easily find back those sections later with that sign over it

[siggboy]

Back to subject, plz!

Actually I have something on topic as well .

The power switch being able to switch once per tick is not realistic. Even less so since the animation of the switch closing, and the graphics of the switch, suggest that it's a bulky device that requires time in order to operate.

I'm not decided on the question if it has to be realistic or not. Probably some very clever contraptions can be built if you abuse the fact that you can switch power once per tick. It should not be necessary to run an actual factory.

The power switch should be nerfed so that it can not switch more often than the animation of the sprite suggests is possible (maybe once per second, give or take, the exact time does not matter much).

If the switch is flipped (be it manual or from a circuit/logistic condition), the switch should become unswitchable until the animation has completed (or 1 second has passed, or whatever the appropriate timeout is). Changing circuit/logistic conditions should simply be ignored during that time. The manual switch should be locked/greyed out/unavailable.

Example: the switch is currently "off", and the condition is "Red = 1". You pulse "Red = 1" into the switch. The switch will turn "on" (from the condition), and after 1 second (assuming that's the timeout) it will turn "off" again. If you sent an oscillating "Red" signal into the switch it would turn "on" and "off" every 1 second.

Are there any problems with this approach that I'm currently not seeing?

[siggboy]

So either Power Switches get a delay/cooldown for switching on/off, or we get something like a Timer combinator to avoid having to use weird combinator contraptions. Maybe someone can come up with an even better alternative on how to measure power demand etc altogether.

Well... you're touching several issues here (I haven't quoted everything).

If the power switch is cabable of switching, say, once per second, and your circuit makes it do exactly that, then that's what it is. It should be possible, because it might be desired.

Nobody has ever complained about pumps getting turned on and off every other tick; in fact, it's very useful that this is possible, because you can split liquids that way and you can use the fact to measure throughput.

In your example, with the accumulator load being used to decide if you want to enable steam backup, what you actually need is a "fuzzy controller", to avoid rapid switching while the accumulator load oscillates around a binary condition.

I don't think that the game needs to solve that problem (fuzzy controller) for you. If you want it, for whatever reason, it's your quest to come up with a circuit that does it. It's in the same class of problems like "turning a hold signal into a pulse", "detect a signal change (edge detector)", "store a value for later (register)", "AND/OR condition", etc.

A timer combinator is a quite specialized device, it's arguable if it should be added to the Vanilla game. I don't think it's complicated enough to warrant a new entity in the game. It's rather easy to build a clock/timer, it only requires a single combinator, maybe 2 if you want the clock to wrap around at a certain value. Yes, it's not straightforward like comparing "oil supply" to a constant value, but it doesn't require black magic either.

I consider "how to build a clock/timer" to be part of the enciclopedic knowledge that you gather while you get better at the game (just like knowing what the good and bad solutions for a latch are). There are some areas where the combinators need to be enhanced, because there are simple problems that require Dark Arts if you want to solve them, but clocks/timers are not one of them in my opinion.

The power switch does have some UI issues (the blinking power symbols), and it's probably not realistic that it's so fast (arguable, and what about the pumps then?), but building a fuzzy logic into the switching so the player won't have to come up with that would be really cheap and inconsistent and against the Factorio spirit for sure.

[MeduSalem]

Well... you're touching several issues here (I haven't quoted everything).

[...]

Even though it is offtopic again (sorry ssilk, but I made my statement about the Power switch -> It should work on a delay)... I must say at this point (but I have said it in other threads too sometimes) that I'm not all too happy on how the improved Circuit Network stuff works for certain things in the first place ever since it was first introduced with 0.12. There are really parts where the current implementation requires some additional love to make it more straight forward for beginners.

I give the devs credit that it feels unique... different from every other game I ever had the honor to touch... but at times the Factorio implementation feels like it really is designed to be as different from other games as possible just for the sake of being different as well as trying to be as fundamental as possible, without caring that sometimes it makes things only harder than they'd otherwise need to be. Sometimes trying to achieve very simple tasks that could be solved with just 1 simple and trivial comparison in other games because they support that kind of thing turn out to require several combinators resulting in an absolute wiring crapfest of a nightmare quite fast in Factorio.

Aand that's what is holding me back (and I can imagine other players too) to even want to try fiddle around with certain things because I already know how it would end up. It's also hard to maintain such a combinator mess... If one takes a break from the game for several weeks or months and comes back it's really hard to remember how something worked and to find possible errors if it breaks for some unknown reason because one has to work its way through the mess first to remember why and how.

Point is... I'm playing a game here that's about automatation and maintaining a factory and not about complex Electronic Circuit Design (though I had 3 years of Electrical Engineering before I chose to move over to Construction Engineering and Architecture so I basically should know how fundamental circuit designs work but clearly I'm not a master in this kind of things). I don't know if I'm alone with the feeling but sometimes for a game Factorio really feels like the Circuit Network stuff is implemented more harder than it needs to be to make things harder on purpose so that a handful of people can show off how geeky they are about these things.

I wouldn't mind if some of the Circuit Network stuff would allow for more types of explicit comparisons (AND, OR, NOT, etc) for example and other such things as additional combinators that are more straight forward for day-to-day use. I'm not for removing any of the current capabilities, just for improving the quality of life for people who don't want to read into 20 pages of circuit network design just to be able to make some simple setups. A timer combinator if implemented well could be one of these quality of life things because it's more straight forward for people who are not that much into circuit design than building a clock with combinators is.

For example another thing I find quite weird since 0.12 is that Red and Green Wire automatically get summed up for input into a device. Though summing up is one interesting option, I really would like the feature back from pre-0.12 where one could set a condition for each Green and Red wire seperately... and specify if the Green Wire/Red Wire/Logistic Network conditions should work in an AND/OR fashion (much like the Train Wait conditions work with 0.13). Because it would remove at least one necessary combinator from certain contraptions that have to do such a thing since a device basically only allows one input signal for a condition.

[fandingo]

We had since 0.6 dozens of working solutions to do exactly that (and they are still working

I'm not aware of any that allow the player to set a singular setpoint based on accumulator charge. Perhaps you can share one? All of the solutions with which I'm familiar involve a ranged setpoint, which is not desirable.

Well, they are currently still in the wiki, https://wiki.factorio.com/index.php?tit ... old.22_way
And many can be found in "Show my Creations" board. I think it's not relevant for this discussion, so I won't go deeper here.

You need to take a deeper look at those. None of them do what I can do today with the fast-flipping power switch. Not one. I have little interest in setting a ranged setpoint.

The issue is that closed loop control systems cannot use an instantaneous value, even if time-boxed, and reach stability. They will always oscillate. All this change does is increase the period of oscillations.

Well, then you misunderstood the intend of this: It is a graphical issue/glitch, which (I think I can say that) just feels "wrong".

Then why is there any discussion of changing gameplay behavior to address a graphical issue? Makes no sense.

More explained: Currently we have the issue, that there is no difference between a power failure and a network, that is switched off. I'm sure that will be fixed soon. The fix is in my eyes to show a new symbol on the devices. And it makes also no sense then to have that symbol blinking.

Put a light in the disconnected network or anything that consumes some power...

Now if the power switch constantly switches on/off this symbol begins to blink or flashes. That is, what feels completly wrong, cause "blinking" is something, that a Factorio player has learned to pay much attention on, and I really think, that should keep like so.

The issue is this: It will distract you from your game, if you have a more or less large part of a factory, that constantly turns on/off. By minimum it will be quite hard to get used to that.

And it is not good from other perspectives, like CPU-load (I know, bad argument), cause I think flashing such a network needs to constancly reinitialize all the devices inside (O.K. I cannot know, how that really works).
And I think it's also some kind of not useful gameplay, to have power switches that work like transistors. You see the discussion around this topic and you have the circuit network for such things.

There's no functional problem.

Right from the technical side: It's a pieces of software.

So now to my current opinion:
It should be a combination two conditions plus a delay. And I will explain and argue about it below.

Gross. Make these separate combinators. There's no reason they need to be built into the power switch. Both of these functions have uses outside the power switch.

I also think it increases gameplay, if this kind of "flashing" will minimized, cause it removes useless distraction from the player. I think that last one is a very good argument (even knowing, that some players will deny it ).

You just said how those flashing icons were going to change, and this is so trivially controlled by the player that it shouldn't impact game design.

But I had an new inspiration. The duration of this delay depends on the amount of power, that flows through that switch.

So, why that? Some quite simple thoughts: The issue is more or less a graphical issue. I don't want to have a big field of miners, which constantly turn on/off. That will distract me quite a lot.

I'd like you to think more about the conditions used to control power to a mining outpost. I don't think your concerns are solutions a player would implement. I see two power conditions that would control whether a mining outpost is active:
* Item count: This is the most likely. A count of X falls below a threshold, so the outpost kicks on and produces some ore, which eventually makes its way to the main factory. There wouldn't be fast switching for a few reasons. First, the count of X in the circuit/logistics network depends on the transportation of real items by robots or belts/inserters. Therefore, there's no reasonable way the power switch condition can flip every tick. It just wouldn't occur.
* Load shedding based on accumulator charge. Unless the player sets the condition to a very low value (say <3%) and/or has few accumulators, these miners won't constantly switch on/off. The power switch will, but there will always be enough accumulator charge in reserve (that gets replenished by the next ON tick). The miners keep working and never flash a no-power icon. This is effectively the same as the design I originally posted, and I never ever see these flashing icons. The same thing happens with steam-only since boilers/generators buffer some hot water, so there's no dependency on accumulators to get this to work properly.

But for some devices I think it would be quite o.k. to have switched them a bit faster. And for one single device: Why not each tick? That is not such a problem.

I'm still missing why it's a problem anytime. Are inserters going to get slower when they're moving heavy stuff like locomotives instead of gear wheels?

So the rule is simple: The power usage when you turn on or before you turn off should be relative to the delay afterwards (a "real" cooldown), cause the more devices are in that switched network, the more power they will probably need and the more distraction they induce to the player.
For very small networks, the switch behaves like now, but if you switch a really big cluster of furnaces you need a different strategy. For example: It's then much more useful to switch your furnaces on/off in smaller groups, more regulated. Example: if iron below 1000 turn on first group, below 900 turn on second and so on, until all furnaces will work.

Hope that makes sense.

Let's talk about power flow through the network. Here's a power switch array that I created:



What's the switching speed? This idea would require the power network to calculate *ALL* routes between power sources and their consumers on every tick, and power generation is never isolated to one route. This is a NP-Hard problem that requires an exponential algorithm to solve. Furthermore, it leads to processing loops. Let's say the circuit condition (ARM in your ranged setpoint model) flips to true. The top power switch will need to activate, so it looks at the big poles at the left and right to calculate power flow, so it knows how "slow" it needs to activate. Let's say this is X ticks. However, the next combinator uses the same circuit condition, so it will also need to activate, but we're still in the same tick. The first question is whether the second combinator knows that the first is about to activate. Either way, there's a problem: the second combinator has to tell the first to recalculate but this leads to runaway recalculations, or the first combinator calculates doesn't update it's switch rate to X/2. Instead combinator 2 has the correct X/2 value, but since it will finish activation well before the first (X ticks), it will actually allow the entire flow to pass through the switch, breaking the "delay" mechanic. Things only get worse as more and more power switches enter the picture.

Since today's FFF mentions algorithmic complexity, I analyzed this system. It's O(m * n!) where m is the number of power switches, n is the number of power poles in both networks, and ! is the factorial operator. Entirely impossible to implement in a video game. Even a memoized algorithm would be terribly expensive. It's also totally at odds with current Factorio loop that iterates entities on ticks, which doesn't include a "revisit" possibility.

[mattj256]

I don't want to curtail the discussion here, and I also want a practical solution to the original "problem" of the power switch oscillating so frequently between on and off.

"Power switch should have built-in delay before switching."
viewtopic.php?f=6&t=29115

I broke this off into a separate thread.
(ssilk I hope you don't mind.)

I copied and pasted some of the relevant discussion to that thread. My apologies if I left out anything important.
Some of the discussion here cuts to the soul of Factorio, and it's a perfectly good discussion, and I don't see it any time soon leading to anything practical that the developers can implement. I really do want to make it easier for Factorio beginners to avoid having their power switches flicker, even when it means burning extra coal, even though it is arguably suboptimal.

[ssilk]

No, I don't mind. It's a good idea to split the created ideas up from this thread to discuss them separately, but it's always a lot of work to do that.

Then why is there any discussion of changing gameplay behavior to address a graphical issue? Makes no sense.

How should I explain you that, if you don't see it?

Gross. Make these separate combinators. There's no reason they need to be built into the power switch. Both of these functions have uses outside the power switch.

Good arguments from a technican, not so good from a gamer.

You just said how those flashing icons were going to change, and this is so trivially controlled by the player that it shouldn't impact game design.

Shouldn't. But that's, what I believe, or do you believe, that I put so much time into this subject, if I didn't thought that? Now prove me wrong.

I'd like you to think more about the conditions used to control power to a mining outpost. I don't think your concerns are solutions a player would implement.

Of course not. A player uses the stuff that is available.

Therefore, there's no reasonable way the power switch condition can flip every tick. It just wouldn't occur.

Of course. It will blink then. In irregular intervals, like a broken neonlight...

I'm still missing why it's a problem anytime. Are inserters going to get slower when they're moving heavy stuff like locomotives instead of gear wheels?

No, because there is no created gameplay doing like that.

Let's talk about power flow through the network. Here's a power switch array that I created:

I don't know what you see, but I see the split-point between two electric networks. If you switch off a switch it takes the amount of needed power used in the controlled network and calculates the delay from that. There is no NP-hard problem. It's a quite simpel calculation.