Discuss: Power Switch should not "Blink"

[siggboy]

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 (336.82 KiB) Viewed 13949 times

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.

[ssilk]

Very nice. No really cool. I think I should put this post into Show Your Creations.... (?)

[siggboy]

Feel free . I should make a better screenshot without the fuckup with the green wire. Maybe a circuit diagram.

Actually it should go into the Combinator Contraptions thread (that's stickied already and it's where I would have posted this).

[XKnight]

It is a pity that I should search in the whole forum for the all combinator-related stuff, instead of looking in some dedicated forum section...
Sometimes I think that you are hiding interesting things from me

Build

Formula:
A = - lower limit
Blue = upper limit - lower limit

Example:
lower limit = 20
upper limit = 80
A = - 20
Blue = 80 - 20 = 60

[siggboy]

Nice design, as always. I'm glad you couldn't do it in 1 combinator, that would have been depressing. However, your solution only uses 3 tiles instead of 4, and it's more difficult to understand, so I guess you win .

It is a pity that I should search in the whole forum for the all combinator-related stuff, instead of looking in some dedicated forum section...
Sometimes I think that you are hiding interesting things from me

In all seriousness, there SHOULD be a dedicated sub-forum ONLY for combinator related designs.

We really need it. It' very difficult right now to learn this because you don't know where to search. The few sticky threads that we have are not enough.

Most of the time somebody posts something in "Show Your Creations", and then you have a valuable discussion, but the information is lost after a while.

Unless you know who the few people are who are actually good with combinators and post designs, it's not even possible to search for this stuff.

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

[siggboy]

lower limit = 20
upper limit = 80
A = upper limit - 100 = -20
Blue = upper limit - lower limit = 80 - 20 = 60

This explanation is not complete.

Does this imply a value range for "A"?
In the combinator, is "A = upper - (upper + lower)"? That would always make it "-lower", much simpler formula.
What happens if you apply values outside the legal range?
What happens if "A" is not present (zero)?

So I guess "Blue" is like "D" in my example (difference between U and L), "A" is "L * -1" and "U" is implied by "A * -1 + D". (I hope I got it right, just in case somebody tries to set this up with anything other than an accumulator ).

[XKnight]

Wow, I made a mistake, explanation is fixed.

In the combinator, is "A = upper - (upper + lower)"? That would always make it "-lower", much simpler formula.

Indeed, overengineering.

What happens if you apply values outside the legal range?
What happens if "A" is not present (zero)?

Emmmm, nothing bad (I hope ).

Actually, if you have (L=20 U=80 D=60) and you send 2^31-60 there might be some problems... and vice versa with negative values.

[siggboy]

I guess it's not necessary to use "Each" in the decider? You could as well do "Blue < A" (or "D < A" with mnemonic signal names).

Then the contraption would still work if there are other inputs on the wire except "A" ("Blue" is of course always illegal).

[XKnight]

I guess it's not necessary to use "Each" in the decider? You could as well do "Blue < A" (or "D < A" with mnemonic signal names).

Then the contraption would still work if there are other inputs on the wire except "A" ("Blue" is of course always illegal).

Nope It works only with Each mode.

[siggboy]

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 .

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