[2.0.43] Splitter with filter causes inserters to be unable to pick up item

[FactorioFan822]

I have noticed many strange quantum bugs with inserters lately, but here is a very clear-cut, demonstrable case of what I think is a bug.

04-09-2025, 02-18-16.png (503.73 KiB) Viewed 460 times

Allow me to explain. Notice the barely-visible Jellynuts sitting at the filter? One of the two inserters should be able to pick them up, yet neither of the inserters are interested.

All the settings on the inserters and the chests are pure defaults, no filters or anything weird.

I think what is happening is that the Jellynuts are "scheduled" to move over to the right side of the filter and exit there, and somehow that is confusing the game.

If this is somehow an intended behavior, allow me to protest. The items are clearly visible on the left side of the splitter still, my inserter is clearly there, it should pick up the item. For this item to be displayed as available yet magically locked violates basic WYSIWYG principles of base design, and in this case caused an entirely unexpected (and hard to diagnose) stalemate in my production line, as it is sure to do for many future players as well.

In this case my intended behavior is to block and wait (and allow to pick up) non-expired fruit, while moving along expired trash to be burnt. Here is the full setup, as well as a demonstration what the deadlock looks like.

04-09-2025, 02-31-40.png (2.51 MiB) Viewed 460 times

No mods, vanilla Space Age, 2.0.43 (build 82163, win64, steam, space-age)

Savefile: https://drive.google.com/file/d/1argZxl ... sp=sharing

Logfile attached.

[boskid]

I see no bugs here. Inserters are specifically made to only grab from the output lines of a splitter so in case of filters they only grab what already passed the splitter filter. Items you see the spoilage bar are still on the input side being blocked waiting for space on the other side output, they are just quite unfortunately far down making the bar not covered by splitter structure

[FactorioFan822]

If that is the case items ought not enter the splitter at all unless there is room for them at their output lane, so that they remain grabbable in the previous tile, or enter into the splitter immediately into a state where they are grabbable as well.

Items entering a state where they are permanently ungrabbable can't be the intended outcome, surely?

[boskid]

When items are inserted into a splitter, they go into the input lines(asterisk: depends on drop point) so they can be filtered to the correct output. When items are taken out of a splitter they are taken from the output lines. Splitter is 1 tile long and both input and output lines are half a tile long (asterisk: inputs are slightly longer). Items can enter position over a splitter because the real splitter has no length and is located 0.5 tile after beginning of input lines. I wont change anything here because that would significantly change splitter behavior when inserters are taking items out from them as right now taking items respects the filters and with your proposed change inserters taking items from a splitter would take not only the output items but also input items that could be unfiltered yet. Your setup is inherently faulty because one of the outputs you have is blocked and your inserter takes items only from the output part where a spoilage only is expected.

[FactorioFan822]

Sir, my setup is based on the very reasonable assumption that an inserter is able to pick up any item that is laying on a tile from which the inserter is picking up items from. To call that "inherently faulty" is rich, when it's based on a what-you-see-is-what-you-get cause and effect assumption that is:
* Based on intuitive, natural logic derived from how humans interact with the real world
* True in every single situation I have encountered in my many many years of playing this game, except in this one single edge-case

I understand that you are defensive about your implementation, but your implementation violates reasonable user assumptions and the in-game logic that applies in every other scenario.

It is understandable that you are now unwilling to change this implementation now because it will cause a sudden logic change in the game, from one version to another.

But it's quite simply rude for you to call my surprise at this violation of game logic "inherently faulty", when it is your unfortunate implementation that has caused this violation. Your ego should not be a reason for you to refuse to acknowledge the flaws created here.

[boskid]

It is possible i slightly miscommunicated my reasons why i am not considering this to be a bug. This behavior was there for a really long time to the point i expect players may be used to it and changing this behavior would break valid existing save files just because inserter would now start grabbing items that do not match splitter filters. There are 2 possible outcomes for inserter taking from the splitter: either it takes from output lines only so the items are filtered based on splitter filter, or it takes items from input AND output lines and so the splitter starts behaving randomly because it will correctly take filtered items that entered a splitter also when feeding from the other input, but it would also provide items that happened to be on the input of this splitter side but happened to not be filtered yet. I am not considering your use case to be significant enough to make the change because i see how other players would report the new behavior as being a faulty one.

Example of other players save files i have on my disk that this change in behavior would cause a behavior change:

05-04-2025, 13-37-01.png (604.28 KiB) Viewed 237 times

05-04-2025, 13-33-08.png (500.16 KiB) Viewed 237 times

05-04-2025, 13-34-41.png (493.4 KiB) Viewed 237 times

05-04-2025, 13-51-02.png (628.24 KiB) Viewed 237 times

05-04-2025, 13-53-40.png (420.4 KiB) Viewed 237 times

Even your own save file would be affected:

05-04-2025, 13-44-51.png (550.74 KiB) Viewed 237 times

So if i can avoid breaking people's save files by not introducing a change in the behavior that is reasonable and they rely on, even if that means being on the receiving end of personal attacks, i will take that. Just in case i will raise this topic on our internal meeting to see if other devs agree or disagree, but given that this change would break existing save files and would introduce an additional complexity in inserter logic causing slight performance drop, it is quite unlikely to be changed to what you would like it to be.

[computeraddict]

Adding my hat to the "not a bug" ring. Not being able to get the benefit of a filtered splitter until the following tile would absolutely suck.