Factorio Forums

Abstract: Allow filter inserters to be configured to filter for negative signals (or any other condition than the default positive).

At the moment, when filter inserters are connected to the circuit network and set to "set filters" mode, they will grab any item for which they receive a positive signal from the network. I would like to be able to change the condition from "positive" to other conditions of the form > x or < x or = x where x is a number (or signal). That is, to allow filters to work analogously to decider combinators working on a condition involving "each". Of particular use to me would be to allow them to filter for only the items with a negative signal.

This would be particularly useful when one uses filter inserters which are both setting their filters from the circuit network and (in some mode) sending their contents to the circuit network. It would allow these signals to be "opposed" to each other so that the pulse from the filter picking up an item could trigger the item to be taken out of the filter the next tick. I already use this principle with belts - for instance, in the image below, the first belt is activated when (stone) < 11 and the second belt is in pulse mode, the combinator is set to +0 and the constant combinator is set to -11 stone. It works so that the moment the second belt signals that it has received enough stone, the first belt is shut off. I would love to be able to set a filter inserter to filter for negative items to allow the following setup to filter for exactly 11 stone (where the filter inserter is in "pulse" mode for reading): However, at the moment, this cannot be done since filter inserters are locked to filtering for positive signals. In any setup, this requires some additional logic to remove the filter, so requires both an extra tick (at least) to respond to the stimulus, and more combinators. With this "negative means go" convention, I do not need to build any new combinators to control new belts - it's easy enough to build a central system which counts all pulses sent to it (with no delay) and maintains the signal as that count minus some constants, thus controlling every belt attached to a single network.

As far as I can tell**, with filter inserters as they currently are, it is impossible to build a system with the same nice properties as the belt control system I use - each inserter needs at least one combinator to control it/read its output. Further, a filter cannot fail its circuit network condition the moment the inserter sends out the appropriate pulse, since the combinators take time to process. The best system I've come up with for the current behavior is two ticks slower* than what I propose and uses one extra combinator per filter inserter.

This is similar to existing functionality in both decider combinators and the usual enabled/disabled GUI, so I doubt it would be too hard to implement. However, it would make building large smart factories substantially easier by allowing filter inserters to easily be set up to grab exact amounts of items.

(*This is enough of a delay to cause a filter inserter with stack bonus to retrieve too many items off a red belt. It can handle a yellow belt fine though. I'd assume that one could get the delay down by a tick with some circuit network witchcraft, but I'll bet that blue belts would still be troublesome)

(**EDIT: It has occurred to me that one can abuse integer overflow to get things to work. I'd generally prefer such behaviors not to be necessary to reasonably straightforwards application, though)

If you want 11 iron in the chest, why not wire the inserter to the chest and tell it to insert iff iron < 11? Besides, saving a few ticks for an optimisation trick doesn't seem necessary.

I would love to be able to use "enable/disable" and "set filter" modes AT THE SAME TIME on an inserter. Right now they're exclusive to eachother (which is not really necessary).

Probably material for a separate suggestion thread, but kind of related to this one.

Also let me point out that, unless this suggestion is implemented, we kind of need negative filters to NOT filter, because it's the only way to disable an inserter with a filter on it if you have no way of "un-setting" the filter.

For example, if your filter is set from a register, but you can't erase the register for certain reasons, the only way to remove the filter is to "overwrite" it with a negative value that is small enough. You can also use this to stop the inserters at a precise item count (if you add -2^31 - item_count to provoke a negative overflow when the limit is reached).

Go to this FFF
https://www.factorio.com/blog/post/fff-140
and scroll down to "circuit network examples".

There's also this forum thread:
viewtopic.php?f=5&t=25756&start=10

The net result is what siggboy asks for: a way to dynamically set the filter on a filtered insterter and also dynamically turn it on and off.
Please don't make the filtered inserter more complicated than it already is. This stuff is hard enough to understand as it is!

Of-topic:
In my opinion this points to a basic misconception of the whole circuits.

Let's explain it so: Today I changed the batteries of the outdoor thermometer. I can see that it needs to be changed, when the reciever shows me, that there is no signal anymore from outside.

So this is a state, where there is NO signal anymore.
The same thermometer can send also an signal "UNKNOWN". This is, when the temp is too hot or too cold to be in range of it's hardware.
In all other cases it sends the temperature. Unlike the Factorio ciruits it can send a signal "0 degrees". That is just a value as any other.

If the circuits where a wire that means:
- No signal: The wires aren't connected. Or no power on sender-side.
- Unknown: The voltage on the wire is too high or too low, to be measured.
- In range: The voltage on the wire is in relation to the outdoor temp.

That is known in informatics, too: The first one is, if the value doesn't exist. Often called "not existing", "not defined", etc. It is a state, where you even don't know, if the value is known or unknown. The second is the value NULL, which can just be described as "unkown" or "I don't know". It is a value, like any other value, but you cannot calculate with it (null-arithmetic is used instead). And only the third state are simple scalar values.

Just my 2 cents.

I'm not entirely sure if I understand you correctly, ssilk, but if you are suggesting that "0" (zero) should be a possible value in combinator signals, then I agree.

Obviously, if combinators were changed (fixed) in that respect, it would break everything, and half the player base would leave. Well, maybe not, but even if only XKnight left it would be bad enough

siggboy wrote:I'm not entirely sure if I understand you correctly, ssilk, but if you are suggesting that "0" (zero) should be a possible value in combinator signals, then I agree.

Yes, that's the point. If I set a combinator "Output signal X", then there is a signal X, but it has no value.

Obviously, if combinators were changed (fixed) in that respect, it would break everything, and half the player base would leave.

It's clear for me, that this change has no good game-play value. I won't make such suggestions.
What I wanted to say is
A) Any change to the current system will break other behavior. It's like fixing a tire by pluging a nail into the hole. The best choice is to keep it as it is.
B) I just wanted to point to this problem, from where it comes and how it could be fixed. Of course there are eventually better solutions. Of course I'm not sure, if this is a solution.

ssilk wrote:

siggboy wrote:I'm not entirely sure if I understand you correctly, ssilk, but if you are suggesting that "0" (zero) should be a possible value in combinator signals, then I agree.

Yes, that's the point. If I set a combinator "Output signal X", then there is a signal X, but it has no value.

Well, 0 ("zero") is a value, "no value" is another value (like NULL in SQL, the empty word [epsilon] in formal languages, NaN in JavaScript, etc. etc.). Factorio does not distinguish between "0" and "epsilon" -- and a signal with value "epsilon" disappears. On the other hand, you can compare to "0", and it's the same as comparing to "epsilon". It's a way of simplifying things. You can also eliminate values by zeroing them.

One of the problems is that you can not multiply by zero, unless it's a constant value "zero". This is a drawback. If it was possible, you could much more easily filter values. Set the filter signal to "zero", multiply the input by it, and then output non-zero signals (of course the latter is also not straightforward, since we don't have a "not-equals" comparison, but that's another story).

Having "zero" as a proper value meets common sense, and what people expect from a programming language.

One would have to introduce a special value "epsilon" (or "undef" or "NaN"), then you could still make the old comparisons that are possible now (like "Green = epsilon" would be true iff no Green signal is present; right now you do "Green = 0").

I'm pretty sure than Twinsen and the other devs have considered this at some point, but the general design philosophy regarding combinators appears to be to keep things simple and barebones. I currently feel that this is the wrong philosophy.

A) Any change to the current system will break other behavior. It's like fixing a tire by pluging a nail into the hole. The best choice is to keep it as it is.

There are infinitely many changes (including improvements) that do not break other behaviour. A great example is the Decider combinator change proposed by XKnight (28946) -- it's a substantial improvement and does not break anything at all.

Sometimes the best choice is actually to keep the status quo, but certainly not always.

B) I just wanted to point to this problem, from where it comes and how it could be fixed. Of course there are eventually better solutions. Of course I'm not sure, if this is a solution.

I don't even think we're on-topic any longer. I agree with OP that it should still be possible to use a circuit condition on the inserters IN ADDITION to being able to set a filter value. The two scenarios do not conflict, and it would be easy to present in the UI.

Also, setting a negative value to remove a filter is useful, it allows for clever contraptions, and it allows you to eliminate a filter even if the inserter is in "hand read (hold)" mode and is holding an item. It's not a huge drawback that a negative count is not allowed to set a filter, but it does have applications.

If "zero" was a possible value, then one could have all non-zero values set a filter, "zero" signals would have no effect and/or remove an existing filter. It's not much different from the current situation. But a "zero" value is good and logical and consistent in general, and useful in many other scenarios.

siggboy wrote:I'm pretty sure than Twinsen and the other devs have considered this at some point, but the general design philosophy regarding combinators appears to be to keep things simple and barebones. I currently feel that this is the wrong philosophy.

Well, my opinion is, that if we have wires, they should behave like wires. They should behave like real hardware-objects.
As it currently is, it is not the case. They behave more like basic programming languages.

Sometimes the best choice is actually to keep the status quo, but certainly not always.

Yes, there is always a third way. I speak of course as a programmer and programmers always try to make things "perfect". Please understand my statements In this sense.
In reality I'm much more convenient; In my daily business we do small, very small steps to improve existing software. Much harder, than doing it right from start.
And this is also the way the devs should go now.

So much off-topic for now.

ssilk wrote:

siggboy wrote:I'm pretty sure than Twinsen and the other devs have considered this at some point, but the general design philosophy regarding combinators appears to be to keep things simple and barebones. I currently feel that this is the wrong philosophy.

Well, my opinion is, that if we have wires, they should behave like wires. They should behave like real hardware-objects.
As it currently is, it is not the case. They behave more like basic programming languages.

"Real hardware wires" (in digital circuits) do not transmit values, they only carry voltages, and that's used to encode binary digits. If you want combinators to be a simulation of actual digital circuits then suddenly everything becomes really complex. I do not think anybody wants that.

It's OK that combinators are a hybrid of digital circuits and a programming language. But if you create such a hybrid, you might as well try to make it easy to use for PROGRAMMERS -- and not introduce tons of arcana and quirks. Electric engineering knowledge is useless for combinator design, but computer programming knowledge is not. The two worlds should meet a little closer together.