Proposal to fix: the pulse function on inserters (+belts?) is inconsistent under low power.

[Deadlock989]

I mean, if you really wanted to you could make a mod that requires everything to be powered

No, not really. Several entity types don't support an energy source. Belts and ammo turrets are the first ones I can think of. Without direct engine support, you're reduced to hacky scripts. I can't think of any way of scripting an equivalent for belts which wouldn't murder UPS and break and suck literally all the time. That's why there's no "powered belts" mod on the portal that doesn't have massive game-breaking drawbacks like literally deleting every item on the belt when it "loses power".

Some people get quite insistent about how it doesn't make sense that belts require power. Me, ammo turrets bother me more. I got over it.

[Optymistyk]

Tbh I think it makes more sense gameplay-wise for ammo turrets to require power than for combinators, but I digress.

I haven't tried making mods for Factorio, but just for the sake of argument I couldn't find any mods that make circuits/assemblers not require power, so I assume it's also not that easy. Circuits work differently when at low power, so I assume if you set them to require no power they may work jank. Assemblers produce Pollution based on how much Power they take, so an Assembler that takes no power would probably generate no Pollution. But maybe not. Honestly that's irrelevant.

We're talking Vanilla. If you can't do something with the modding tools that's a problem with the modding tools(or with your expectations). But Vanilla should only do what's most sensible from the gameplay perspective. I'd argue there's no good reason for circuits to require power, constant combinators are already free to use. On the other hand removing the power requirement would make circuits more intuitive and readable. It's a small change but I think it's for the better.

[Deadlock989]

I couldn't find any mods that make circuits/assemblers not require power, so I assume it's also not that easy.

I linked to one in the second post of this thread. It's a doddle.

No and always no to suggestions to make the game more trivial. That stuff is for mods.

[Optymistyk]

I linked to one in the second post of this thread. It's a doddle.

Oh well in that case I guess I'm gonna go ahead and install it.

[Koub]

But Vanilla should only do what's most sensible from the gameplay perspective.

The fact that there have been so few reports/complaints/suggestions on this particular subject until very recently would make me inclined to think that only a handful of people have been bothered by that 'maybe not so intuitive' behaviour. My intuition is that the overwhelming majority of players don't give a f*ck about this. There are other areas of the game where an improvement would be appreciated by a significantly bigger part of the playerbase.

I'm sure it's incomparably easier to mod something designed to consume energy to stop doing so than it is to do the reverse.
[Edit] Seems so.

[Optymistyk]

But Vanilla should only do what's most sensible from the gameplay perspective.

The fact that there have been so few reports/complaints/suggestions on this particular subject until very recently would make me inclined to think that only a handful of people have been bothered by that 'maybe not so intuitive' behaviour. My intuition is that the overwhelming majority of players don't give a f*ck about this. There are other areas of the game where an improvement would be appreciated by a significantly bigger part of the playerbase.

I'm sure it's incomparably easier to mod something designed to consume energy to stop doing so than it is to do the reverse.
[Edit] Seems so.

Yeah to be honest it never seemed like a massive problem to me, certainly not as big as OP is making it out to be. Honestly I'd consider it to be more of a QoL improvement. Still, I just think it makes more sense and probably doesn't require much work at all, just changing a few variables in the code to 0. But if not, well, that's okay too. There's this sweet mod I just installed that does this anyway

[Theikkru]

That's, uh, sort of what this suggestion is about? I dunno why the OP titled it as they did,[...]

This is why ￬

I mean, you can win the game without ever placing a single combinator. So much for it being a "noob trap".

OP is just embarrassed because they built something elaborate that rested on a pulse mechanism like the Princess and the Pea, but forgot that combinators need power, so they've charged in here suggesting "bad game design". The devs have said that this logic isn't changing. There is no "problem". It's up to you to change, not the game.

Can we please keep at least a couple of learning points and barriers in this game before it becomes pure tapioca.

People keep coming up with these strawman arguments that completely ignore everything I've addressed already. Nowhere did I say that newer players WILL encounter this problem, only that they are far more likely to, and they are least likely to be able to diagnose it. That is bad game design. In the previous thread everyone agreed that cases between different electrical networks could stay the same, so the problem wouldn't even be removed from the game. Further, I showed multiple times exactly how to work around this problem, and demonstrated how those solutions are either trivial or redundant and therefore uninteresting. Another sign of bad game design. This just proves my entire point in the Objection 1 section up top.

[...]And at the same time I think the whole stuff is completely logical and if someone cares just for 10 seconds she/he will see the problem.

Please explain to me how someone can even hope to figure out this problem when it won't even manifest consistently for 10 seconds. It's far more likely that said someone will conclude something completely incorrect if they cannot reliably reproduce the problem.

It’s a computer game and if they are not difficult they make no fun.[...]

The logical converse is not true. Being difficult does not imply that something is fun.

So: no reason to kick another feature for that.

I ask again. Which feature is getting kicked?

Well if I try running my CPU at 50% power it's probably not gonna run properly so... Yeah.
[...]

If you try to run your computer at 50% power, it won't boot. That is much much better than producing all sorts of garbage outputs. Even in real life, fast fail behavior is far preferable to intermittent and erratic behavior for the exact same reasons.

[...]
No and always no to suggestions to make the game more trivial. That stuff is for mods.

You have yet to show how either the proposal or the easy fix in the first post would make the game more trivial.

The fact that there have been so few reports/complaints/suggestions on this particular subject until very recently would make me inclined to think that only a handful of people have been bothered by that 'maybe not so intuitive' behaviour. My intuition is that the overwhelming majority of players don't give a f*ck about this. There are other areas of the game where an improvement would be appreciated by a significantly bigger part of the playerbase.
[...]

I described in detail how the erratic and intermittent nature of this problem, coupled with the way it affects less experienced players more, combines to create a situation where players would be unable to find, diagnose, or even reproduce the problem. How would a newer player make a report or post on behavior they cannot even reproduce or identify?

I also don't see why this topic is now in outdated, since neither the proposal, nor the easy fix have been directly addressed.
The proposal, especially, has the potential to optimize the game in very interesting circumstances, and everyone seems to have completely ignored that as well.

[Koub]

I described in detail how the erratic and intermittent nature of this problem, coupled with the way it affects less experienced players more, combines to create a situation where players would be unable to find, diagnose, or even reproduce the problem. How would a newer player make a report or post on behavior they cannot even reproduce or identify?

Usually, this results in bug reports ("things don't work"), before being re-qualified as "not a bug", "Suggestion", or "Gameplay Help" depending on OP's wording and the dev/moderator who is involved. And it's not only my experience as Factorio forum's moderator, but also as a IT support engineer for almost 20 years. People almost always assume they do things right and what's happening is a bug/incident, even when things behave like they have been explicitly designed for.

Or, sometimes, people will post in gameplay help ("Can't wrap my head around this thing"), or show your creations ("I noticed things behave in an un intuitive way, and I worked around with that clever trick").

[Theikkru]

Usually, this results in bug reports ("things don't work"), before being re-qualified as "not a bug", "Suggestion", or "Gameplay Help" depending on OP's wording and the dev/moderator who is involved. And it's not only my experience as Factorio forum's moderator, but also as a IT support engineer for almost 20 years. People almost always assume they do things right and what's happening is a bug/incident, even when things behave like they have been explicitly designed for.

Or, sometimes, people will post in gameplay help ("Can't wrap my head around this thing"), or show your creations ("I noticed things behave in an un intuitive way, and I worked around with that clever trick").

Exactly, but if a player encounters a problem like this and they cannot reproduce it, they can't make a bug post because they have nothing to show. Conversely, if a player does not yet fully understand the normal behavior (i.e. "can't wrap head around" stage), then erratic problems like this will simply throw a wrench in the learning process, and again won't turn up in a post because the behavior is not reproducible. In order for any sort of report to come out, the problem has to be reproducible. My point is that the ones most likely to have the knowledge to do so are the ones least likely to encounter the behavior.
The rake handle metaphor I saw in the last thread is a great comparison. If someone steps on a rake and gets smacked in the back of the head by the handle, telling a friend that "someone hit me in the back of the head" is useless if they did not see the rake and can't show it happening again when they walk around in the lawn. If the rake is hidden by leaves and the person doesn't know what to look for, they are surprisingly likely to conclude something absurd like "my neighbor did it".

[valneq]

I described in detail how the erratic and intermittent nature of this problem, coupled with the way it affects less experienced players more, combines to create a situation where players would be unable to find, diagnose, or even reproduce the problem. How would a newer player make a report or post on behavior they cannot even reproduce or identify?

I also don't see why this topic is now in outdated, since neither the proposal, nor the easy fix have been directly addressed.

I don't see why this is even being talked about.
Whenever your power satisfaction drops below 100%, all your machines slow down proportionally.
The issue you describe only occurs when power drops below ~50%, so your factory runs half as fast as it could.
This alone should be motivation enough to always satisfy your power demands.
Whatever it is you are trying to optimize with combinators, the slowdown will be worse.

Combinators and the circuit network is often one of the last things new players start to really explore, similar to uranium processing.
After all, both these things are entirely optional to finish the game.
By the time people really use combinators, they usually have some experience and learned the lesson that power less than 100% should under all circumstances be avoided.

If you really struggle with power and need a circuit logic that is resilient enough to do that, use the solution you proposed yourself. Let all other people happily use the pulse signals from inserters.

[Theikkru]

I don't see why this is even being talked about.

In summary, it's inconsistent behavior, and it's disproportionately punishing to newer players learning the ropes for no good reason.

Whenever your power satisfaction drops below 100%, all your machines slow down proportionally.

Not true. Combinators are unaffected until 50% power (which is another inconsistency).

The issue you describe only occurs when power drops below ~50%, so your factory runs half as fast as it could.

But this can easily happen intermittently; for instance, you might not notice the factory slowing if you're busy repairing firing laser turrets on the front lines.

This alone should be motivation enough to always satisfy your power demands.

Indeed it should. Which is why having punishing and inconsistent behavior hiding in the wings is ridiculous.

Whatever it is you are trying to optimize with combinators, the slowdown will be worse.

It is not combinators that need optimizing, but other logic devices. At any rate, this is untrue. The side effects of this behavior can easily be worse. A factory can handle a brief slowdown in production due to firing lasers easily, but logic may throw a cog in a crucial production system and starve something critical with just 1 such dip.

Combinators and the circuit network is often one of the last things new players start to really explore, similar to uranium processing.

This is a generalization that is also untrue. Combinators are logistics tech. I myself put off uranium, trains, and most of oil until after I had a good understanding of combinator logic.

After all, both these things are entirely optional to finish the game.

True, but that's not a reason for the behavior to be broken, especially if the fix could make the game so much better.

By the time people really use combinators, they usually have some experience and learned the lesson that power less than 100% should under all circumstances be avoided.

Same generalization as above, and not always true. The always 100% power no matter what is primarily taught by lasers and biter attacks. People who don't paste down laser walls everywhere tend to be a lot more relaxed about power.

If you really struggle with power and need a circuit logic that is resilient enough to do that, use the solution you proposed yourself.

I already have.

Let all other people happily use the pulse signals from inserters.

Neither of my proposed solutions significantly change that.

[foamy]

I couldn't find any mods that make circuits/assemblers not require power, so I assume it's also not that easy.

I linked to one in the second post of this thread. It's a doddle.

No and always no to suggestions to make the game more trivial. That stuff is for mods.

This doesn't trivialize the game, but in any case, you aren't the one making the decision, and you haven't managed to raise any objection worth noting, just a constant repeat of 'but it works this way already, don't change it'.

I described in detail how the erratic and intermittent nature of this problem, coupled with the way it affects less experienced players more, combines to create a situation where players would be unable to find, diagnose, or even reproduce the problem. How would a newer player make a report or post on behavior they cannot even reproduce or identify?

I also don't see why this topic is now in outdated, since neither the proposal, nor the easy fix have been directly addressed.

I don't see why this is even being talked about.
Whenever your power satisfaction drops below 100%, all your machines slow down proportionally.

The thing is -- they don't. That's the basic issue here; combinators slow down, other logic entities do not. While it is of course both possible and desirable to ensure your combinator contraptions have full power at all times through factory design, you'd want to do that anyway if things were changed for consistent behaviour across all logic entities, simply because you'd still want your logic system to respond at full speed. It therefore doesn't remove that particular challenge from the game.

What it does do, in synchronizing the slowdown effect across all logic entities on the same electrical network, is ensure that you can't get different outputs on the same inputs depending on an external factor (power supply). That's the inconsistency that's being targeted here -- the slowdown of the combinators should be sync'd to a slowdown in the signals it is provided from non-combinator logic entities, and a cocomittant slowdown in those signals being processed by non-logic entities.

This would actually make running low on power more punishing in absolute terms because it will make wired inserters, belts, and pumps require full power in order to run their logic at speed. So in that sense it's increasing the gameplay challenge and incentive to maintain consistent, uninterrupted power to critical applications while at the same time correcting a behaviour mismatch between similar entities.

[Optymistyk]

If you try to run your computer at 50% power, it won't boot. That is much much better than producing all sorts of garbage outputs. Even in real life, fast fail behavior is far preferable to intermittent and erratic behavior for the exact same reasons.

You can however, as I said, run a CPU with any power you want. The reason your computer won't boot at 50% is because there are systems in place to prevent it from booting. Your CPU itself has none of those, however. But the reason your computer won't boot at 50% is because someone constructed and programmed it that way. You can make your circuits do something similiar if you really wanted to. Or you can give them a separate power network to make sure they are always at 100%. Or you can just download the mod like me. Point is, there's ways to make it work the way you want it to. I wouldn't consider this a gamebreaking issue and I'm using circuits all the time.

[Koub]

If you try to run your computer at 50% power, it won't boot. That is much much better than producing all sorts of garbage outputs. Even in real life, fast fail behavior is far preferable to intermittent and erratic behavior for the exact same reasons.

You can however, as I said, run a CPU with any power you want. The reason your computer won't boot at 50% is because there are systems in place to prevent it from booting.

Are you really sure of this ?

[NotRexButCaesar]

Maybe combinators should give a low power alert (like roboports do) when not having full power. This seems like the easiest and best solution to me

[NotRexButCaesar]

If you try to run your computer at 50% power, it won't boot. That is much much better than producing all sorts of garbage outputs. Even in real life, fast fail behavior is far preferable to intermittent and erratic behavior for the exact same reasons.

You can however, as I said, run a CPU with any power you want. The reason your computer won't boot at 50% is because there are systems in place to prevent it from booting.

What do you guys mean by “power”? Running at 50% voltage will definitely break some things, but not all. I’m not sure what running it at a low amperage would do: probably also break quite a bit.
(This is probably off topic anyway)

[Theikkru]

The terminology can get a bit ambiguous since Factorio rolls a lot (voltage, amperage, etc.) into one concept of "power" or "electricity" which has a completely different internal representation anyways. The crux of the issue is that the behavior is inconsistent and results in erratic symptoms, which is generally considered a bad thing because inconsistent problems that play hide and seek are a PITA and no fun. (Just take a look through the 1/0 magic bug subforum.) Still, instead of trying to poke holes in the proposed implementations themselves, all these objections seem to be hung up on trying to justify an inconsistent behavior for some reason. I don't get it. Fixing an inconsistency and getting a UPS boost in the process seems like a really good idea to me.

[jodokus31]

I fail to see, why this issue is so important that you guys post text wall after text wall. I rather want the devs to implement truly important stuff and more important, dont trivialize the game in the name of consistency. The behaviour could be accepted as it is like you accept laws of nature.
Don't get me wrong, if the devs find a possibIlity to solve the inconsistency in a reasonable amount of time, im all in. But if they dont im not dying. I just dont want more streamlining like powerless combinators or removing pulse signals.

[foamy]

Maybe combinators should give a low power alert (like roboports do) when not having full power. This seems like the easiest and best solution to me

The issue isn't with combinators having low power though! The issue is with the behaviour of other entities under low power.

[Theikkru]

I fail to see, why this issue is so important that you guys post text wall after text wall.[...]

Because this

if the devs find a possibIlity to solve the inconsistency in a reasonable amount of time,[...]

and more are right here

[...]

The proposal

• Remove the energy buffer from dedicated logic devices (combinators).
• Install corresponding buffers/"logic clocks" on each electrical network instead
• Redirect combinator UI elements that previously showed energy buffer levels to the electric network satisfaction level
• Consolidate calculation of power drain for logic devices on each power network (similar to solar panels)
• Increment the "logic clock" for each network each tick according to the power drain calculation, and use it to determine whether or not logic devices that drew power from that network have power to do logic that tick
• Cause all logic devices that are unable to perform logic due to the "logic clock" state to repeat their previous signals (as combinators do now)
• Optional: consistently apply an additional 1W logic power requirement (to be calculated as described above) to all devices that graphically acquire extra apparatus when linked to a logic circuit

and despite no problems being raised about it, everyone keeps derailing the thread with concerns like this

I just dont want more streamlining like powerless combinators or removing pulse signals.

which aren't even part of the proposed solution.