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

[NotRexButCaesar]

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

maybe have inserters give a low power alert too? (to let people know that it is a problem)

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

Are you really sure of this ?

/offtopic
Yeah, of course. The CPU does not decide how much power it gets. It takes whatever voltage the motherboard supplies it with. That's why you can change CPU Voltage (VCore) in BIOS settings (BIOS is on the motherboard).
/offtopic

[foamy]

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

maybe have inserters give a low power alert too? (to let people know that it is a problem)

Inserters do have it (as does every other powered entity, including combinators). That is also not the problem. The problem is something very specific and I don't know why people keep sheering off from addressing it directly: it isn't that things can go to low power and it isn't that logic slows down when you go to low power, it's that you can make 1 = 0 in low power logic.

[NotRexButCaesar]

Inserters do have it (as does every other powered entity, including combinators).

You are mistaken. I mean a "low power", not a "no power" warning. It looks like a red battery, not an electric arc (shown on empty accumulators). I think it would help with the problem, as the warning signals to the player that the combinators will not function properly

[jodokus31]

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.

That's not derailing, it's a valid concern. Esp. because you propose that kind of dumbing down as fallback solution, if your proposal doesnt get implemented.
I think your intent is obvious, now let the devs decide whats the best solution
Im out. Good luck

[foamy]

Inserters do have it (as does every other powered entity, including combinators).

You are mistaken. I mean a "low power", not a "no power" warning. It looks like a red battery, not an electric arc (shown on empty accumulators). I think it would help with the problem, as the warning signals to the player that the combinators will not function properly

Oh, I see what you mean now, I think. That'd be interesting. On most devices a low-power situation's obvious because the animations obviously run slower, but for more fixed entities like combinators (or pumps, whose animation is much more subtle and can be slowed by other factors) a low-power overlay indicator could be useful. You could even included on assemblers et al, just for consistency of application.

But while it's a neat UI tweak I don't think it really addresses the root cause, particularly since the situation that would be most desireable to troubleshoot would be an intermittent issue.

[MEOWMI]

Why would you have 50% satisfaction? I could understand it if it was a bug that happened frequently when you have random, instantaneous dips in power, but it sounds like you're consistently sitting on very low power (considering the baseline is 100% satisfaction).
[...]

Power can easily crash from 100% down below 50% intermittently due to things like sudden bot use from construction or logistical orders, or laser turrets firing.

It can happen, but in most cases you should consider that a major problem. You don't want to run low on power ever. Being that close to it is already low power in disguise, and it should already be a point where you're worried about expanding power production.


Regarding the topic of the pulse itself, I think your best bet is to build a convincing argument for it to be fixed. The pulse function will almost certainly not be removed, that's kind of a ridiculous proposition. It's almost like asking nuclear power to be removed because it's relatively UPS costly. You do realize your suggestion is a double-edged sword? You'd be removing a useful and widely used feature for a very minor fix, and that's not even mentioning the issue that hundreds or thousands of players already use this feature in their existing builds.

Furthermore, regarding circuits, there are far more pitfalls that beginners will face than this particular issue. I've never heard anyone talk about this issue previously but there are certainly a hundred other things circuit beginners have asked for help with. It just doesn't seem like a good solution to try to start removing features like that without a proper understanding of the picture at large. Overall, there's so much that can go wrong when you design a circuit, it really is a world of its own along factory building.

[Theikkru]

[...]
That's not derailing, it's a valid concern. Esp. because you propose that kind of dumbing down as fallback solution, if your proposal doesnt get implemented.
I think your intent is obvious, now let the devs decide whats the best solution
Im out. Good luck

[...]
Regarding the topic of the pulse itself, I think your best bet is to build a convincing argument for it to be fixed. The pulse function will almost certainly not be removed, that's kind of a ridiculous proposition. It's almost like asking nuclear power to be removed because it's relatively UPS costly. You do realize your suggestion is a double-edged sword? You'd be removing a useful and widely used feature for a very minor fix, and that's not even mentioning the issue that hundreds or thousands of players already use this feature in their existing builds.
[...]

There is no dumbing down or removal of anything, and I've been trying to build a case for that this whole time; the fix is right here:

I see no reason unsuspecting players should be lured into using a flawed implementation of a pulse function with potentially disastrous consequences when they could instead be encouraged to reproduce a reliable version so trivially:

fixed.png (477.98 KiB) Viewed 5256 times

Even the "easy fix" can't be called a "removal" if it's still in the game, and it's certainly not a "dumbing down" if players actually have to figure out the general implementation of pulses instead of just clicking a toggle button. Regardless, as I've been saying the whole time, the "easy fix" was mostly a rhetorical device to point out the absurdity of the situation (that the general implementation doesn't suffer from broken behavior while the supposed "convenience feature" does).

It can happen, but in most cases you should consider that a major problem. You don't want to run low on power ever. Being that close to it is already low power in disguise, and it should already be a point where you're worried about expanding power production.
[...]

While you can make the case that players should fix their power in general, my point was that it's easy for power dips to go unnoticed if it's intermittent, especially for less experienced players, and the inconsistency wouldn't help with that at all; it would just throw a monkey wrench in the logic somewhere and randomly cause trouble later, likely long after power is back to full. As a problem solving device, that is miserably bad design.

[...]
Furthermore, regarding circuits, there are far more pitfalls that beginners will face than this particular issue. I've never heard anyone talk about this issue previously but there are certainly a hundred other things circuit beginners have asked for help with. It just doesn't seem like a good solution to try to start removing features like that without a proper understanding of the picture at large. Overall, there's so much that can go wrong when you design a circuit, it really is a world of its own along factory building.

The big difference between all other potential pitfalls and this inconsistency, is that they are persistent and reproducible, and ergo easily identifiable. A problem that stares you in the face is one you can work through and solve. Also:

[...]

To be honest, circuits are not noob friendly to begin with. I have a lot of experience with similar systems both in other games and outside of games, and yet it still took even me a long time to wrap my head around all the crazy stuff involved.

This is all the more reason to remove confounding factors like an undocumented inconsistency in behavior that can unexpectedly and intermittently break all sorts of logic and trash attempts at learning in the process.[...]

Most importantly, still, no one has found any objection to the full proposal at all:

If at all possible, however, the following proposal would be superior, as it includes the side benefit of helping optimize the game's performance, especially for complex and interesting logic creations like Facto-RayO:

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

I'm flabbergasted that this idea keeps getting locked away (last thread), thrown out (this thread), and otherwise ignored despite the fact that no one has pointed out anything wrong with it.

[MEOWMI]

The main proposal does seem to have some merit, but it involves a lot of changes, which makes it harder and thus less likely, all for fixing a small problem which further makes it all the less likely. You would probably want to motivate and explain it in more detail but I suspect that's not an easy thing. Even Boskid mentioned implementation difficulties which is just one of the many things that would have to be addressed.

As for this forum thread, the main problem I see is that you frame it as a noob trap, which is quite misleading, plus the post itself proposes too many things, and the thread title itself suggests a different, quite radical change.

I will say, it is nice that you posted a picture of a solution that players can make, if they run into this issue. Hopefully it doesn't get buried, for people who actually do come to these threads potentially looking for a solution.

[ptx0]

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

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

how will newer players encounter this problem? I've hung out on Factorio discord for a long time, and something I have observed is that "noobs" avoid circuit network (CN) like the plague because they just don't need / want its complexity - let alone using "pulse" readings. personally, I have barely started using that feature even after 5800h in-game.

they're the least likely to run into this problem.. and if they do, it's likely because they imported a blueprint that they didn't understand.

[Theikkru]

The main proposal does seem to have some merit, but it involves a lot of changes, which makes it harder and thus less likely, all for fixing a small problem which further makes it all the less likely. You would probably want to motivate and explain it in more detail but I suspect that's not an easy thing. Even Boskid mentioned implementation difficulties which is just one of the many things that would have to be addressed.

I've tried to provide as much detail as I can, and both in the last thread and here (Objection 2) it was clearly noted that boskid's comment didn't actually apply to the proposal. The first page of this thread had some pretty relevant conversation to that effect, but the more detail and context I provide, the more I've seen this bizarre tendency for people to get hung up on tangential things and completely lose sight of the actual proposal.

As for this forum thread, the main problem I see is that you frame it as a noob trap, which is quite misleading[...]

How is this misleading? Starting in the Objection 1 section of the main post and continuing throughout the thread, I've described how this inconsistency disproportionately affects "noobs" who are less familiar with or less diligent about keeping their power up, and how it can unexpectedly smack them upside the head without them being able to even identify what got them, a.k.a. a "trap".

[Theikkru]

how will newer players encounter this problem? I've hung out on Factorio discord for a long time, and something I have observed is that "noobs" avoid circuit network (CN) like the plague because they just don't need / want its complexity - let alone using "pulse" readings. personally, I have barely started using that feature even after 5800h in-game.

they're the least likely to run into this problem.. and if they do, it's likely because they imported a blueprint that they didn't understand.

A lot of "noobs" also avoid trains, oil, and uranium like the plague, at least until they have good cause to make use of them. That doesn't change the fact that at some point, anyone who is going to use any of these features is going to have to learn about them, and at that point they would be considered a "noob" in that respect, trying to learn the ropes. My arguments are centered around how the inconsistency affects players who are making this attempt, not those who simply avoid the feature in question altogether. Again, a "noob trap" doesn't have to catch all "noobs" to be a problem.

[ptx0]

How is this misleading? Starting in the Objection 1 section of the main post and continuing throughout the thread, I've described how this inconsistency disproportionately affects "noobs" who are less familiar with or less diligent about keeping their power up, and how it can unexpectedly smack them upside the head without them being able to even identify what got them, a.k.a. a "trap".

and people have disagreed repeatedly. not diligent about power but uses circuit network pulses heavily? lies.

[Theikkru]

and people have disagreed repeatedly. not diligent about power but uses circuit network pulses heavily? lies.

No, the correct conditions are "not 100% diligent about power and uses the pulse function on inserters at all". Pulses on the network in general aren't a problem if they come from combinators. Are you going to tell me that once past what you call the "noob stage", players NEVER allow their power to dip below 50% at all throughout any given playthrough? People aren't that perfect.

Besides, the operative word here is "trap", not "noob". Would it clear up the confusion if I called it a "booby trap" instead? The argument is not "this problem will affect so many people plz halp", it's "this problem is erratic, inconsistent behavior which is bad and btw is more likely to affect newer players, here is a way to fix this, is there anything wrong with this idea".

P.S. I'd like to remind everyone that the proposal could also improve UPS. Everyone keeps glossing over that bit too, but if anything, I'd think that could be the strongest case for implementing the proposal.

[ptx0]

and people have disagreed repeatedly. not diligent about power but uses circuit network pulses heavily? lies.

No, the correct conditions are "not 100% diligent about power and uses the pulse function on inserters at all". Pulses on the network in general aren't a problem if they come from combinators. Are you going to tell me that once past what you call the "noob stage", players NEVER allow their power to dip below 50% at all throughout any given playthrough? People aren't that perfect.

no, that's not what anyone is telling you - they're saying instead that the problem is the lack of power. and then you tell us that no one is listening to you. we're listening. we just disagree.

[foamy]

and people have disagreed repeatedly. not diligent about power but uses circuit network pulses heavily? lies.

No, the correct conditions are "not 100% diligent about power and uses the pulse function on inserters at all". Pulses on the network in general aren't a problem if they come from combinators. Are you going to tell me that once past what you call the "noob stage", players NEVER allow their power to dip below 50% at all throughout any given playthrough? People aren't that perfect.

no, that's not what anyone is telling you - they're saying instead that the problem is the lack of power. and then you tell us that no one is listening to you. we're listening. we just disagree.

Yeah, but they're wrong. The lack of power isn't the problem.


The fact that things respond differently to losing power is the problem. Combinators slowing down in low power conditions is fine, traceable, and a failure mode that encourages being diligent about your power planning. Those are good things!

Other logic entities not doing so is bad. It introduces inconsistencies with the inputs and outputs of combinators for no reason. The proposed fix -- not the headline used to get people to pile into the thread and which is very obviously revealing who bothered to read to the end and who did not -- may simplify the power calculations for a given electrical grid, resolve that inconsistency, increase the design challenges of circuitry because now you have to make sure every logic entity has power, not just the combinators, and retain the current behaviour of combinators slowing under low power.

But there's a lot of 'well just build your factory better' coming back, instead of consideration of the actual suggestion. It's thought-terminating nonsense and it's getting my goat.

[ptx0]

But there's a lot of 'well just build your factory better' coming back, instead of consideration of the actual suggestion. It's thought-terminating nonsense and it's getting my goat.

well the thread is in "Outdated/Not Implemented", so there's that.

the proposal decides there's an issue just because inserters don't behave like combinators, combinators miss the pulse outputs during low power condition. this is because of poor base design - no real question about it.

inserters have odd behaviour - they will drop an item into a cargo wagon while powered off. they are weird. that's all.

[foamy]

well the thread is in "Outdated/Not Implemented", so there's that.

Yeah, I know, but I think it was put here without proper consideration, probably because OP presented it a bit poorly out of frustration.

I think the actual suggestion, buried behind the spoiler cut in the OP, is a good one. It adds the good kind of challenge to the game (that of applying creativity to solve a problem), could aid UPS, and fixes a behavioural inconsistency along the way. And since the devs have recently been talking about how they have knocked off all/almost-all of the bug reports, it isn't like there's that many higher-priority projects out there for them to work on, either :p

[Theikkru]

[...]
the proposal decides there's an issue just because inserters don't behave like combinators, combinators miss the pulse outputs during low power condition. this is because of poor base design - no real question about it.

inserters have odd behaviour - they will drop an item into a cargo wagon while powered off. they are weird. that's all.

My proposal is about a way to make inserters (and other logic devices) be less weird and inconsistent, so why such strong fight against it? Even if I swallow your position that suffering from it can only be a result of bad base design, (and for the record I don't,) I've shown time and time again that having this weird and inconsistent behavior adds nothing to the game, and time and time again I show different ways it can cause all sorts of aggravating problems, and I've even come up with a solution to it, yet somehow "just fix ur power" justifies keeping an inconsistency around? I already addressed this argument way back in the Objection 1 section of the main post, yet you're here repeating the same argument without answering any of my refutations. If you can show me problems with my actual suggested solution, or reasons BESIDES those I've already addressed that changes should or should not be made, then I'm all ears, but repeating a bad argument does not make it any better.

[ssilk]

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.

Being simple also. Especially a computer game for nerds.