[2.0.14] Inserting onto splitter no longer saturates both output belts

[mwls]

Hi, I noticed this difference between Factorio 1 and 2. I'm not sure whether this was an intentional change, or an unintentional side effect of some other change, and whether it's considered a bug or is intended to be the new behavior, but I thought I'd report it. Designs like these relied on the old behavior in order to get more items out of a single inserter onto belts more quickly.

• What did you do?
  Set up an inserter to insert onto the side of a splitter, as shown in the wiki here: https://wiki.factorio.com/Inserters#Chest_to_splitter
• What happened?
  The inserter dropped items onto the splitter such that they came out on each belt at approximately 66% compression.
• What did you expect to happen instead?
  For the items to come out on both belts fully compressed, like they did in Factorio 1.
• Does it happen always, once, or sometimes?
  Always.

[boskid]

Thanks for the report however this is not a bug.

This behavior was a bug in 1.1 where items inserted onto a splitter were put at incorrect positions of a transport line causing them to be inserted at the end of transport line wher a splitting logic was happening. That meant that within 1 tick the item would move past the splitter so a second item was able to be inserted in the next tick and also be handled within 1 tick. When i fixed the positions of item insertions onto transport lines, now they are inserted at a point 0.2 tile away from the head of the transport line and so when item is moving towards the end of line where a split happens a subsequent items are not possible to be inserted.

If this would be decided to be an expected behavior i could make this broken again but then it will be broken again. Unfortunately splitters have input lines of length 0.7 so the middle point where items are inserted are exactly 0.2 tiles away from the point at which splitter acts upon.

[mwls]

Thank you for the explanation.

I did notice that when inserting onto Turbo splitters the output does end up being fully compressed. Turbo belts move 0.125 tiles per tick (versus express belts' 0.09375 tiles per tick), so it seems like there's some complexity with the order that things happen on each tick that I don't fully understand to allow items to clear the Turbo splitter input within a tick, but at least that allows designs like the one I mentioned above to still be possible in a Space Age playthrough.

This behavior was a bug in 1.1 where items inserted onto a splitter were put at incorrect positions of a transport line causing them to be inserted at the end of transport line wher a splitting logic was happening.

May I ask how this bug was noticed or prioritized for fixing? I'm curious if the incorrect insertion position had other ramifications that aren't obvious to me.

[Acid_Burn9]

If this would be decided to be an expected behavior i could make this broken again but then it will be broken again.

I would appreciate it if you broke it back. (or messed with the splitter logic to re-create this accidental feature properly)

It wasn't even OP since you still had to fit a splitter in the space which is twice as big as a belt to get the double offloading speed bonus, which seems like a reasonable tradeoff. It was just a satisfying trick to use and to be honest it felt like an intuitively expected behavior, at least for me. Splitter allows an inserter to access 2 lanes at once, so it only makes sense that it would get double the offloading speed. Current behavior not only makes less sense IMO, but is also inconsistent across different belt tiers. (literally unplayable)

AVADII made a nice video demonstration of these inconsistencies.
https://youtu.be/3iVuNEElaxc

[feffy]

The inconsistent differences in throughput between tiers is what makes this feel strange.
Turbo: buff
Express: buff
Fast: no change???
Basic: buff

[TurningGears]

I also have a lot of builds relying on the mechanic to fill two lanes at once. This is also still the case on green splitters. If green splitters are still bugged, I think they should also get fixed or (my preferred solution) introduce the feature (not a bug ) back into the other splitters.

[kitters]

This really made me mad, searched forum, find this in 'not a bug'. What a joke.
I wouldn't expect this to be fixed. Sounds like massive code rewriting, and they don't like to resolve problem in other way even if their solution caused massive complaints (like fluid update). And we are here just a few guys.

[AVADII]

I think one of these 3 solutions should be implemented for all belt tiers consistently:

1) Either all splitter tiers should behave like the turbo splitter, 2x throughput and both output lanes saturated like in 1.1
2) or behave like the fast splitter now, normal throughput and split action, just as if you inserted into a regular belt before the splitter
3) or kill this entire concept and make it so that items don't go through the splitter action at all, just like when inserting from behind the splitter

I'm not a game designer and I don't have an opinion what's best for the meta of the game.
But i think it should be the same behaviour for all tiers.

[Loewchen]

If you want to make a suggestion about this open a topic here: viewforum.php?f=6.

[Loewchen]

Use one tier above splitter for three first tiers of belts to get 1.1 unbroken effect of packing tightly both belts through a splitter by an inserter. Last tier (4, turbo) works as earlier 1.1 now, as some of you mentioned. So, all problems solved.