Factorio Forums

I've hit upon what I believe to be a bug regarding how asteroid collectors (and possibly other items that both "set filters" and "read contents" in some form) interact with the circuit network. To my understanding, it should be impossible for 2 entities on the same network (and not connected to the other color wire) with "set filters" enabled to have different filters. Yet that is what's happening. Here's the story:

This started because I wanted to use the storage space inside my asteroid collectors to store asteroids in a controlled way, keeping it from filling with only one type of asteroid. My sushi belt stores some asteroids, of course, but it just seems like such a waste not to use those 39 slots per collector...

The immediate problem with using the storage space in an asteroid collector this way is that you necessarily need to both "read contents" and "set filters" on the same circuit network, and "set filters" turns on the filters as numbers get larger, not smaller.

Initially, I made a rather complicated setup with several combinators to use the top 2 bits of the values to represent the output of a decider combinator, forcing the sign to be what I want, while using the remaining 30 bits as if they were a signed integer, to represent the contents. This worked, but I thought I could simplify.

I hit on the idea of using integer overflow to cause a positive-negative boundary where I wanted it to happen. It was as simple as setting an entry for each asteroid type to (2^31 - threshold) in a constant combinator attached to the same circuit network. If I don't have enough asteroids of that type, the value on the network should be positive, but if I have enough asteroids of that type, the the value on the network should overflow and loop around, becoming something a little above -2^31, and removing the asteroid type from the filters due to the value being negative.

What actually happened was weirder. The collectors weren't all getting the same filters. If they were supposed to get a particular asteroid, they all had it in their filters. However, some collectors also had filters set for things they shouldn't, yet the collector next to it, on the same network, didn't have that filter. I did notice a correlation between the contents of the collectors and the spurious filters appearing (they would get filters for asteroids they had a lot of), leading me to a tentative conclusion:

I suspect that asteroid collectors are treating their own "read contents" value separately from the rest of the inputs to the circuit network, and adding it in in separate code, which is unfortunately not using 32 bit integers, and so not overflowing like the actual circuit network would.

Here's a blueprint string of the buggy setup, including the nearest asteroid collectors so you can see how they're configured and connected together:

Copy blueprint

Sleeping on this, I've realized the more likely answer is that the asteroid collectors subtract their own "read contents" output from the network value before setting filters, in an (arguably misguided) attempt to make it "easier" to use both mechanisms simultaneously. When controlling only a single collector per network, that could provide some benefits, at the cost of very unintuitive behavior, but with multiple on the network, the behavior is utterly unhelpful in every way...

The ignore-self-behaviour is not popular with the devs either: see also 120435.