Inverse filter setting (Is not filter, take all except...)

[I_IBlackI_I]

Joined -- ssilk

I thougt it would be cool if you could set filter inserters to take everything exept the items you put in.
Just an idea.

[Mysteria9]

Even though one can do this with multiple filter inserters, it would be quite space-saving to have this. I like the idea!

[I_IBlackI_I]

I know its still possible but remeber the game is in alpha so there will be alot more items in the future!

[ficolas]

this is usefull, if you have a chest with lots of different items, but is better to sort the items in different chests I think

[EditorRUS]

Easily could be implemented with NOT condition. Filter will take "exceptions" from belt and return to basic chest.

[rlerner]

The ability to use filter inserters to remove anything NOT specified in the selection, help with garbage removal on lines when changing them up or when a chest explodes

[rk84]

Handy, but with bit of planning you can do that with normal filters.
another thread

[ssilk]

I add the need for such an inserter, because it is just logic.

I also would see operators like "lower equal" and "higher equal", I constructed a belt-farm, where this was needed and I needed and extra inserter for that. (Ok, everything can be built like with more effort, but this is in my opinion also the problem of the game).

[MF-]

I also would see operators like "lower equal" and "higher equal", I constructed a belt-farm, where this was needed and I needed and extra inserter for that. (Ok, everything can be built like with more effort, but this is in my opinion also the problem of the game).

Would you be happier if we got "lower/equal" and "higher/equal" instead of current "lower" and "higher" ? (+0 on the slider)
I still don't think we need both.

[ssilk]

No! If I where forced to choose I would say "lower" and "higher" are enough, because "lower equal" includes always equals and this is already existing (as said you can rebuilt "lower equal" with two inserters in a row, but the other way (make lower equal to lower) is much more complicated, because f. lacks the "not equal").

Hm. I think I have a better idea.

Firsr add a row of buttons under the slider for the logic like so:
"-4", "-3", "-2", "-1", "0" (default), "+1" , "+2", "+3", "+4". Thats enough.

The number from the slider and the number from the buttons are added (don't forget to show the resulting number )

Because we have always integer numbers, this works fine and it is common practice in programming to add/subtract 1 for such problems instead of dealing with operators, because this will complicate the algorithm.

And when we are here: The "equal" makes not so much sense to me. The problem is for example like this: you have a production-line. You switch the inserter which outputs from the factory off, when you reach for example 10 items. But till the items comes to you, it takes time. In this time the next item is produced (because the count wasn't reached yet). Now the item is inserted. But before the output stops, the factory has created another item and the programmed inserter puts it on the belt. Now the output is stopped. But one item lays on the belt and now it is inserted into the chest and counted. Now the production restarts, cause now you have 11 items in the box, which is not equal 10.
I barely can think of situations, where you really need "equal" - and only if it is guaranteed, that if I insert with 4 smart inserters into a chest, another smart inserter will move once, if the count is exactly reached. (this takes with 4 inserters only 0.1 secs)

So in conclusion: I really mean only "lower" and "higher" is needed. Instead of the symbol display it in English language please.

[Oh yes, when doing this plz change the numbers in the slider: Instead of 0 1 2 3 4 5 6 7 8 9 10 20 30 50 ...
to 0 4 8 12 16 24 32 64 ... this fits much better to the stack sizes - more logically I think and it avoids wasting half stacks.
Below this you can might write how many items of this type (if already selected) will fill a small chest, a smart chest... completely.
]

...

And when I'm in the middle of recommended changes : I think it is so hard to program the inserters!
Because you have situations, where you need to program dozens with the same program. One little mistake with the slider and you can search very long for the reason why it doesn't work as expected. Takes time. Slows down gamespeed. This is not good.

I would prefer instead a controller which I program once and which can also have more than one output. And that the smart inserters work with it the same way as the slow, because the speed of the different inserters are sometimes very important but you cannot make the smart inserter slower...

Nebulous. Far target... I try to explain this vision as clear as I can.

Step 1: Pull the filter and logic out of the inserters. They are not practical for more than 3 inserters with the same program. The inserters in my eyes are just different speed and costs resources like now. Instead, they have up to 2 stacks: One for up to 5 filter modules and one for up to 2 logic modules. This stacks rebuilts the current behaviors. This enables upgrading without making the maps unplayable.
To make the handling easier: Add a button "Add", which builds and extends the module in one step.
(and it should be easy to make a different filter module "inverse filter" which moves all, what is NOT selected) or a filter, which filters only every second/third... item)

Step 2: create a "controller-device", which has a stack for logic modules and you have some kind of routing input (-channels) to modules and then to the output (-channels).

Step 3: Remove the need for red and green wires. They are already there but normally you need only one type. It has channels to distinct the source and targets. (The red and green wires may be used inside the controller?)

Now you set this controller anywhere near and the inserters don't need any logic internally (no stacked modules are needed in this case), all inserters can be controlled by a wire and telling the inserter to which channel they should "hear". You don't have to program the inserters, you program the controller instead and wire the signal to the right channels.

Step 4: Add more modules! Instead of a simple counter module (it counts, if something is over or under a value) you have a time-switch-module. A boolean-logic module. Add sensors for power control or creeper alarm module (can be stacked only in the radar). Or a regulator circuit with 2 inputs and 5 outputs to regulate something. https://forums.factorio.com/forum/vie ... 6234#p6234

Step 5: Now you need only some panels (for controlling the controller from everywhere) and lamps with different colors, horns, sirens, blinken lights, etc.

And this matches so well to the steam-punk theme...

[MF-]

I don't see any difference between "<" and "is lower than", except for the screen-size taken and the resulting reduced precision of the slider.
I don't see any difference between "x<=a" and "x<a+1"
I don't see any need for rewriting your suggestion here instead of the thread that you already allocated instead of simply linking it.

I would support a way of fine-tuning the threshold, though.
Stack-size rounding v.s. decimal rounding: I think it's the same problem as decimal v.s. hexa when doing low-level programming.
I am afraid this need a toggle in the menu. Beginners will likely prefer decimal and circuit circuit designers hex.

[ssilk]

I don't see any difference between "x<=a" and "x<a+1"

One operator less? Simpler fine tuning with bigger numbers? I often tried things like "inserter 1 lower than 4, inserter 2 lt. 3, inserter 3 lt. 2 " to make a cascaded output. Doesn't work very good with the current methods to create a controller, but would work perfect with other types of controller.

I don't see any need for rewriting your suggestion here instead of the thread that you already allocated instead of simply linking it.

I'll try to slow down myself. it's just pure fun for me to think and write about it... Call me crazy... Ok, I should put the things to the right threads...

Stack-size rounding v.s. decimal rounding: I think it's the same problem as decimal v.s. hexa when doing low-level programming.
I am afraid this need a toggle in the menu. Beginners will likely prefer decimal and circuit circuit designers hex.

Good idea, OTTD has also dozens of preferences like that. Maybe a better idea but much more work:There is always a chest involved, right? Either a smart chest or some of the logistic networks. You can follow the cable and look, which chest is on the other end. And this is the scale that is preselected when opening the inserter the first time. There is a small select-box in the inserter, which preselects the type of chest (=scale) and shows the icons of the boxes, which match this stack size. The scales are then for example 1, 16, 32, 48 and 100. The 1 and 100 is for the beginners and no icon is displayed.

And now you can say in the slider 1/16, 1/8, 1/4, 1/3, 1/2, 1, 2, etc. which numbers are shown may depend from the scale. This is multiplied with the scale and displayed.

Hmmm. Too much work. For the first implementation I would say let's try it and put in just the scale-selector, set it per default to 1 so that - if you don't touch the scale - everything works as before and see how this plays...

[defacto]

Here are my three points/wishes:

1. I would also like a <= and >= operator. Maybe you could change the operator selection into a expandable list instead of cycling through the operators.
2. Values shoud start at 0 and not at 1.
3. Keyboard could be used for fine grained manipulation of the value. At first you could use the mouse to set it to 100. Now you press left do decrease it by 1. Holding the key will continue decreasing after a short break. Pressing the right arrow key would increase it by 1.

[Nukem950]

Joined, cause identical, but see the former discussion about it, please -- ssilk

It would be cool if a NOT option could be added to the smart inserter. The idea would be that you want it to grab every type of item except for one (or maybe up to 5). For example, the inserter would grab everything except coal.

I have 2 scenarios in my head where this could be useful:
1. It could be used to keep certain transport belts from being contaminated, such as keeping an ore or coal line from having random junk on it, preventing furnaces from working.
2. You could use it to pass repair supplies to a remote train stop without having to add additional train cars. This could include ammo, repair packs, walls, etc. You could have an insert dumping stuff into a train car while it is being unloaded, with smart inserts filtered only to take the one item out . At the remote depot, have a smart insert that grabs everything out except for your resource you are working with, while inserters on the other side are loading it up with your resource.

[ofca]

Well, this is an obvious oversight, which requires multiple smart inserters to think of everything that may fall down on a belt. The things I found blocking a furnace, or lying at the end of a belt... - and to think they could've just fallen into an active provider chest and be done with them.

[Khyron]

This is one of those requests that seems logical but if you actually challenge the theory by looking at practical examples, it seems we can implement a pretty good filter that deals with reasonably sensible factory layouts, as discussed here.

So we have to ask what will adding an absolute filter (a smart inserter with an inverted filter, for example) add to the game? Well, most importantly it will provide a very easy way to solve problems with bad factory layouts.

People will yelp at that saying they want to play Factorio their way and that my way isn't the only right way, but that's not at all what I'm discussing here. IMHO adding this feature would be too convenient for people who have not yet come to understand the puzzle aspects of Factorio. Redesigning your factory to function better with the parts you have available is core to the game. If you absolutely can't live without a filter, maybe a mod could be created. I don't think a filter belongs in the vanilla game.

[Wyrm]

IMHO adding this feature would be too convenient for people who have not yet come to understand the puzzle aspects of Factorio.

Nonsense. Making a functioning blacklisted filter line using the default whitelist inserter is pretty trivial, and not at all an interesting problem. You just need two additional belts and reverse the smart inserter. Done. How is this a "puzzle"? If you can't solve this rather trivial problem —turning a whitelisted filter into a blacklisted filter— then your factory is very likely to be deficient in many other ways, and having a blacklisted filter as an available tool is not going to solve your problems. You can throw all the tools you want at a bad design, and it will still be a bad design.

On the other hand, smart inserters are very good at solving a very present problem in Factorio: mixed ore lines. Mixed ore lines are not "bad design". Sometimes ores generate in such a way that it is a more elegant and more productive solution to mine the mixed patches and filter out the unwanted product, than to try to place your miners where you are guaranteed a pure ore line, especially since the output of the resource is proportional to how many miners you can place on the patch. Yes, you can use a smart filter to filter for the specific bad product, but it is conceptually simpler to say, "this inserter filters out stuff that is not coal from my line". Also, a blacklisted inserter would make the design more robust— you can filter out bad product for further sorting to another feed which will be able to process it properly, all without changing the setting on the filter. Having a factory that is robust to bad input is actually good design. (I remember one mod [whose name escapes me at the moment] even has vanilla ore patches occasionally produce side products, so it is not inconceivable that such a thing may happen in vanilla Factorio. In such prospective versions, ore line filtering would be vital.)

Nukem950 had another suggestion for a blacklisted inserter: loading a train car with product at the same time you're unloading another product. Again, you can solve this by whitelisted inserters simply not including the outgoing product in your whitelists, but the number of inserters available to this task is limited. Blacklisted inserters are able to pull everything that is not outgoing product out of the car for later sorting, without restricting them to a limited whitelist, so you're able to load the car faster and send the train on its way quicker.

Which leads us to another place where blacklisted inserters are useful: Your own example. Yes, you can set one of the inserters to filter for the one product on the belt and its mate for the other product, but conceptually it's simpler for one inserter to have a whitelist and the other to be a blacklist. It's also simpler to set up: just copy the settings to the other inserter, and change one of them to blacklist mode. Blacklisting also makes it a general filter. Yes, there's no reason to deliberately put more than one product on one side of a belt, but it can happen anyways (like accidentally rotating a belt a way it shouldn't, sending its product onto a nearby belt, or the aforementioned mixed ore line), and proper general filters can help make a more robust factory. Robustness is good.

This brings me to the final use for the blacklisting filter: with general filters possible, it makes possible the ultimate luxury early game, the dump chest. It's the place for you to dump your excess inventory and let the attached sorting system figure out where to put all that stuff. As such, a dump chest line can contain anything (it wouldn't be a proper dump chest sorter otherwise), so it needs a general filter to work robustly. In the logistic robot age, this will be replaced by the active provider chest and logistic robot swarms, but blacklisted filters are essential for the early-game version.

Khyron, while I see your point about the puzzle solving aspect of Factorio, quality-of-life improvements are also important. Being able to set smart filters to use a blacklist are a good quality-of-life enhancement, and is a logical extension of the normal whitelist. I have no objections to the blacklist capability being a later enhancement to smart filters that you must research in order to unlock, or if the inclusion is saved for the beta version of Factorio, it really doesn't make sense that smart inserters can have whitelists but not blacklists. And no, pointing out the puzzle solving aspect of Factorio does not wash with me, because then you'd have to explain to me why we have long-handed and fast inserters. There's nothing that can be done with a fast or long-handed inserter that you cannot do with a regular inserter with a little more space, but we have them anyway. And do fast or long-handed inserters now make good factories out of bad factories because they exist? Why does your "make good factories out of bad" objection not apply to smart inserters themselves, since they allow mixed product on belts, too? No, no matter what your available parts, using them properly still takes thought. A bad factory design that blacklisted filters make workable will still be a bad factory design. The cure for bad factory designs remains the same.

[ssilk]

@all: To stop this discussion: The devs stated several times, that they don't want to include new basic mechanic, that can be built in another way. We can discuss, what "another way means" and how complicated that is, but in Germany we have a proverb: "Die Kraft des Faktischen" ("The power of facts"); which means, that reality is stronger, then any logical argument.

The game itself might already allow to mod them as "not-filter".

[Khyron]

Nonsense. Making a functioning blacklisted filter line using the default whitelist inserter is pretty trivial, and not at all an interesting problem. You just need two additional belts and reverse the smart inserter. Done. How is this a "puzzle"?

I think you misunderstood what I'm referring to as the puzzle. The filter is not the solution to the puzzle. The puzzle is the upstream problem that leads you to think a filter is the solution. The puzzle is: it's possible to have a working factory without a filter, so where have I gone wrong in my design that I now seem to need a filter?

The example filter I linked to is not an absolute filter, and I'm only arguing the case that the game does not need and should not provide an absolute filter. It's perfectly fine to use smart inserters to make a filter-like mechanism because it has limitations. The absolute filter has no limitations. See the difference?

In the rest of your post you explained situations where a filter would be advantageous but not requisite. The usefulness is not in question.

@ssilk:
I'm not entirely clear on what you meant, but since you didn't lock this thread I assume it's OK to keep talking amongst ourselves, even if the devs aren't listening...

[ofca]

One can argue that even using smart inserters might be a bad design, and even normal inserters are smart behind the scenes when connecting assemblies. Currently making an "absolute" filter consists of stacking few smart inserters together, connecting them to active provider chests and determining what 5 things you don't want might end up on the belt. This doesn't prevent accidental and unexpected stuff making it's way through. You obviously may solve this with

Code: Select all

 /==============
 |      SSSSSSSS
== A[I]================
 |      SSSSSSSS
 \==============
I - normal inserter
A - active provider chest
S - smart inserter configured to grab stuff you want

This won't even impact belts throughput and that's my go-to absolute filter these days