Powered logic devices (combinators, inserters, etc.) should behave consistently under low power

[Theikkru]

See this topic.
I'm told this is intended behavior, but it feels really broken, and seems like bad game design, since it can cause all sorts of strange problems that are really hard to find, diagnose, and fix.
I propose that at the very least, all powered logic devices on the same electrical network should behave the same way when suffering from low power. Whether that means everything runs on the same slow, jittery clock or isn't affected at all, I don't care; I just think it should be consistent across devices so that a dip in power doesn't completely break the logic.
The current implementation just makes pulsed signals a large enough PITA that I'm leaning towards avoiding their use entirely.

[valneq]

While I agree with you in principle, I don't think the devs are going to change this. After all, this issue only arises when you run low on power.

A workaround is to make sure that you never run into a brownout once you have sophisticated circuit networks configured. There are ways to prepare backup power via steam engines or steam turbines that only kick in once accumulator charge is low. Also, self-expanding solar farms help considerably.

[Theikkru]

[...]There are ways to prepare backup power via steam engines or steam turbines that only kick in once accumulator charge is low.[...]

The irony is, I encountered this problem when trying to design this very thing; the logic for my nuclear setup was behaving strangely when I tried to boot it up (and take a guess as to why I was trying to boot it up). How am I supposed to design a robust power system if the logic controlling it breaks whenever the power is overtaxed (despite whatever backups)? The solution to low power is obviously more power, yes, but that doesn't mean the factory should fall to pieces in the meantime every time the lights dim.

[valneq]

Well … if you have a certain power buffer via accumulators, you can use the accumulator charge to see if you need more power. When accumulators fall below, say, 20% your backup power should kick in. A set–reset latch can help to then turn backup power off again once accumulators are back at, say 90% charge.
Remember, you reach a brownout only when all accumulators reach 0%.

Before de-activating backup power for the first time, you should make sure that your logic works and that the accumulators are reasonably charged. And no-one forces you to design your circuit logic with your main power network that is at the risk of brownout. You can always design the circuit logic with a dedicated temporary solar power + accumulator supply.

[Theikkru]

I'm well aware that you can work around this; I can think of a few ways to make the circuit resistant to this problem, but they all feel like really clunky workarounds (e.g. backup power for the logic control of a backup power system, or shutting off the logic circuit if accumulators reach 0) compensating for behavior that shouldn't happen in the first place, and all of those workarounds have obscure failure/lockout cases too.
If combinators are going to stall intermittently under low power, why don't inserters do that too? If everything just behaved the same way, the logic could slow down just like production does without weird errors.

[foamy]

[...]There are ways to prepare backup power via steam engines or steam turbines that only kick in once accumulator charge is low.[...]

The irony is, I encountered this problem when trying to design this very thing; the logic for my nuclear setup was behaving strangely when I tried to boot it up (and take a guess as to why I was trying to boot it up). How am I supposed to design a robust power system if the logic controlling it breaks whenever the power is overtaxed (despite whatever backups)? The solution to low power is obviously more power, yes, but that doesn't mean the factory should fall to pieces in the meantime every time the lights dim.

I agree that consistent performance of logic networks would be nice, so that they behave the same, just slower, if the power is down by the same amount across the whole network.



But in the meantime, what you want for that kind of system is some sort of dedicated uninterruptible power source just to power your logic. Usually people build that in the form of a solar panel & accumulator, and use that, on an isolated grid, to power the controls for everything else. I also like to build a brown-out detector that works on an edge signal into a short-term rolling average accumulator, so that I can tell how quickly a given grid's accumulators are discharging and therefore how close it is to brownout. As it approaches, I start cutting the draw from that grid, so that it never goes into actual brownouts unless the supply is more or less completely shot. Useful failsafe.

[Theikkru]

[...]Usually people build that in the form of a solar panel & accumulator, and use that, on an isolated grid[...]

I get what you're saying, but I just want to point out that this is the perfect example of what I mean. A big reason people go through the effort of building fancy power systems is because they don't want to go with the braindead option of "just plunk down another solar mat" to satisfy their power needs. So after much hemming and hawwing you come up with a shiny new power design, only to find that it breaks for some weird reason. After a lot of experimentation you narrow down the problem to combinators going wonky when they don't have enough power, and the solution to that is? "Just plunk down a solar panel (and an accumulator and run it on an isolated circuit)." Or maybe you get into recursive backup power.
The point is that broken low-power logic doesn't add anything to the game; it just makes it more punishing. If you're going to make me plunk down a solar panel anyways just to solve this niggling problem, why don't we pretend the combinators come with mini solar panels or something and just have them work? It doesn't take any additional thought to work through a problem you've already solved, just more frustration (to diagnose the problem) and more busywork (to nest in an isolated network). And then you have to watch out for errant power pole placement from then on.

[boskid]

I gave some details about this behavior in the other topic.

Possible solutions that i see:
- solar+accumulator is a simple solution, it is able to backup up to 42 combinators. Combined with 1.1 feature of blueprints preserving power pole connections (fff-362) it should be also easy to duplicate power production without worrying about wires.
- as only arithmetic combinator and decider combinator are affected by this behavior, why not doing some creative logic combinator-less? belt based SR-latch with 2 belts conditionally enabled and some of them being sensors, 1 item on belts (could even self-starting by having content of all belts counted, requester chest + inserter to put item when there is none. Or use some crazy rail signal logic like chain signal turning red or blue if there are closed rail signals in front - that is just heresy, but does not depend on energy at all
- reduce amount of logic to absolute minimum. Combinator with full energy buffer has enough energy for 2 ticks of operation.
- have a backup fast reacting (as few combinators in between as possible) logic that is able to react to power drops and take some actions (direct accumulator read into power switch for example)
- (playing modded, combinators could have primary-input usage priority)
- (as described in other topic, combinator's energy buffer could be increased, slightly increasing their priority within secondary-input usage priority)

I am ok with how arithmetic and decider combinators are working right now - it gives some problems for the players to solve.

[Theikkru]

Again, the issue I have isn't that the problem can't be solved, it's that:
1. it's disproportionately difficult to diagnose, because the symptoms are so obscure and intermittent, making it very difficult for an unaware player to determine the cause
2. it can wreak all sorts of havoc in the factory unexpectedly because it can manifest in any number of ways depending on the logic used; the more complex the logic, the worse it can be
3. its consequences (completely breaking the behavior of a system) are disproportionately severe and not consistent with other low-power behaviors, which are directly visible and only impose a relatively minor, proportional, quantitative impediment (such as slowing down or dimming) on factory operation
4. its solutions fall under two categories:
Preventative: keeping the circuit from reaching a state of low power. This includes the trivial solar/accumulator and the redundant/recursive backup power to the backup power. These are unengaging because they require no additional thinking to implement.
Workaround: not using pulse signals or not using combinators to solve the problem. This feels forced and broken, because the whole purpose of combinators is to do logic, yet the player must now come up with a non-pulse or non-combinator way to do logic because combinators don't work properly. If the past years of community content have taught us anything, it's that Factorio players don't need contrived problems to come up with creative designs. People will make crazy belt/train logic anyways if they feel like it. Instead, this discourages the use of pulse signals with combinators, which is in fact stifling creativity.

This part confuses me:

[...]
- reduce amount of logic to absolute minimum. Combinator with full energy buffer has enough energy for 2 ticks of operation.
[...]

How does reducing logic help with a full energy buffer? If the trigger signal (such as an inserter pulsing an item) does not coincidentally arrive in the first few ticks after the power runs low, then the buffer will have run down already.

[ilikegoodfood]

I haven't run into this issue yet, but as my factory is growing,the amount of combinators is slowly growing. Glad I spotted this thread and definately agree with OP.

[Deadlock989]

Or - and I appreciate this seems like madness - you could just not have a crappy power supply.

Some people won't be happy until every single consequence and wrinkle is ironed out of this game forever.

[Theikkru]

[...]you could just not have a crappy power supply.[...]

"Just put down another solar mat."

[...]until every single consequence and wrinkle[...]

"Consequences and wrinkles" should not be there just for the sake of being punishing; they should be there as part of an interesting problem. An obscure unreliability of combinators that throws random monkey wrenches into factory logic isn't an interesting problem, especially if the "solution" is something trivial or redundant like putting down more solar. It's just another manifestation of the low power problem that's really aggravating to diagnose and clean up after.

[Deadlock989]

Literally never had a problem with it in 3000+ hours of play. And I only ever use solar as my main power source in about a quarter of my games.

Because I try to avoid having a bad power supply, because that's bad, for more than one bad reason.

[Theikkru]

That's my point. Players are already taught by other, far more obvious mechanics that low power is bad. Having combinators break logic too is needlesly punishing and just adds frustration and confusion to the problem.

[Deadlock989]

If this game ever stops being frustrating, I will stop playing it. Or, more likely, just mod it back to the interesting behaviour it had before. c.f. oil processing.

[boskid]

"Just put down another solar mat."

There is a difference in placing 1000+ solars and 840+ accumulators to increase general power production, and placing 1 solar and 1 accumulator to have isolated electric network that backups the power needs for up to 40 combinators.

[Theikkru]

There is a difference in placing 1000+ solars and 840+ accumulators to increase general power production, and placing 1 solar and 1 accumulator to have isolated electric network that backups the power needs for up to 40 combinators.

From a problem solving standpoint, I don't see the difference. Solar is solar, and power backups are already a thing, so making the player include a solar backup for all the combinators is just more busywork.

[foamy]

I'm with ikkru here; a problem being present doesn't mean it's an interesting addition, even to a problem solving game. I'm not super fond of 'oh well it's something for the player to solve, that makes it interesting' as an answer to inconsistent or unexpected behaviours; it's right up there with dismissing something with 'oh there's a mod for that' as a pet peeve.

Having logic systems slow down or stop because of low power is a useful problem to solve, because there are systems you don't want that to happen to and so want to design some kind of UPS for (in the same way as designing a backup system for the inserters and/or pumps of a nuclear or steam plant would is). Having a logic circuit come back with 1 + 2 = 0, on the other hand, or other async behaviour you can get in low power situations, is awkward.

It might not be fixable for whatever reason, but it's not defensible on 'this makes the game better' grounds, any more than oddities like asymmetrical inserter behaviour are.

[jodokus31]

The behaviour gets weird, if power satisfactIon is below ~50%. I dont consider the behavior as very problematic, because who would Run the factory with such low power without fixing it.
If it happens anyway, i agree it's very frustating esp. If you dont find the Problem. That's an issue of communication: wiki, tooltip, etc.

[Jap2.0]

I think I get the general idea, but can someone succinctly say what's inconsistent about this? Every other entity in the game works slower when not receiving full power; combinators do the exact same thing.