Decider combinator is malfunctioning, outputting signals it shouldn't

[Testymagic]

What I'm doing:
I was upgrading my main station, fumbling really...
Using decider combinators to check if I have to much of certain things and chucking them if I do.
The input is the space station with "read contents", the output goes to a grabber with "set filter".
Using basic AND/OR logic, it should indicate when a certain item has more then X amount and that item = specified item.

I am using deciders on all my spaceships and i have noticed this before, the grabber filter briefly shows an icon of something that should not be thrown out according to the set rules. On my smaller ships it doesn't actually throw them out. It seemed to correct itself before actually grabbing it.


sounds simple enough, but then why are outputs wrong sometimes?
In this case, my items were ruthlessly being thrown overboard
I saw this:
https://steamcommunity.com/sharedfiles/filedetails/?id=3381694471

Inspecting my decider to see if I messed up (after loading)

https://steamcommunity.com/sharedfiles/filedetails/?id=3381697919
https://steamcommunity.com/sharedfiles/filedetails/?id=3381698263

Seems ok right?
right now my grabber is sideways to prevent it from going.
but you can already see the output signal is showing my uranium fuel cells, which it shouldn't filter.
Hovering over the uranium fuel cell, you can see it "matches" with both the conditions that are for the metallic chunk

https://steamcommunity.com/sharedfiles/filedetails/?id=3381700740

grabber in action

https://steamcommunity.com/sharedfiles/filedetails/?id=3381701893
https://steamcommunity.com/sharedfiles/filedetails/?id=3381702171

Any idea what I'm doing wrong? it seems that certain items are simply mismatching.

[Testymagic]

FYI, I swapped the input of the wires from green to red between testing and reloading.
I don't think that should matter but you might notice it in the screenshots.
1 wire from station to decider input (the blocky part).
1 wire from decider output (the prongy part) to grabber

https://steamcommunity.com/sharedfiles/filedetails/?id=3381704918

[Testymagic]

another FYI.
On my smaller ships I use a fast inserter.
On my main ship I used a bulk inserter.
Funny enough, using different inserters causes different items to be thrown away.

[Fel]

It might "seem" ok but in fact it really isn't.
Each > 150 AND Each = Ice
Anything that is in a quantity over 150 and has the same quantity as ice would be "true".
So if your red circuits are in the same quantity as your ice and both over 150, both would fit the condition and end up in the filter.

I understand why you are doing it that way (to save on space and combinators) but that doesn't really work sadly.
I tried to figure out a solution for something like that but didn't really manage to find one that really works in all cases and had to go back to 1 combinator per signal.

[Testymagic]

full clarity, I am using this because I saw it in Nefrums speedruns.
It works fine for the most part, my 3 couriers are all running a reduced version (only chunks) and don't have the issue of actually throwing it away.

It still sounds like a combinator issue if x red circuits equals x ice.
That means the equals function does not take into account what type of material it is comparing?

[Testymagic]

perhaps I am expecting complex logic while this is doing simple math...

[PunCrathod]

What I did was put a green wire from the hub and a red wire from a constant combinator into the decider. Then if each from green is larger or equal to each from red and each from red is greater than 1 -> output each 1. Then just set the thresholds in the constant combinator.

Edit: you can omit the each from red is greater than 1 if you want it to throw away everything that you have not set a threshold for.

[Fel]

Your condition is "each", meaning it does all of the checks by replacing all of the "each" by 1 of the input signals, marks it as passed if it meets the conditions and false if not, then does the same with the next input signal until all have been done.

With the simpler "Each > 150 AND Each = Ice" from before, if you have 200 red circuit, 200 ice, 170 uranium ammo and 25 blue inserters (pure example) as input then it would do:

red circuit > 150 (true) AND red circuit = ice (true), red circuit passed the test.
ice > 150 (true) AND ice = ice (true), ice passed the test.
uranium ammo > 150 (true) AND uranium ammo = ice (false), uranium ammo didn't passed the test.
blue inserters > 150 (false) AND blue inserters = ice (False), blue inserters didn't passed the test.

The output would then have "each" be red circuit and ice since both passed the test.
The "ice" doesn't mean "if it is ice" but "if it has the same amount as ice".

[Testymagic]

I think I know what you mean, I'll try that tomorrow.
I think the reason a reduced version works (remove chuncks above 15) is because you never have those odd numbers with the resources you get. you usually have way more iron, plates, ammo etc.
So it only went wrong when I wanted high and round numbers that match stack sizes of other things.
So perhaps going odd numbers will help some. But the constant combinator will be better in the long run.

[PunCrathod]

Originally posted by Testymagic:

I think I know what you mean, I'll try that tomorrow.
I think the reason a reduced version works (remove chuncks above 15) is because you never have those odd numbers with the resources you get. you usually have way more iron, plates, ammo etc.
So it only went wrong when I wanted high and round numbers that match stack sizes of other things.
So perhaps going odd numbers will help some. But the constant combinator will be better in the long run.

The constant combinator version takes one more tile but I would think it is harder to make mistakes with it. It is much easier to see what the thresholds for each item is. It is also easy to turn off without having to delete things with the handy on off switch constant combinators have. I also had one ship with multiple constant combinators that went through decider combinators that output everything when the moving to/from signals had certain values. So depending on where the ship was going it would adjust the limits for items.

[Fel]

Originally posted by PunCrathod:

What I did was put a green wire from the hub and a red wire from a constant combinator into the decider. Then if each from green is larger or equal to each from red and each from red is greater than 1 -> output each 1. Then just set the thresholds in the constant combinator.

Edit: you can omit the each from red is greater than 1 if you want it to throw away everything that you have not set a threshold for.

That's definitely the right solution, not sure why I didn't even think about it and ended up wasting hours without even coming up with a solution when I tried to do this.
Many thanks for this.

[Testymagic]

@Fel I understand now that I was expecting a material type check when all it did was an arithmetic check. So I will mark your answer as the solution.
Chalk this one up to user issue

[PunCrathod]

Originally posted by Fel:

Originally posted by PunCrathod:

What I did was put a green wire from the hub and a red wire from a constant combinator into the decider. Then if each from green is larger or equal to each from red and each from red is greater than 1 -> output each 1. Then just set the thresholds in the constant combinator.

Edit: you can omit the each from red is greater than 1 if you want it to throw away everything that you have not set a threshold for.

That's definitely the right solution, not sure why I didn't even think about it and ended up wasting hours without even coming up with a solution when I tried to do this.
Many thanks for this.

I will admit I too had one decider per signal in my ships for some tens of hours of playtime. Then one day I said to myself that there has to be a better way and realized that I have been doing something similar with trains delivering stuff to defense walls. A few minutes later I had this setup and I actually felt a little bit smarter.

[Fel]

Originally posted by Testymagic:

@Fel I understand now that I was expecting a material type check when all it did was an arithmetic check. So I will mark your answer as the solution.
Chalk this one up to user issue

Maybe mark PunCrathod's first post as the answer since it gives you the solution you wanted, even if my answer gave you the reason of why your system didn't.

[Testymagic]

Well sure, my issue was not understanding the decider combinator which you helped explain. PunCrathod helped make it work. I guess both are right.
I'll mark PunCrathod's answer.

[Testymagic]

Thank you both