[0.17] Strange inserter circuit problem - bug or oversight?

[zOldBulldog]

I noticed recently a strange behavior when using a wire between a chest and inserter to limit the content of the chest. It seems to work fine when I first place the design, but later it seems to freeze up and no longer work... even if the chest is empty.

I am not sure if I missed something in my design or if I have discovered a bug. Ideas?
(BTW, I know there are other ways to achieve the job, but I would very much like to stick to the assember-inserter-wire-chest approach as it is cheap and available very early in the game)

Below is a simple example. The left assembler makes beacons, the right one makes copper coils.

inserterBug.png (98.93 KiB) Viewed 3597 times

0eNqVldGOmzAQRX9lNc9YwoSQFvUj+l6tkAGHjAQ2tU12o4h/7zjsIlrchbwg2XiOL9d3zB3KdpC9QeUgvwNWWlnIf93BYqNE6+fcrZeQAzrZQQRKdH4krJVd2aJqWCeqCyrJEhgjQFXLd8j5GG0iUFlpnDSLsmRHmZE1e0MjF2WHHWWtbtA6rFh1kdYx67QRzRKSjq8RSOXQoZwseAxuhRq6klTmfGadBRFm+RH02lKVVn5zIrE0ghvkMbFrElpNrzIv8h9k8iSS8W3mYWY6I5TttXGslK0LQI9BaBqAps9C423m8eswrcnJTCYuPs64lIISCwF6ts7ZihgHzykCQjqj26KUF3FFbfzyCk01oCvoXT0zzmisK1bJu6JxA83MEqYVTKibo69rfOp8oznhu47HsR92vTDC+c3gB4zTCjWJsp7N/YPCv4wm1r58fB3HgAOnveGKgzFIAshve5HJ7rh+/xu5FS++O7I83ur9/8Dj/d5n3nofx98DgYsztuTGdHl8XoSziI+oevbgj90fW0A1f7Ir0nVTVLrvpWGVKFsZag2ePNvNe+w+LOwmyRdBBtRfRISHyIm/hB8Xd774MUXQCtJHcz+Npo/qXj6xLx9tSUuu5PyDcTrEPMtOSXLMxvEPrrRO/Q==

Copy blueprint

[DaleStan]

I suspect your problem is that the inserter is set to any < 100. Set it to beacon < 100 instead.

The any signal really means "any non-zero signal". (After all, if "any < 100" enabled the inserter as long as you had less than 100 red circuits in that chest, you wouldn't be particularly happy.) If you run out of beacons, there are no longer any non-zero signals less than 100, and the inserter will turn off.

[zOldBulldog]

I suspect your problem is that the inserter is set to any < 100. Set it to beacon < 100 instead.

The any signal really means "any non-zero signal". (After all, if "any < 100" enabled the inserter as long as you had less than 100 red circuits in that chest, you wouldn't be particularly happy.) If you run out of beacons, there are no longer any non-zero signals less than 100, and the inserter will turn off.

OK, so "any" breaks if the count drops to 0. But I am only feeding one type of item and it is so much easier to copy/paste an anonymous condition than manually specifying the item every single time.

Which is the correct "anonymous" signal that can be used without specifying the exact item? Is it "everything", or "each"?

[DaleStan]

Try both of them; it won't take you that long.

But I'm guessing neither will do the trick, for the same reason that any doesn't: How do you tell the inserter to enable for zero beacons but not for zero red circuits?

I think you can do it if you add a couple deciders, though: Inserter enabled if G ≠ 1, one decider set to "any > 0"=>"G = 1", and the other decider set to "any < 100"=>"G = 1". Connect the chest to the decider inputs and the inserter to the decider outputs.

[zOldBulldog]

Try both of them; it won't take you that long.

But I'm guessing neither will do the trick, for the same reason that any doesn't: How do you tell the inserter to enable for zero beacons but not for zero red circuits?

I think you can do it if you add a couple deciders, though: Inserter enabled if G ≠ 1, one decider set to "any > 0"=>"G = 1", and the other decider set to "any < 100"=>"G = 1". Connect the chest to the decider inputs and the inserter to the decider outputs.

I understand the reason you give to explain why it fails. And will definitely test the other two.

Still, this is starting to stink of "bug", or at the very least of horribly sloppy and flawed design.

Throughout my life I coded in almost a dozen programming languages, and in all of them "X < 100" would be true when X is zero, no matter how abstract the definition of X. Making the condition false just because X isn't around... is beyond absurd. The simple fact of X being zero should make all of the X < N conditions true, both generic and specific.

But let's hope that at least one of the other generic implementations works.

[DerGraue]

If anything would work how you think it should work then "anything < n" with "n > 1" would always be true, simply because you will never have all signals of the game on that wire. I do not see how that is an oversight, a bug or a flawed design.

Everything will work.

[zOldBulldog]

If anything would work how you think it should work then "anything < n" with "n > 1" would always be true, simply because you will never have all signals of the game on that wire. I do not see how that is an oversight, a bug or a flawed design.

Everything will work.

Inserter wire plus multiple combinators is much too complex a band-aid to setup a simple limit. Complexity is fine for other uses, but not this particular use.

Seriously, this isn't a matter of me just not liking it. It is a matter of basic logic algorithm theory, as would be covered even in a beginner course. A "anything < N" condition just needs to include "anything = 0" in its "true" result set as zero is less than N.

No amount of rationalizing is going to make not including it any less of a flaw. It is simple math and logic theory. It really should not matter that you don't have a signal to compare it to.

[DerGraue]

Let's say it works as you say. There are always all the "0" signals on every wire.

Let's say you wire it up like you did in your blueprint. Now you reach more than 100 items in your chest.
The inserter should now disable, right? Cause there are more than 100 items in your chest.

This will not happen, the inserter will stay enabled because there are all the other signals that equal 0, which is smaller than 100. So the inserter stays enabled.

How would that help you?

In your particular case if you use "everything" it will work just fine, so why do you complain? There is no need to "band-aid with multiple combinators", whatever that means.

Btw, the same limitation applies to "everything" as well. Let's say you have some kind of setup where you want to output or enable something if one or multiple signals are larger than "N". With your logic this would never be true. Because there will always be a "0" signal on the wire, so there will never be a case "everything" > 0.

[zOldBulldog]

Let's say it works as you say. There are always all the "0" signals on every wire.

Let's say you wire it up like you did in your blueprint. Now you reach more than 100 items in your chest.
The inserter should now disable, right? Cause there are more than 100 items in your chest.

This will not happen, the inserter will stay enabled because there are all the other signals that equal 0, which is smaller than 100. So the inserter stays enabled.

How would that help you?

In your particular case if you use "everything" it will work just fine, so why do you complain? There is no need to "band-aid with multiple combinators", whatever that means.

Btw, the same limitation applies to "everything" as well. Let's say you have some kind of setup where you want to output or enable something if one or multiple signals are larger than "N". With your logic this would never be true. Because there will always be a "0" signal on the wire, so there will never be a case "everything" > 0.

You are not understanding and are thinking it backwards.
- The premise is that "no signal" is *equivalent* to a signal with a zero quantity when evaluating X < N.
- There is no actual zero signal on the wire unless you generate such a signal intentionally.

So:
- If the chest is empty, no signals have a value, the equation is 0 < 100, true, the inserter is enabled.
- If you get 100 items of an item and there is no other signal, the equation is 100 < 100, false, the inserter is disabled.
- If you have 100 beacons in the chest and 5 lamps, the lamps make it true, inserter enabled.
- If you have 100 beacons in the chest, and a wire from somewhere else with a signal lamp = 0, that existing additional signal gets evaluated as 0 < 100, inserter enabled.

This is how logic equations really work, and how they would be applied to the conceptual problem. If done right they still let you solve every design. It isn't implemented this way... that is a clear flaw.

And yes, we can always do something hokey to cope with a bad design choice, we are used to doing it in Factorio, but it still does not make the existing behavior "correct".

[DerGraue]

[...]
- There is no actual zero signal on the wire unless you generate such a signal intentionally.
[...]
And yes, we can always do something hokey to cope with a bad design choice, we are used to doing it in Factorio, but it still does not make the existing behavior "correct".

The game does not work that way, there is no zero signal. Maybe you want it to work that way, but it just does not work that way.
I am quite sure there is a good reason why there is no zero signal, probably a performance reason, maybe a usability reason, I don't know.

And how is it hokey? Please explain that to me. You can literally use your own design, change one thing on the inserter and it will work.

[DaleStan]

No amount of rationalizing is going to make not including it any less of a flaw. It is simple math and logic theory. It really should not matter that you don't have a signal to compare it to.

Simple math and logic: I have no signals. Therefore I have no signals less than 100.
How do you get from "I have no signals" to "I have at least one signal that is less than 100"? Other than "I really really really want it to work that way", of course.

[AsherMaximum]

Instead of 'Anything", use "Everything". "Anything" sends false if there are no signals, "Everything" sends true if there are no signals.

However, if there are other things in your chest that there is >100 of, this would cause the signal to be false, whereas with "Anything", the signal would still be true.

[zOldBulldog]

Instead of 'Anything", use "Everything". "Anything" sends false if there are no signals, "Everything" sends true if there are no signals.

However, if there are other things in your chest that there is >100 of, this would cause the signal to be false, whereas with "Anything", the signal would still be true.

This is the correct answer. Everything behaves like normal math (confirmed by a DEV on a different thread). Thanks.