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

[Koub]

They already behave consistently. Every tick, every powered entity's buffer is equally filled with energy. Whenever there is enough energy to perform 1 action, the energy is consumed in the buffer, and the action is processed.
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.

[ilikegoodfood]

Frankly speaking, I was surprised to learn combinators worked AT ALL on low power. I would have expected them to just flat out stop working when power got below a threshold, and the threshold I'd consider reasonable would be 100%.

That would be a great solution, as it would both stop the desync issue and make intuitive sense.

They already behave consistently. Every tick, every powered entity's buffer is equally filled with energy. Whenever there is enough energy to perform 1 action, the energy is consumed in the buffer, and the action is processed.

I can see that it is a consistent behavour, but it leads to the combinators behaving in a way that appears inconsistant. What would happen if they had no buffer at all, and therefore combinators would all stop uniformly during a brown-out? Is that even possible with how the game handles power consumption?

[Nosferatu]

What I got out of this thread:
Not any brown out causes this.
Your power supply must fall below 50% of demand.

This should never happen with nuclear reactors. You have to rely heavily on solar and akku...

Solar farms don't need combinators.

So bottomline: nuclear for the win!

[Theikkru]

I don't know why that makes no sense. Inserters are mechanical and move slower when deprived of power. Combinators are little computers with no moving parts. I would expect them to behave differently with low power.

How does it make sense that an inserter, which also behaves like a little computer when it's sending out signals, can still keep sending out single-tick pulses like clockwork even under low power, while a combinator gets sluggish and starts sending out signals over multiple ticks?

Frankly speaking, I was surprised to learn combinators worked AT ALL on low power. I would have expected them to just flat out stop working when power got below a threshold, and the threshold I'd consider reasonable would be 100%.

Even this would be preferable to the way it is now. At least then it would be consistent, and wouldn't cause all sorts of random logic errors that are a PITA to track down.

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.

They already behave consistently. Every tick, every powered entity's buffer is equally filled with energy. Whenever there is enough energy to perform 1 action, the energy is consumed in the buffer, and the action is processed.

It is not consistent. The energy level of inserters doesn't affect how its signals are sent. While combinators repeat the same signal during "dead" ticks, inserters never send a pulse signal for more than 1 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.

What I got out of this thread:
Not any brown out causes this.
Your power supply must fall below 50% of demand.

This should never happen with nuclear reactors. You have to rely heavily on solar and akku...

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.

[foamy]

What 'depth' does fixing this remove? The depth in combinators is in their logic, and for that depth to be genuinely explored it needs to behave in a deterministic and predictable way.

I'm going to stop you right there. Factorio is literally deterministic. If it weren't then multiplayer would not work.

There's deterministic, in the sense that if you precisely replicate all conditions and the full and entire game logic, including ones you cannot possibly know or have access to without direct examination of the game's binary data -- for example, a pseudo RNG, such as governs the output of uranium --, you can recreate the next step. This is neither particularly useful nor particularly interesting for a player, because it would hold true for a dice-roller app too.

And then there's the actual *useful* meaning of deterministic in this discussion, which is that if you have access to the actual tools the player does, you can know what will happen.


The second form, which is one that is central to Factorio's goals of handling things with design and engineering and planning, is the one that's relevant here. And in this case, combinator logic ceases to be deterministic, because the same inputs with the same timing into the same logic can result in different -- and unreplicable when troubleshooting, to boot -- outputs depending on whether one more laser turret fired, taking you from 50.1% power to 49.9% power. It is the equivalent to cosmic rays flipping bits or signal noise, which are generally considered flaws to be removed.

I'm not asking that combinator slowdown (and full stops on power loss) be removed. I think that's a good thing that, of itself, is more than sufficient to encourage you to make damn sure your logic is powered, because if it's not, your precision controls will start getting sloppy and/or cease to function altogether. That's fine.

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.

[Deadlock989]

And then there's the actual *useful* meaning of deterministic in this discussion, which is that if you have access to the actual tools the player does, you can know what will happen.

Oh, well, sure, if you can just make words mean anything you like, this argument's clearly over.

[Theikkru]

And then there's the actual *useful* meaning of deterministic in this discussion, which is that if you have access to the actual tools the player does, you can know what will happen.

Oh, well, sure, if you can just make words mean anything you like, this argument's clearly over.

No, that's a clearly recognizable contextual definition, because the strict definition is a useless tautology in the context of computers and software. You've also failed to address any of the actual argument made. Why exactly are you so adamant that the current behavior persists? Is it because you don't think low power penalties are punishing enough? I don't see you campaigning for inserters to drop items on the ground if they run low on power.

[Deadlock989]

Why exactly are you so adamant that the current behavior persists? Is it because you don't think low power penalties aren't punishing enough?

Because the banana maelstrom is side-translated by the margin coalescence, obviously.

"Low power penalties", lol. Oh no, someone was mildly inconvenienced because their assumptions were wrong and they can't be bothered to power their base properly. Quick, rewrite all the base game logic to suit them.

[Theikkru]

[...]These stout-hearted defense 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.

Consider me equally baffled.

[boskid]

I have to step into this discussion and stop it. This logic will stay as it is. Combinators are consuming energy and if there is not enough energy they will not update. With combinatorial logic this is all fine and good, no questions asked. In case of sequentional logic (when there are loopbacks) there is assumption that combinators are updating every tick for those logic to work. Combinators are not being updated when they have not enough energy. If a player knows combinators may not update because of loss of electricity (they are told about this by requiring electricity to be provided for them and by not updating until electricity is provided) and logic they are designing depends on them updating every tick, and purposefully allows them to enter into low power state and starts to complain "why are they not updating" then well...

Alowing them to update always even when no power would remove the need to power them. 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. If combinators not updating and so keeping previous output value are hard to notice, maybe i should change them to clear their output in case of low power condition?

[jodokus31]

It's obviously not so easy to fix/change? Boskid offered to increase electricity buffer so that combinators break with under 25% power satisfaction. But i doubt you guys are satIsfied with that.
Edit: didnt notice the reply of boskid

[foamy]

I have to step into this discussion and stop it. This logic will stay as it is. Combinators are consuming energy and if there is not enough energy they will not update. With combinatorial logic this is all fine and good, no questions asked. In case of sequentional logic (when there are loopbacks) there is assumption that combinators are updating every tick for those logic to work. Combinators are not being updated when they have not enough energy. If a player knows combinators may not update because of loss of electricity (they are told about this by requiring electricity to be provided for them and by not updating until electricity is provided) and logic they are designing depends on them updating every tick, and purposefully allows them to enter into low power state and starts to complain "why are they not updating" then well...

Neither one of the things you mention here are in fact the issue. The problem isn't that combinators slow down, the problem is that other entities don't. People keep responding as if it's the first and I don't understand why.

Combinatorial logic can break under low power conditions, because inserters behave differently from combinators: inserters generate logic signals at full speed regardless of their power level. Combinators don't detect those full speed signals, though. The answer is to therefore make the logic outputs of things like inserters have the same slowdown in processing combinators do.

Alowing them to update always even when no power would remove the need to power them. 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. If combinators not updating and so keeping previous output value are hard to notice, maybe i should change them to clear their output in case of low power condition?

None of these is being proposed either. If someone has logic systems with different power levels trying to talk to each other, that's their problem. The problem is that logic devices with the same power level will drop out of synchronicity with each other because, for logic networks, inserters and combinators behave differently in low power conditions.

A combinator not updating is fine. The problem is that the inserters don't share the same behaviour. Nor do belts, which will generate and process logic with no power at all. That's why one of the suggestions here, far from saying combinators shouldn't require power, is that circuit-wired belts should.


The goal is simple: The loss of power should impact all logic entities -- combinators, belts, inserters, pumps, switches, and so on -- in the same way.

[Theikkru]

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

[jodokus31]

Combinatorial logic can break under low power conditions, because inserters behave differently from combinators: inserters generate logic signals at full speed regardless of their power level. Combinators don't detect those full speed signals, though. The answer is to therefore make the logic outputs of things like inserters have the same slowdown in processing combinators do.

What is a fullspeed Signal? A pulse Signal is sent in one tick. It cannot be longer based on electricity

[Theikkru]

What is a fullspeed Signal? A pulse Signal is sent in one tick. It cannot be longer based on electricity

Yes it can. If you make a pulse generator with combinators and run it under low power, the pulse will last longer when the combinator stalls.

[jodokus31]

What is a fullspeed Signal? A pulse Signal is sent in one tick. It cannot be longer based on electricity

Yes it can. If you make a pulse generator with combinators and run it under low power, the pulse will last longer when the combinator stalls.

But it's a pulse through a combinator, which obscures it. A pure pulse is one tick long. A pulse from an inserter has to be obscured identically and in sync.

[Theikkru]

But it's a pulse through a combinator, which obscures it. A pure pulse is one tick long. A pulse from an inserter has to be obscured identically and in sync.

I'm not sure what you mean by "obscure". Combinators, inserters, and belts can all be set up to generate pulses. The difference is that pulses generated by combinators can be protracted by low power, whereas those from inserters and belts are (currently) always 1 tick.

[jodokus31]

But it's a pulse through a combinator, which obscures it. A pure pulse is one tick long. A pulse from an inserter has to be obscured identically and in sync.

I'm not sure what you mean by "obscure". Combinators, inserters, and belts can all be set up to generate pulses. The difference is that pulses generated by combinators can be protracted by low power, whereas those from inserters and belts are (currently) always 1 tick.

I mean a combinator under low power is able to change the 1 tick pulse almost randomly. The pulse from the inserter or belt would have to be changed by the same rules.

[Theikkru]

I mean a combinator under low power is able to change the 1 tick pulse almost randomly. The pulse from the inserter or belt would have to be changed by the same rules.

It's not random, but yes, that's the idea, that all logic devices follow the same low power rules. Combinators already do that amongst themselves most of the time.

[ssilk]

What 'depth' does fixing this remove? The depth in combinators is in their logic, and for that depth to be genuinely explored it needs to behave in a deterministic and predictable way.

The depth is, that you need to think about it, once you find out, that there is this behavior. And there are several strategies:
- you can ignore the problem and live with the risk.
- you make your electric network waterproof/overpowered.
- you create circuits, that doesn’t matter, if they work or not.
- you make simple circuits without combinators only.
- you make circuits, that work reliably by synchronizing somehow.
- you make circuits, that go into a safe state, when power is too low.
- you make circuits with their own safe power supply.
- etc.

Some of the options you have are really complicated to implement.

So I can call that “depth”.

I won't say nobody has ever used the mismatch between combinators and inserters to achieve something, but it reminds me of that XKCD comic about workflows. Fixing it makes the game better; leaving it as-is means it's a rake-handle waiting to smack people in the face when they do try to use the depth that combinators allow, and what's more it's not something that is at all easy to diagnose even by the standards of tracing combinator logic.

But “fixing” it removes the above mentioned depth. And it sounds like it’s broken, but it’s not.
What’s really missing - and you point here to something which I already said many times - is that the circuits lacks the ability to test them.

That is the core of this problem!

Another aspect of that problem is described here:

https://forums.factorio.com/viewtopic.php?f=6&t=41176 Improve Basic Circuit Overview

I want this: I mark an area and all entities in that area are moved into some kind of simulation. A map-editor-like surrounding. And here I have endless energy, but I can also reduce the power, to answer the question: what happens with my factory, if I have only 50% energy?

New players can and should use this and find out, what will happen when they build circuits with too less power, and everyone is fine.

Edit:

The point is that in an equal brownout logic devices should slow down equally.

I think you overlock the complexity of Factorio, foamy.

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)

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.

Hm, yes, I understand that. For me as old player it’s sometimes really hard to see the struggle and frustration of new players and because I had already been going through all of this and I found a solution and I am proud of it I mean now the new players should also go through this process. Something like that.

That’s sometimes right, sometimes wrong. Here I think it’s right, because a) you have to decide as player which I find really interesting and b) the game is missing this above explained simulation mode for many, many other reasons.