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

[Theikkru]

The depth is, that you need to think about it, once you find out, that there is this behavior. And there are several strategies:

I should point out that a big problem with this idea is that it's so difficult to identify that there is this behavior. Judging from the replies in this thread, the vast majority of people didn't even know it existed (much less encounter it), and those that did just concluded that combinators are unreliable under low power, without any further detail. These things you call "depth" are problematic, because of what I described earlier:

[...]
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.
[...]

- you can ignore the problem.

Not a solution.

- you make your electric network waterproof.

Preventative. This is the same solution for all low power problems, and would not be invalidated if this inconsistency is fixed.

- you create circuits, that doesn’t matter, if they work or not.

Not a solution. (Unless I'm misunderstanding what this is supposed to mean.)

- you make simple circuits without combinators only.

Workaround. You can do this anyways if you want to, (and some players already have,) but forcing players to do this makes combinators feel broken.

- you make circuits, that work reliably by synchronizing somehow.

Workaround. This effectively means not using pulse signals generated by belts or inserters, and doing it with combinators instead. Makes the pulse functions on belts and inserters pointless.

- you make circuits, that go into a safe state, when power is too low.

Preventative. This is a minor variant on the backup power idea.

- you make circuits with their own safe power supply.
[...]

Preventative. Again, redundant with backups for low power in general.

A lot of these methods have other good reasons to be implemented, so they wouldn't be lost along with the inconsistency, and the rest are just ways to make the logic do what combinators and pulse signals were supposed to do in the first place but can't be relied upon to. I call that broken.

There can be unlimited numbers of electric networks. All can have their own power state. Which means, you can have one circuit with combinators laying in two or more different electric networks!

And added to that is, that there is a power switch, which can be used to turn off anything behind it. Even the circuits in that area. I use that sometimes to spare cpu cycle. (When I’m honest I’m not sure if that is really a good strategy but that’s not the point here)

The convenient thing is that the power network already has to deal with this in order to figure out which devices draw power from which network, so a logic clock could use that information as well. Consequently, electric network complexity shouldn't present any additional cost or barrier to logic clock implementation.

[jodokus31]

I think there are only 2 realistic options:
1. Combinators output nothing in low power.
2. Combinator work without power

1. does not really help, but just makes the it more obvious, that low power is bad
2. Is a severe dumb down imo and I really dont want it.

The optimal option is make all entites behave the same by the same rules under low power. But I dont think it's realistic

[Deadlock989]

I think there are only 2 realistic options:
1. Combinators output nothing in low power.
2. Combinator work without power

You forgot: 3. Do nothing, because there isn't actually a problem, except the irrelevant problem of a couple of stubborn players who refuse point blank to stump up a trickle of power to run their incredibly sensitive and fragile combinator creations that they for some reason have pinned major operations on.

Which is the stated course of action the devs have said they will be taking.

[jodokus31]

You forgot: 3. Do nothing, ...

Agreed. But with the reason that it's a minor issue, which has almost no Impact for most players.

[Theikkru]

[...]
The optimal option is make all entites behave the same by the same rules under low power. But I dont think it's realistic

How is this unrealistic? Throughout my posts, I've outlined how electrical networks could be used to implement logic clocks that keep all logic devices operating within them synced to each other, how it would make sense and be consistent, and even how it could help optimize the game:

[...]Whether that means everything runs on the same slow, jittery clock[...]

[...]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.

[...]
(B) everything gets slow and jittery in lockstep, in which case the full-power combinator should register multiple counts per inserter grab because the inserter signal is sluggish and lasts more than 1 tick, while the low-power combinator keeps true count because it's running on the same protracted power clock.

As a corollary to this topic and the scenario (B) above, I'd like to add that, in the name of consistency, I'd welcome the addition of a 1W power requirement on other normally un-powered devices (such as belts) when hooked into a logic circuit. Not only would that add a bit of realism, (given the extra apparatus that appears on them graphically,) it would also ensure that all logic devices on the same electrical network stay in sync.

[...]
Also, while it's technically true that combinators can get desynced from each other, that doesn't happen under normal circumstances; combinators on the same electrical network will experience the same buffering math, and that buffering gets resynced whenever power is sufficient, so the only cases where combinators on the same network get desynced would be when you build a bunch of them while power is low and try to use them before power is restored to full. You can test this in the demo save I posted by duplicating the low-power test combinator a few times.

[...]I don't think it's up to the game to cache pulses for you because you can't build well.

The point isn't that the game should go out of its way to help you compensate, it's that it makes no sense that inserters inconsistently don't suffer the same effects of insufficient power that combinators do. The logic not breaking should be a natural consequence of low power being applied equally (which is why I specified powered logic devices on the same electrical network).

The real question here is why things on the same electric network can get desynced at all, given that such a problem has no real game design positives and a lot of negatives, as I've argued earlier. I can't imagine it would be that hard to just clock logic behavior using the electric network; it might even help optimize performance since dedicated logic devices (e.g. combinators) wouldn't need a power buffer anymore.

[...]

I have never designed a game, at least not one as complicated as Factorio, so I can't speak to any of this in general. I though CAN imagine that it might be hard to "just clock logic behavior using the electric network," considering none of us know how any of this is coded internally.

I can surmise some things based on current behavior. Because combinators CAN be desynced from each other, they must have individual buffers in their data tracking how they are powered individually. Moving the clock to the electric network would be as simple as removing said buffer from dedicated logic devices like combinators and such, and putting one on each electrical network instead. Because at least almost all factories with non-trivial numbers of these devices will have more combinators than electrical networks, this would help performance. Updates to logic devices can then just query the electric network they're currently drawing power from to find out whether there's enough power to do logic that tick.
[...]

What you ask for is that all electricity powered entities within a network wait for all of the other entities to have their power buffer full to start their action at the same tick. There is absolutely no reason why all those entities should communicate to synchronise themselves. Just the concept of it doesn't make sense.

In real electric networks, brownouts manifest as a synchronized drop in voltage across the entire network. There is no need for communication for the behavior to synchronize. Being dependent on a common property of the electric network from which power is being drawn is enough. As I pointed out previously, synchronizing between combinators already happens naturally most of the time.
[...]

[...]Trying to make them all update at the same time would cause implementation issues when there would be multiple combinators in the same circuit network logic but they would be powered by isolated electric network with different state of overload.[...]

What would the implementation issues here be? All logic devices on the same electrical network update in sync, and ones on different networks do not. You'd get weird behavior (like now) if logic devices desynced across electrical networks, but that can be left as an edge-case to be handled by the player, since there's a clear piece of information (different electrical networks) immediately available to the player to help diagnose it.
It would also help optimize UPS.

[...]

There can be unlimited numbers of electric networks. All can have their own power state. Which means, you can have one circuit with combinators laying in two or more different electric networks!

And added to that is, that there is a power switch, which can be used to turn off anything behind it. Even the circuits in that area. I use that sometimes to spare cpu cycle. (When I’m honest I’m not sure if that is really a good strategy but that’s not the point here)

The convenient thing is that the power network already has to deal with this in order to figure out which devices draw power from which network, so a logic clock could use that information as well. Consequently, electric network complexity shouldn't present any additional cost or barrier to logic clock implementation.

I haven't seen any specific arguments addressing this idea; instead, there's a lot of marginalization, denial, and misunderstanding of the problem:

I'm getting the strong impression that those shutting this idea down are simply not seeing the issue that is being very reasonably and patiently described over and over again. I'm very impressed by foamy's patience in this.

The negative impact of low power on logic systems (combinators) is disproportionate to the negative impact on everything else in the factory. This in and of itself is an inconsistency that will hamper less-skilled players trying it out. The lack of it being explained anywhere, that this can even happen, and the lack of diagnosis in an already complex system exacerbates this significantly.
[...]

[...]
I see this a lot. "It rarely/shouldn't happen(s) if you build your base properly" is not a convincing argument for the behavior to be all sorts of broken if it does happen. Again, I'm not saying that there shouldn't be ANY consequence to low power on logic networks; I'm arguing that it shouldn't be inconsistent and disproportionately punishing for no good reason. It's a bit absurd that low power can be so much worse than no power.

[...]
The point is that in an equal brownout logic devices should slow down equally. These stout-hearted defenses of an absurd and uninteresting corner case baffles me, particularly when they don't seem to pay much heed to the actual issue under discussion.

Nobody's talking about making sure all the buffers are full either @Koub, I have no idea where you got that from.

[jodokus31]

[...]
The optimal option is make all entites behave the same by the same rules under low power. But I dont think it's realistic

How is this unrealistic? Throughout my posts, I've outlined how electrical networks could be used to implement logic clocks that keep all logic devices operating within them synced to each other, how it would make sense and be consistent, and even how it could help optimize the game:

My assumption is that it's difficult and not worth the effort. But i really dont know.
Supporting circuit wires across different electric networks dont have to be thing. It's Ok if it would work in one electric network under low power. Anyway it's up to the devs

[ilikegoodfood]

I haven't seen any specific arguments addressing this idea; instead, there's a lot of marginalization, denial, and misunderstanding of the problem:

This right here. The amount of 'not reading' and 'not addressing the issue being discussed' going on in this thread is truly mind-blowing. I expect to (and do) see this sort of behaviour when watching memebers of parliment in my country discuss topics (or rather not discuss them) on the official livestreams. I am shocked to find it in a dedicated and inteligent community such as this one.

Deadlock989, [Moderated by Koub : No personal attacks please]. You have said what you wanted to say. Please just leave already and let those who care about this, those it does or may effect, have a conversation. If it ever gets fixed, you will never even notice it in gameplay, so you have absoluetly no valid reason to be here anymore.

[NotRexButCaesar]

I have seen no arguments against this except “I wouldn’t use it” which is not a real argument.

[Koub]

[Koub] This thread is indeed going nowhere. I was in the process of locking it when boskid posted his last post, so I let the discussion keep on. Seems it's the right time to proceed now.