Factorio Forums

After reading the wiki and playing with the above combi I didn't get the results I expected. So I searched this forum and found a question in the "not a bug subforum" here viewtopic.php?f=23&t=49869&p=565866&hil ... er#p565866. Here is a snippet of someone explaining CORRECTLY how it works. I now understand this and have tested it to confirm.

Let's say I had the output of the first Arithmetic Combinator (B=10) hooked up to the input of the Decider Combinator, with the condition of "B > 5", and an output of "C = Input Count". I was expecting that because B=10 (and is therefore greater than 5), that C would be output with the count of B - but this is wrong. What actually happens is, C gets output with the input count of C, which in this case is 0, thus nothing happens. If I was to switch the output to "A = Input Count", then I would be getting A=10 on the decider output, provided the input was connected to the same input source as the arithmetic combinator.

What I don't understand is the logic for this. An easier example (and to explain why I don't see this as useful) - say I have 10 belts in a box the combi is hooked up to read it. The condition is IF belts =10 then then TRUE. If I set the output to 1 and stone then this works as you intutively expect, it outputs 1 stone. However, if you change this to still be stone and set it as "input count", nothing is outputted. This is because it tries to get the count of STONE from the input signal and NOT the count of the input signal ((which is exactly what the tooltip says btw!) which is the belts)). Since there is no stone on the input, rather than output the count 10, it outputs 0. This is very unintuitive and I can't understand how this would even be useful. Why not have the logic in the way I THOUGHT it worked? Not saying my opinion is any better, but it is the way everyone would intutively think it worked.

Can someone give a example of how this way is better than what you would intutively think it would do?

Thanks,

It's more flexible. You can replicate your suggestion by outputting the tested signal and then using an arithmetic combinator to rename it to the signal you actually wanted. But what if the signal you're testing and the signal you need to forward/output are different? For example, when I need some memory I tend to use decider combinators with "if reset-signal == 0, then output stored-signal, input count". With your suggestion, this would always output 0; either because the condition is false or because the condition is true, and thus reset-signal is 0.

It is an example that programmers brain works differently than average human.
Here is classic joke, which is not a joke.

A woman says to her husband: "Go to shop, I need groceryes. Buy a bread, then check if they have eggs so you can take 10."
In half an hour her husband a programmer came back with 11 loaf of bread.

Reason:
task one > Buy a bread
task two > Condition "check if they have eggs " fallowing action defined previously buy bread.

That is exactly how decider works:
Check valid value of the condition YES / NO
if condition is valid(YES) then do counting

Get noticed, counting has NOTHING to do with condition. There is no link, no relation.
It counts EXACTLY what you say.
condition is separate task
counting is separate task
It is perfectly intuitive as long as you received technical brain.

Mucker has it generally right. Thing is that the quote below is kind of a tall order.

mucker973 wrote: ↑

Thu Aug 25, 2022 10:16 pm

Can someone give a example of how this way is better than what you would intutively think it would do?

I can give a clear simple example of this being used, sure, and I will below. Trying to illustrate the fine point of *better* is tougher though. It would require some fairly complicated nuanced designs and I suspect that you're probably just not ready for those without a lot of hand holding.

Anyways, here's a simple useful design that I have deliberately exploded and further simplified to make it as easy to understand as possible. It's a low power warning alarm.

Copy blueprint


From left to right, it goes like this.

Section 1.
Accumulator sends it's charge as signal A.
If the charge level is >= 75%, things are good so send a single green signal.
If the charge level is < 75%, things are bad so send a single red signal.

Section 2.
Note that the combinator here connects to itself on the green wire! It's a memory cell working as a timer.
Every game tick (nominally 60 times per second), this combinator sends the current value of red back to itself and will do so until the accumulator is recharged to 75% and sends a green signal from section 1. If the charge is below 75%, this memory cell continues to *additionally* receives a red input from section 1 above. In other words, the stored red value will tick upwards by 1 every game tick until the accumulator gets charged.

Section 3.
Now that we have a timer that's ticking upwards until the low power situation is resolved, we do some simple math on that timer's value and use it to sound an alert every 3 seconds. Why every 3 seconds and not continuously? What a silly question... What do you have against my ears?


So there's a simple demo of *usefully* passing a value through a logic combinator on a test. Once you understand this example, you will be prepared to understand the problem with this line.

mucker973 wrote: ↑

Thu Aug 25, 2022 10:16 pm

Since there is no stone on the input, rather than output the count 10, it outputs 0.

That's only true in your specific example. In reality, there may or may not be multiple inputs on a single line.

The combinator literally can't be smart enough to determine your intentions. It does not and can not tell if the inputs it's receiving are from a pretty simple 1 input system or a complicated system with possibly many variable inputs that happen to all be zero at the moment. This means that the combinator *has* to just act consistently one way or the other.


So let's look at it both ways.

The way it is in the game right now, you can get the result you're expecting easily. It just takes one more combinator.
Combinator 1 - Decider. If belts = 10 output count belts. Combinator 2 - Arithmetic. Belts * 1 = Stone.


So then lets look at it from the other perspective. Let's say you *do* have multiple inputs and you want to gate 1 or more of those values behind a condition. Modifying your example, let's say you have a chest that may contain some number of belts and rocks. You want to pass the number of actual rocks forward if the number of belts is 10. If the combinators worked the way you propose, how would you get the number of actual rocks?

You would need 3 combinators. 2 in a pair and then a third merging the output values. The pair would consist of the logic test with an output of 1 belt and a second combinator to output the actual rock count and then you would need the third combinator to multiply the rocks by the single belt. Alternatively, you could do it with 2 combinators if you introduced a third reserved variable, let's say check marks. The first combinator would be a decider that outputs 1 check if belts = 10 and the second would be an arithmetic combinator that multiplies checks by the true rock count from the box. Either way, you're introducing 2 new elements to juggle.



Now maybe you're thinking introducing 1 element vs 2 elements isn't such a big difference. Especially for the edge case of multiple inputs.

Well, lemme tell you this - If and when you start working with more advanced circuit designs, you'll find that managing multiple inputs isn't the edge case. It tends to be the norm. The simple stuff can *usually* be done either with no circuit logic at all or simply doing a single check on an inserter/pump. Virtually everything that you need to solve with circuit designs is a bit complicated as the baseline and complicated circuit designs get big and messy really quickly.

I will also tell you that, subjectively speaking, as a guy that does a *lot* with circuit networks, I gate multiple inputs behind a test *way* more often than I want to convert the value of a test into some arbitrary signal.

If your decider combinator input is only signal B, there is a trick to convert the output to signal C.

That works but I'm just going to put this warning out there for newbies -
Be *really* careful with doing that. It really does hinge on having a single input. Things like this can be hard for the inexperienced to suss out when, not if, you make a mistake. More explicit forms are easier to debug. I'm not saying "do not use". I simply saying "use with caution".

It's all documented on the wiki. The decider combinator looks easy at first glance, but it has some very interesting not obvious features, especially with the wildcard operators. It can not only just decide on one input signal and return the result of that, it operates on conditions in a general way. You can work with the whole input (all signals), not only one single signal, and output can be based on the whole input, not only a single input signal.

If the combinator worked as the OP assumed in the first place, it would be limited to one signal only. By disconnecting the condition from the output, it opens a broad field of additional functionality. Its best function is the ability to filter a whole set of signals in one step.

For example, if you want a list of items you need to load into a train. In this case, you subtract the train content (read from a station) from a reference (constant combinator). With a decider, you set the condition to * > 0 (anything > 0), and as output you also use * (anything). You get signals for all items where there are less items in the train than in the constant combinator, and you get exactly the amount that's missing. Only 2 combinators required: one arithmetic and one decider.

"Only 2 combinators required: one arithmetic and one decider."

You forgot the constant combinator.

Also... You don't need the decider and *possibly* don't need the arithmetic either. In any case, from your description, you don't need the arithmetic combinator you *think* you need.



Let's say your example train currently has 500 of 1000 desired copper plates.

Wire the train station to a constant combinator via a red wire.

Set the station to read train contents enabled.

Set the constant combinator to output -1000 copper plates.

Run that red wire to wherever you want to use the total. The signal on the red wire will read -500.

Depending on what you intend to do with that signal, you may want to multiply it -1. In my experience, this is usually the case but not always.

Let's say you do multiply by -1. You *can* filter unwanted values with a decider set to each > 0 but, IME, that's almost always pointless.

You can always set the output to the same signal you test. Then you get the behavior you want. As said the current behavior is more flexible.

Here is another simple example:

Say you want to output a red signal when pipes and underground pipes are above 100 each. So you place one decider combinator set to "pipes > 100: output 1 red" and connect the output to a second decider combinator set to "undergound pipes > 100: output red (input count)". The first combinator will create a red signal and the second will let it through (if there is one present). So now you have a decider for 2 conditions.

ColonelSandersLite wrote: ↑

Fri Sep 02, 2022 3:44 pm

"Only 2 combinators required: one arithmetic and one decider."

You forgot the constant combinator.

Also... You don't need the decider and *possibly* don't need the arithmetic either. In any case, from your description, you don't need the arithmetic combinator you *think* you need.

It depends of course on what kind of signals exactly you need. I just gave an example where it might be useful if part of a bigger setup.

I had my self designed supply station in mind where I define the desired content of one wagon with one constant combinator and 1 requester chest per wagon that requests exactly these items. Not a bunch of chests that all have their own item, it's just 1 chest for all items, so you can load up to 40 different items into one wagon. In this setup, I needed to filter and select arbitrary items and never decide for single items - it all works universally for all possible items.
Copy blueprint