Discuss: Power Switch should not "Blink"

[XKnight]

Nope It works only with Each mode.

Will you explain why, or do I have to find out myself and explain it? It's not obvious to me right now.

You need to be less mysterious and explain more, then people can learn. Showing off is only 50% of the distance covered .

"Blue < A, output A" will put A's value into the output.
while
"Each < A, output A" will convert Blue's value into A.

Example:
Blue=30, A=50
Blue < A, output A => output 50 A
Each < A, output A => output 30 A

[siggboy]

"Each < A, output A" will convert Blue's value into A.

Example:
Blue=30, A=50
Blue < A, output A => output 50 A
Each < A, output A => output 30 A

So, the 0.12 behaviour has not been changed if you use the "Each" virtual signal in the condition? The Decider is supposed to copy the value of the specified output signal from the input, apparently that does not apply if one uses the Each condition. One more quirk to remember.

Sigh.

(XKnight, this is why only a handful of people try to make advanced contraptions, and why you should explain such stuff especially in a thread unrelated to combinator designs. Thanks a lot for posting your design though, I think I'll make a review of the 3 possible designs and post it in the Contraptions thread.)

[XKnight]

"Each < A, output A" will convert Blue's value into A.

Example:
Blue=30, A=50
Blue < A, output A => output 50 A
Each < A, output A => output 30 A

So, the 0.12 behaviour has not been changed if you use the "Each" virtual signal in the condition? The Decider is supposed to copy the value of the specified output signal from the input, apparently that does not apply if one uses the Each condition. One more quirk to remember.

Sigh.

Actually, this is very logical, because only using this behaviour you can calculate sum of different items using decider combinator (input: A,B,C,D output sum of every signal which satisfies given condition).
From the other side what behaviour would you expect?
Input: A=100,B=200,C=300,Blue=20
"Each > Blue, output Blue" => Blue + Blue + Blue = 60 ? this is ridiculous.
"Each > Blue, output Blue" => Blue = 20 ? what is the difference with "Any > Blue, output Blue"
The only logical behaviour is to use each signal's value and calculate sum.

By the way, this stuff is already described here viewtopic.php?p=98325#p98325

Quote

Each
Each is a bit more complicated. Each also performs the test on each input signal, but instead of being true or false once, it gives a true or false result for each one individually.

Take our examples earlier:
if the test is "each > 10," and output is set to "coal" and outputs 1, if iron and copper are both 1, each will test false, and there will be no coal output.
If iron is increased to 11, iron will test true, and it will output 1 on coal.
If iron and copper are both 11, both will test true, and it will output 1 on coal twice, meaning it actually outputs 2 on coal.

So, using output "1", "each" in your condition means it outputs the number of input signals that passed the test.

If you output "input count," things get odder. In our example above, with iron and copper both = 11, the coal output would be 22.
With iron=11 and copper=1, the output would be 11.
With both = 1, it would not output coal.

I'm sure this would be useful in some circumstances, but I have no idea when or why! Let me know if you find one!

[mattj256]

ssilk, please, I know you're reading everything. Give us a combinator sub-forum!

+1
It would also be nice to have some of the combinator stuff transfered to the wiki.
The forums are for discussion. IMHO "polished" designs should be on the wiki or the Factorio Guide, as well as posted on factorioblueprints.com.
That's the best way to keep things searchable and accessible to newbies.

I've done some work with the wiki and I don't have (much) time for it.

As long as we're off-topic, what's the proper forum to post a challenge like "design something with combinators that will solve a quadratic equation"?

Ok, I'm ready to talk about the power switch now.

[XKnight]

By the way, this stuff is already described here viewtopic.php?p=98325#p98325

Also, I don't believe that you didn't know this information, because everyone always recommends this tutorial everywhere.
The core problem is to find application for this knowledge... difficult modes are used rarely, and this leads to lack of expirience with these modes, and this leads to unability identify the suitable applications for them, and this leads to rarety...
That's why this tutorial is good only for very beginners who doesn't want to launch the game and build one combinator by himself.
More experienced players should find their own way.

[siggboy]

Actually, this is very logical, because only using this behaviour you can calculate sum of different items using decider combinator (input: A,B,C,D output sum of every signal which satisfies given condition).
The only logical behaviour is to use each signal's value and calculate sum.

Couple of points:

First of all, it's not "logical" to have one way and not the other. When you say "logical", what you actually mean is "this is what I expect, and makes the most sense to me".

There's no "logical" behaviour, there's only CORRECT behaviour and INCORRECT behaviour. The correct behaviour is the SPECIFIED behaviour. If the actual behaviour is different from the specified behaviour, then either the specification needs to be changed or the implementation needs to be fixed.

The specification says: "Copy the value of the specified output signal from the input." This is not what the decider combinator does if you use the "Each" virtual signal on the input.

(Of course, the behaviour of these virtual signals is not even specified AT ALL anywhere in the game, which would be bad enough even if it wasn't quirky as fuck [excuse my French]).

From the other side what behaviour would you expect?

As said above, I expect the specified behaviour.

Input: A=100,B=200,C=300,Blue=20
"Each > Blue, output Blue" => Blue + Blue + Blue = 60 ? this is ridiculous.

Why is it "ridiculous"? It gives you the number of signals over the threshold, times the threshold. It is what it is.
The actual implementation gives you the sum of all signals over the threshold, mapped to the signal color of the threshold. How is this any more, or less, "ridiculous" than the other?

Maybe I happen to have an application for the first case. I have a reference input signal, and I want to output it once for every other signal that is less than/equals/greater than the reference. Then the specified behaviour would be what I'd need.

Also, the current behaviour is not consistent: "Blue > A; Output A" should be a special case of "Each > A; Output A" if the only inputs are "Blue" and "A". (Much like, for an example, an endless loop in a programming language can be made as a special case of a WHILE loop with a constant TRUE condition.) Alas, the game does not behave in that way, and it violates the Principle of Least Surprise.

It's like having a loop construct in a programming language that behaves differently if you only loop once. Nobody designing a programming language would have that.

"Each > Blue, output Blue" => Blue = 20 ? what is the difference with "Any > Blue, output Blue"

There would be no difference, but it would not be the specified (tool tip) behaviour either. So it's beyond the point.

[siggboy]

By the way, this stuff is already described here

viewtopic.php?p=98325#p98325

1. Each time you link to the post with the Bad Latch, a kitten dies.
2. The article was written before 0.13; and in 0.13 it was explicitely changed (mentioned in patch notes and in the tooltip), so that the decider copies the count of the specified output signal from the input -- except if you use Each, as it now turns out...

We now have a hybrid of the 0.12 and 0.13 deciders, and I don't think it makes things any easier to understand.

[siggboy]

Also, I don't believe that you didn't know this information, because everyone always recommends this tutorial everywhere.

I DID know that this is how the decider behaved in 0.12, and I assumed that with the 0.13 change it behaves differently in all cases, and not only in the special case where you do not use "Each".

The core problem is to find application for this knowledge... difficult modes are used rarely, and this leads to lack of expirience with these modes, and this leads to unability identify the suitable applications for them, and this leads to rarety...

I'd say that the core problem is that many people give up before getting to the point where they can successfully build interesting things, because the quirks and arcana of the combinators are just too much for most. (Maybe that's just paraphrasing what you've said.)

I would much prefer to find interesting solutions to practical problems with a toolkit that is consistent, correctly specified, and effective. There's only so much fun in exploiting weird behaviour before it becomes old.

That's why this tutorial is good only for very beginners who doesn't want to launch the game and build one combinator by himself.

I still think the tutorial is meh, because it first introduces a broken latch implementation as its first real-world example, and then spends the rest of the time explaining how to work around the brokenness of said latch. Sadly, GopherAtl seems to be gone and has never updated his guide in that regard.
And now you can tell the combinator beginners who've just read the guide when they post something clever which includes the SR-latch from that guide.

Sorry for all the ranting, I'll stop now. I'm aware it's off-topic.

[ssilk]

Just want to mention this post, which is (in my opinion of course ) water on my mills.
viewtopic.php?f=6&t=30191

[mattj256]

1. Each time you link to the post with the Bad Latch, a kitten dies.

Much of this could be improved by having the wiki and/or guide.factorio.com more up-to-date.
(The wiki is written and maintained by volunteers, not the Wube staff.)
I've made a lot of simple changes to the wiki, getting some things up to date for 0.13. I'm having a hard enough time making time for the game and real life, let alone the wiki.

At this point I've basically given up that anything will change with the power switch. I'm getting more used to the status quo. I can either accept the oscillations or build something external with the circuit network.
My last playthrough I did the "steam all the way" achievement and I didn't use the power switch at all.
In my next playthrough I'm looking forward to testing out that Schmitt Trigger with the four transport belts. Thanks for pointing that out.

[BlueDrache]

To implement a Schmitt Trigger (hysteresis circuit) you need 3 combinators (one to check lower bound, one for upper bound, and one for the latch).

This was nagging me, and so I tried to make it smaller.

Indeed you can make a Schmitt Trigger with only 2 combinators (plus an optional constant combinator for somewhat easier configuration):

schmitt-trigger.png

This configuration is closer to how you'd make a real Schmitt Trigger (comparator + feedback loop).

"U" is the upper threshold.
"D" is the difference to the lower threshold.

(In this example the effective lower threshold is "20").

The decider combinator outputs A=1 if it's in the "high" state, and nothing if it's in the "low" state (so on the power switch you'd set "A=0" as the condition if you want to switch it on when the accumulator goes below 20).

Caveat of this implementation: due to the 2 ticks delay in the feedback loop the contraption can fail if you have wildly flickering input over a wide range. Should not be an issue with power/accu related applications. This should not be a problem at all.

Your diagram doesn't read very well. I can't tell where the green wire's supposed to go. In your expanded diagram it looks like the constant is hooked to both the arithmetic and decider.

Are you able to clarify this?

[siggboy]

Your diagram doesn't read very well. I can't tell where the green wire's supposed to go. In your expanded diagram it looks like the constant is hooked to both the arithmetic and decider.

Are you able to clarify this?

The green wire needs to go to both inputs (the "U" and "D" values from the constant combinator need to be visible to both, because one uses the "U" value and the other one uses the "D" value).

You can remove the constant combinator (and green wire) entirely, and replace the "U" and "D" signals in the the combinators with literal values. The constant combinator is only there to make it slightly more convenient to configure the circuit.

Try to understand exactly what the circuit does, and how it does it, and it will become obvious to you how it needs to be wired.