[Twinsen] [16.7] Circuit Network on belts

[FuryoftheStars]

Hi, not sure if this has been reported... searching around I haven't seen it, so apologies if I missed it.

In this situation, use a circuit wire to connect two belts, set one to "Read belt contents" and mode to "Hold", then set the other belt to "Enable/disable" and the enabled condition to Everything (asterisk with red background) is greater than or equal to 6 (other values could probably be used, but this is my usage case). In 0.15, if the belt set to read had nothing on it, the other connected belt would be disabled. In 0.16 (and I've tested in the latest 0.16.7), the other connected belt remains enabled until at least one item passes through the reading belt. As soon as this item finishes passing, the other connected belt is re-enabled. It's as if when nothing is on the belt, it's counting the empty slots. The other connected belt does properly enable when the reading belt's contents hit the condition threshold, still, it's only when the reading belt is empty when it's not performing as expected.

I can get around this by using the Anything (asterisk with green background) condition, but this doesn't work for my needs on mixed content belts. I am unsure if the Everything condition is affected in other areas or if it's just on belts.

I disabled all mods to be sure this wasn't a cause.

[Koub]

Hi,

Would you please include a save with the illustration of what you're reporting and/or a screenshot with a few labels ? It would help figure exactly what's wrong .

[FuryoftheStars]

Hi, sorry, I don't have any good saves currently to illustrate this and not sure a screenshot could properly show it, either (would need a short video of it and I don't have anything to make such a thing with). I can attempt tonight to make a good save, but realistically it may be a few days (work and other obligations).

It can easily be reproduced using the Sandbox scenario to enable cheat mode and enable all tech, then lay out two separate lines of belts and connect one belt from each line as described above. You'll see the belt with the enable/disable condition continue to be enabled even though there are no items on the reading belt (not expected behavior). Then if you drop an item onto the belt line that has the read belt, while that item is passing through the read belt you'll see the enable/disable belt stop and become disabled (expected) until it finishes passing through, then the belt becomes enabled again (not expected).

Hope that helps.

[quyxkh]

blueprint

0eNqdVl2voyAQ/S88641g7YcP+0c2N4bqtCVBMIC92zT+9wW9a7u9NB371MrAOWfOAMOV7GUPnRHKkfJKRK2VJeXvK7HiqLgMY+7SASmJcNCShCjehi9nuLKdNi7dg3RkSIhQDfwhJR2Sl4tBQu2MqFNQYI6X1JODOfAa7nDY8JkQUE44AZOi8eNSqb7dg/FECLiEdNp6BK2CFo+aZh9FQi7+D/0oPFkjjF87xtdB+AMHmzlsy6VMZ6ZOyxh6PmJnQwQqXwbFniOtZiShLBifa0TJalzPXqdY4NHoa7T1HdpBKB9K6xNYF8EsZoX/plYWnBPqaMMUA60+Q9X7mPSioKnCHvKhA5cWYr5slnLT97gTMg1Pu/Kb0vCv9EvrxpPVug+HiWZZQlrdhCh3qQQ+SpmPyWcsh+2zA/YzBxarMAv0yhktqz2c+FloE+bXwtS9cJWPNTPIQRjrqh9H9SyM6/3Ibb+OM1I4g7m4k/conNJwTzge8lyHj7bjhrtARn6N4W9CUHwvoWqEDb+kdKaHW9QAb6oTV00Q5rwVN4vvFI+Bae5kZzbxqynpsWJ0Kltzf1GIJhQh+Bwxeoc3Oo8aHcGk2dLq0UXVezTzwaqYm//7HTOT4s3cPvGS0qVmUoSZDA2aoQuU44VSNOhqoVBM8sVSoRjQNRqUoZPfoDHxhm4X6sTkvluoE4HJMkTrzLF9mFE0GqIPM4Zuhqs3+3C4WmK3AcsXUtM3qf37cHxWlndP2IT4LmUnW7YbutvlxWrHhuEvPvW7yA==

That shows it. No signal ever exceeds 6, so don't see how "Everything > 6" could or should ever evaluate as "true".

edit: OP, as a workaround, would switching to "Anything > 6" work? That behaves properly here, if you're not running a sushi belt I'd think that'd serve.

[FuryoftheStars]

OP, as a workaround, would switching to "Anything > 6" work? That behaves properly here, if you're not running a sushi belt I'd think that'd serve.

It does and that's what I'm currently doing, but yeah, if I have a mixed belt this would fail.

[FuryoftheStars]

Ok, I've had a few minutes to create a save. In this setup, I have two belt loops. The upper loop has the "read" mode belt, while the lower loop has the "Enable/Disable" belt with the condition set for Everything is greater than or equal to 6. The upper "read" loop as 30 items on it placed such that 20 are in one lane and 10 are in the other. This makes it so that when they start passing through the reading belt segment, the lower belt segment should properly evaluate this as True and enable. Then, once the first 20 items pass through, this should leave only 1 lane's worth of items to pass, causing the lower belt to evaluate this as False and disable. This all works properly. Where the fault comes in is once all the items have passed and the reading belt segment is empty, the lower belt segment now erroneously evaluates this condition as True and re-enables.

Changing the Everything condition to Anything will result in proper expected behavior (the lower belt will remain disabled while nothing is on the upper reading belt), but for in game usage, this condition will fail if the belt is carrying a mixed load (more than 1 item type) which is why the Everything condition is preferred.

As a design note for my setup, the upper loop makes a figure 8 pattern in order to balance out the turns seems the inner track of a corner will move items around faster than the outer track will, thus keeping the items on the belt aligned when they reach the reader. It should also be noted that as a side affect, if you let the items run around the belt for a few minutes, item creep starts becoming apparent.

Blueprint string for used setup

0eNqVlm1ugzAMhu/i36lEUvoBV5kmFIrbRoKAklANVRxgB9nFdpIloFX9YJrzhyiJeeyE18ZXKOseO6O0g/wK6tBqC/nbFaw6aVmHNTd0CDkohw0w0LIJM2ektl1r3KrE2sHIQOkKPyDn4zsD1E45hTNpmgyF7psSjTf4i8Gga61/rdXBq0etUgaDH7inV8rgYd5LR/YCFdFQ8T90TYeuF6HbBWhKhwoydEOHcjJ0S4YmZOaOzKTHuScz6ReakZn0L88TMjSlQ3kslI9LmOgESh5jE0vQdazWKdA0Nisp0OgEokBjE+iZycBXY2fauijxLC+qNcH8oMyhV65ALcsai0rZMEJ+lLVFdts2KKviLHVVBIgPzRdjZ/o7i9/12bRpKwzVe3Kq5xhs8MfDw2B1X8uVnwlf6cdFLe0iE5Jyl/vIwkFhZpGpkyydViSRpYIQmeCRyhFRyvF71Y1xVMa64uVvf1HG9X7lFshsscILmsGdlT7BLBXrZGgdtmHSdNJIF5zB9+fXZPCHWB+VuKTVJzkviTWhi5VvJ7H61mRqY/K7roeBP5KdC+x+x7NsvUkzMY4//+wXsw==

3 Screenshots of setup in action

Everything condition on belts - Screenshot 1.jpg (509.28 KiB) Viewed 4299 times

Everything condition on belts - Screenshot 2.jpg (509.83 KiB) Viewed 4299 times

Everything condition on belts - Screenshot 3.jpg (508.54 KiB) Viewed 4299 times

I've also had a chance to use the Everything condition in other setups (combinators, programmable speakers, etc) and so far those all appear to work as expected. So, it just seems like it's when used on a belt itself that it's flaking out.

[golfmiketango]

Ok, I've had a few minutes to create a save. In this setup, I have two belt loops. The upper loop has the "read" mode belt, while the lower loop has the "Enable/Disable" belt with the condition set for Everything is greater than or equal to 6. The upper "read" loop as 30 items on it placed such that 20 are in one lane and 10 are in the other. This makes it so that when they start passing through the reading belt segment, the lower belt segment should properly evaluate this as True and enable. Then, once the first 20 items pass through, this should leave only 1 lane's worth of items to pass, causing the lower belt to evaluate this as False and disable. This all works properly. Where the fault comes in is once all the items have passed and the reading belt segment is empty, the lower belt segment now erroneously evaluates this condition as True and re-enables.

Changing the Everything condition to Anything will result in proper expected behavior (the lower belt will remain disabled while nothing is on the upper reading belt), but for in game usage, this condition will fail if the belt is carrying a mixed load (more than 1 item type) which is why the Everything condition is preferred.

As a design note for my setup, the upper loop makes a figure 8 pattern in order to balance out the turns seems the inner track of a corner will move items around faster than the outer track will, thus keeping the items on the belt aligned when they reach the reader. It should also be noted that as a side affect, if you let the items run around the belt for a few minutes, item creep starts becoming apparent.

Blueprint string for used setup

0eNqVlm1ugzAMhu/i36lEUvoBV5kmFIrbRoKAklANVRxgB9nFdpIloFX9YJrzhyiJeeyE18ZXKOseO6O0g/wK6tBqC/nbFaw6aVmHNTd0CDkohw0w0LIJM2ektl1r3KrE2sHIQOkKPyDn4zsD1E45hTNpmgyF7psSjTf4i8Gga61/rdXBq0etUgaDH7inV8rgYd5LR/YCFdFQ8T90TYeuF6HbBWhKhwoydEOHcjJ0S4YmZOaOzKTHuScz6ReakZn0L88TMjSlQ3kslI9LmOgESh5jE0vQdazWKdA0Nisp0OgEokBjE+iZycBXY2fauijxLC+qNcH8oMyhV65ALcsai0rZMEJ+lLVFdts2KKviLHVVBIgPzRdjZ/o7i9/12bRpKwzVe3Kq5xhs8MfDw2B1X8uVnwlf6cdFLe0iE5Jyl/vIwkFhZpGpkyydViSRpYIQmeCRyhFRyvF71Y1xVMa64uVvf1HG9X7lFshsscILmsGdlT7BLBXrZGgdtmHSdNJIF5zB9+fXZPCHWB+VuKTVJzkviTWhi5VvJ7H61mRqY/K7roeBP5KdC+x+x7NsvUkzMY4//+wXsw==

3 Screenshots of setup in action

Everything condition on belts - Screenshot 1.jpg

Everything condition on belts - Screenshot 2.jpg

Everything condition on belts - Screenshot 3.jpg

I've also had a chance to use the Everything condition in other setups (combinators, programmable speakers, etc) and so far those all appear to work as expected. So, it just seems like it's when used on a belt itself that it's flaking out.

Anything of Everything of nothing is always true. That's how it's supposed to work

Sorry that was deliberately confusing for laughs. What I mean is, if you say "Everything > 0" and there's nothing on the wire, then factorio considers this to be true. Likewise, if you say "Everything < 0" or "Everything = 1337". They are all true so long as nothing is on the wire by design, because, there's nothing on the wire to contradict this. Sort of like, if you said, "All of my money is in the stock market" and you don't have any money, you technically have not lied, just sort of exploited a "degenerate" corner of truthiness.

So that seems, with all due respect, FuryOfTheStars, like a misunderstanding on your part, but not a game-engine problem.

But, if something changed about how identical flows of items on belts caused circuit data to zip around and influence the belts, that is still likely to be a bug, either that was fixed, or created, or, was not fixed but is now replaced by a different bug, in 0.16 I can't load up your blueprint right now due to self-caused technical difficulties to take a look; so, maybe I'm missing something anyhow.

[FuryoftheStars]

Anything of Everything of nothing is always true. That's how it's supposed to work

Sorry that was deliberately confusing for laughs. What I mean is, if you say "Everything > 0" and there's nothing on the wire, then factorio considers this to be true. Likewise, if you say "Everything < 0" or "Everything = 1337". They are all true so long as nothing is on the wire by design, because, there's nothing on the wire to contradict this. Sort of like, if you said, "All of my money is in the stock market" and you don't have any money, you technically have not lied, just sort of exploited a "degenerate" corner of truthiness.

So that seems, with all due respect, FuryOfTheStars, like a misunderstanding on your part, but not a game-engine problem.

But, if something changed about how identical flows of items on belts caused circuit data to zip around and influence the belts, that is still likely to be a bug, either that was fixed, or created, or, was not fixed but is now replaced by a different bug, in 0.16 I can't load up your blueprint right now due to self-caused technical difficulties to take a look; so, maybe I'm missing something anyhow.

Nothing should equate to 0. But if what you say is true, then Anything should operate the same way and it's not.

[Loewchen]

As the wiki and any documentation or topic in the forum about this explains, the Everything signal behaves as universal quantification, and therefore Everything is not true when the first non-match is found. NaB.
Will not move as this is already assigned.

[Jelmergu]

As the wiki and any documentation or topic in the forum about this explains, the Everything signal behaves as universal quantification, and therefore Everything is not true when the first non-match is found. NaB.
Will not move as this is already assigned.

Which means that if Everything is nothing, there are not non-matches found, so Everything is true, which in the case of the last image lets the belt move.

A workaround for the given example
In the example it is solveable by using a arithmatic set to each + 0 => Signal and then the belt to Signal > 6.
I do agree with the OP though that the Everything signal should be changed. When something needs a workaround to work as expected, it clearly doesn't work as expected.

My expectation of Everything is that it is a number that represents the amount of items on the belt/all signals combined. In the mentioned case of the belt you'd be 'saying' to the belt that it should count everything on a belt(Everything) and do something when the count is bigger than 6(Everything>6)

[golfmiketango]

>-% <snip!>
NaB.

>-% <snip!>
When something needs a workaround to work as expected, it clearly doesn't work as expected.

Think of it this way. Deciders test truth of things using values on the wire. Everything, is not a signal. It's instead a shorthand for a special, very strong global test of everything on the wire: are they ALL true? In other words, if any one, or more than one, of the things on the wire does not meet the given criterion, it's false. Otherwise, it's true. The only quirk to bear in mind, being, if the value is zero, that signal is not considered to be on the wire at all.

So, kind of to repeat the above: an equivalent way to state Everything "<blah>" is: of everything on this wire, does any one or more of them fail to meet the criterion "<blah>"? So for example "Everything" = 0 means, for everything on the wire, does any one or more of them fail to meet the criterion "<thing> = 0". And in this particular case, if anything is on the wire, it by definition cannot equal zero, so this particular decider configuration happens to effectively ask the question: "is the wire empty?"

But now imagine if it worked the way you propose. In your proposed arrangement, Everything=0 is false when the wire is empty. But by definition, this is the same thing as everything being zero. Personally, I find the way it works now to be more intuitive in light of the way zero works in combinators.

That stated, to some degree, we have to decide what to do with this everything when there's nothing on the wire and you could go either way. This was what they went with. Either choice leads to some results that some people are going to find counterintuitive. But whatever definition you pick, it is absolutely necessary that Everything be the contrapositive of Anything -- otherwise there will end up being questions that are not ask-able (conveniently) using combinators; so if they had picked "false" as the answer to Everything <X> of an empty wire, they would have needed to replace "Anything" with "Nothing."

Indeed the way it works now, Anything=0 can never be true, even of an empty wire. Which is probably counterintuitive. But the reason is pretty clear once you wrap your head fully around the idea that there is no such thing as a circuit network signal with value zero, hence, if it's zero it's not "any thing" at all.

[FuryoftheStars]

The problem with the current setup is if you have a situation like the one in my OP, where you have two belts connected by wire and you only want the second belt to run when the first one is becoming saturated with goods*, but the goods running on the belts are not all of one type, the Anything condition will fail. Only the Everything condition can properly catch this, but when there's nothing on that first belt, it won't stop the second belt.

*Condition is greater than or equal to a non-zero positive (6 or less works best on a belt, depending on what you consider as saturated). When using a splitter just before these two belt segments, this allows you to shunt goods from the second belt to the first when the first has open space. I believe this is referred to as a priority splitter setup.



IMO, absolutely nothing on the wire should evaluate as an absolute zero, thus technically making Everything = 0 and Anything = 0 evaluate as True. But nothing on the wire should not cause Everything > 6 to still evaluate as true. This is not intuitive.

[Twinsen]

Oh, this Everything vs Anything confusion again. I've added some tooltips to hopefully clarify this subtle difference, since i've moved too many of these bug reports to "not a bug"

They way Everything/Anything/Null signals/zero signals work either work as intended or are confusing depending on what situation it is used in. In this example they are not ideal. But the problem with something as generic as the circuit network is that I can't change it without other players saying that other situations don't work as intended.

[Caine]

The rules of logic state that universal quantifications over an empty domain are true while existential quantifications over an empty domain are false.
Thus an everything (universal) over an empty belt should be true. An anything (existential) over an empty belt should be false.

Phrased differently:
Everything is a forall operation (symbol in logic: ∀). It states: for all elements on the belt, the condition holds. Or equivalently: there are no elements on the belt for which this condition does not hold. An empty belt does not contradict this.
Anything is an there exists operation (symbol in logic: ∃). It states: there is at least one element on the belt which satisfies the condition. An empty belt does not satisfy this.

[Jelmergu]

Oh, this Everything vs Anything confusion again. I've added some tooltips to hopefully clarify this subtle difference, since i've moved too many of these bug reports to "not a bug"

They way Everything/Anything/Null signals/zero signals work either work as intended or are confusing depending on what situation it is used in. In this example they are not ideal. But the problem with something as generic as the circuit network is that I can't change it without other players saying that other situations don't work as intended.

Fair enough, wouldn't be surprised that I would be one of those that would be complaining that something else doesn't work anymore...

Everything is a forall operation (symbol in logic: ∀). It states: for all elements on the belt, the condition holds. Or equivalently: there are no elements on the belt for which this condition does not hold. An empty belt does not contradict this.
Anything is an there exists operation (symbol in logic: ∃). It states: there is at least one element on the belt which satisfies the condition. An empty belt does not satisfy this.

That seems to be the most understandable explanation I have seen as of yet for the everything/anything signal

[FuryoftheStars]

An empty belt does not contradict this.

I think this is the part that's confusing me. How can an empty belt not contradict a comparison of ">6"? On an empty belt, there is nothing that is >6.

[Loewchen]

How can an empty belt not contradict a comparison of ">6"? On an empty belt, there is nothing that is >6.

Everything does exactly NOT ask that! Everything asks: Does a signal exist that does NOT meet the criteria >6, if so return false, else return true. Since there is no such signal it returns true in the case of empty belt.

[FuryoftheStars]

Everything asks: Does a signal exist that does NOT meet the criteria >6

Yes, and "no signal" does not meet the criteria. "No signal" cannot be >6 because there's nothing there. "No signal" / nothing is, essentially, 0.

[Zavian]

I haven't done much with complicated circuit networks, and i don't think I've ever needed to use everything or anything, so I could easily be misunderstanding something, but i'm wondering whether renaming everything to EverySignal would help people understand the concept? Would renaming anything to AnySignal also make sense ?

[Caine]

There is actually a confusing aspect here. There is an implicit signal is nonzero condition.

Everything means: for all non-zero items the condition must hold.
Anything means: for at least one non-zero item the condition must hold.

The factorio developers made the choice to remove zero signals from the network, you cannot even send them over.
There is no way to distinguish between the absence of a signal and a zero signal. This is an arbitrary choice and it would work either way.
Choosing the opposite solution would mean that every circuit network has all the unused signals with a zero value which is confusing too.
Either you show them all, which is messy, or you test on them but do not show them. The latter is harder to debug and can be confusing.

Trying to distinguish between zero and missing is not very intuitive either. Either the user has to manually specify which signal to put on the wire or you would need to do stuff like: if a belt has seen an item of a specific kind at least once it will send a zero signal whenever that item is no longer present, for all other items it will omit the signal all together. So we can choose between cumbersome and non-intuitive.

Thus the real debate is: should all missing signals be interpreted as a zero value instead.
At this point, I am uncertain which is right. I would need more examples and scenarios to argue one side or the other.

<edit>Alternative: allow a constant combinator and an arithmetic combinator which computes a zero to put an actual zero signal onto a wire.
Reading from chests, belts etc... would not produce any zero signals, but by connecting an additional combinator you can force the signal into
the equation.
</edit>
<edit2>I think it would make sense for filtered containers and filtered inserters to also put a zero onto the wire</edit2>