, computers.
- comparative combinators.png (1.46 MiB) Viewed 1077 times
You can also put not two, but three comparative combinators, or even more, as for example in this scheme:
- comparative combinators (2).png (989.79 KiB) Viewed 1077 times
Checking multiple conditions
Checking multiple conditions
Then I was just wondering why there are not several conditions for turning on a flashlight or a manipulator. I soon realized what was going on and wanted to show how it worked. First, let's put a constant combinator and set two values. For example: a = 2 and b = 6. Next, we put two comparative combinators together with a constant, and set conditions for them. Let's say a = 2 and b > 4. The output signal should be 1. We put an arithmetic combinator and connect it with comparative ones. It is configured like this: a + b. That is, if everything is correct, the number 2 should turn out. Next, we attach the arithmetic combinator to the manipulator and set a value for it or to the comparative combinator and everything like that. In our case, to the conveyor. It should turn out like this:
Plan:
You can also put not two, but three comparative combinators, or even more, as for example in this scheme: Plan:
You can also put not two, but three comparative combinators, or even more, as for example in this scheme: Plan:
Last edited by Fjfirond on Tue Aug 20, 2024 5:35 am, edited 1 time in total.
Re: Checking multiple conditions
I encourage you to describe your ideas in a more general way. In your example, you're doing this: You're individually checking conditions and counting the amount of matching conditions. Then check if the current amount equals to the desired number of matching conditions.
There is another way to check multiple conditions. You may need to check if multiple different signals are all above some individual threshold or all below some individual threshold. For example you want to know if "steam < 50000 and counter < 12000". The crucial thing is to make it so that all comparisons are the same operation: all > or all < or all ==.
Add a constant combinator that contains the negative of the individual thresholds. It's steam=-50000 and counter=-12000. Connect this with one wire to the device that needs the decision (doesn't even need to be a decider combinator) and the real signal with another wire color, so they're not interfering. All are summed up in the device, so the threshold values all become 0. So you can check directly within the device as EACH < 0. It works the same with EACH > 0 if you need all thresholds above some value. If you need all values = 0, you need EVERYTHING=0, not EACH=0, since EVERYTHING is the only wildcard operator that returns true, if there are no signals.
This works without even a single combinator!
You can also count this way similar to your example and check how many conditions match. If you do use a decider combinator in my above example with EACH > 0 or EACH < 0 and output value M=1, it outputs M with the amount of matching conditions. So you feed this signal to the device that needs to check how many conditions match and check for M=3 if 3 conditions have to match at the same time.
There is another way to check multiple conditions. You may need to check if multiple different signals are all above some individual threshold or all below some individual threshold. For example you want to know if "steam < 50000 and counter < 12000". The crucial thing is to make it so that all comparisons are the same operation: all > or all < or all ==.
Add a constant combinator that contains the negative of the individual thresholds. It's steam=-50000 and counter=-12000. Connect this with one wire to the device that needs the decision (doesn't even need to be a decider combinator) and the real signal with another wire color, so they're not interfering. All are summed up in the device, so the threshold values all become 0. So you can check directly within the device as EACH < 0. It works the same with EACH > 0 if you need all thresholds above some value. If you need all values = 0, you need EVERYTHING=0, not EACH=0, since EVERYTHING is the only wildcard operator that returns true, if there are no signals.
This works without even a single combinator!
You can also count this way similar to your example and check how many conditions match. If you do use a decider combinator in my above example with EACH > 0 or EACH < 0 and output value M=1, it outputs M with the amount of matching conditions. So you feed this signal to the device that needs to check how many conditions match and check for M=3 if 3 conditions have to match at the same time.
Re: Checking multiple conditions
If you set the output of the deciders to the same signal you can omit the arithmetic combinator, the circuit network will add the outputs for free.
With 2.0, which is just two month away, a single decider will be able to test multiple conditions at once, similar to what wait conditions in a train's schedule allow currently; see FFF 384.
FYI: you can put blueprints in [ bp ] ... [/ bp ] tags like this:
With 2.0, which is just two month away, a single decider will be able to test multiple conditions at once, similar to what wait conditions in a train's schedule allow currently; see FFF 384.
FYI: you can put blueprints in [ bp ] ... [/ bp ] tags like this:
Re: Checking multiple conditions
I just checked it works. Thanks for the advice!Tertius wrote: ↑Mon Aug 19, 2024 12:03 pm I encourage you to describe your ideas in a more general way. In your example, you're doing this: You're individually checking conditions and counting the amount of matching conditions. Then check if the current amount equals to the desired number of matching conditions.
There is another way to check multiple conditions. You may need to check if multiple different signals are all above some individual threshold or all below some individual threshold. For example you want to know if "steam < 50000 and counter < 12000". The crucial thing is to make it so that all comparisons are the same operation: all > or all < or all ==.
Add a constant combinator that contains the negative of the individual thresholds. It's steam=-50000 and counter=-12000. Connect this with one wire to the device that needs the decision (doesn't even need to be a decider combinator) and the real signal with another wire color, so they're not interfering. All are summed up in the device, so the threshold values all become 0. So you can check directly within the device as EACH < 0. It works the same with EACH > 0 if you need all thresholds above some value. If you need all values = 0, you need EVERYTHING=0, not EACH=0, since EVERYTHING is the only wildcard operator that returns true, if there are no signals.
This works without even a single combinator!
You can also count this way similar to your example and check how many conditions match. If you do use a decider combinator in my above example with EACH > 0 or EACH < 0 and output value M=1, it outputs M with the amount of matching conditions. So you feed this signal to the device that needs to check how many conditions match and check for M=3 if 3 conditions have to match at the same time.
Re: Checking multiple conditions
What about version 2.0, I don't have it, the game hasn't been bought, and what about the drawings, thank you!Nidan wrote: ↑Mon Aug 19, 2024 12:37 pm If you set the output of the deciders to the same signal you can omit the arithmetic combinator, the circuit network will add the outputs for free.
With 2.0, which is just two month away, a single decider will be able to test multiple conditions at once, similar to what wait conditions in a train's schedule allow currently; see FFF 384.
FYI: you can put blueprints in [ bp ] ... [/ bp ] tags like this: