Splitter not working properly

[SPolygon]

Ok, so I have 1 input belt and 1 output belt. I used splitter to balance input lanes. I thought that splitter works like this; 1 item left, 1 item right, 1 item left etc. But what happened; 2 items left, 2 items right, yea, the splitter splits couples, not a single items. Picture:



I know, it's still pretty much 50:50, but in some cases (when fully loaded train arrives for example) it can do some unwanted stuff.

IDK, maybe this is how splitter work, anyway I never before noticed that :/

[Klonan]

I think the splitter works by splitting each 'lane' 50/50 to eachside, and by looking at it, your copper and come in on opposite lanes.

So if you imagine, the1st item on the left lane goes to the left lane of the bottom belt, 2nd item on the left lane goes to the left lane of the top belt. This might not be true for all cases, but it explains why both your items wen to the same output belt initially

[SPolygon]

OK, now I see that Anyway, how do I split 1 input to 1 output without this happening

EDIT: now I noticed the same thing happening with 1 lane only splitter, when there are 2 same items next to each other, splitter send them to same output thus not splitting them

Btw.: tnx for quic answer

[daniel34]

I think Klonan's answer is only partially correct, the reason both ended up on the bottom belt is because Splitters work per item:

(the same would have happened if both ores were on the same lane of the belt)

[vanatteveldt]

Interesting design choice, I would have expected either a single "memory slot" or a slot per lane, not per item type.

(Note that I found the statement "Splitters work per item" confusing, I would have said "Splitters work per item type")

[SPolygon]

OH, so they work per item type, iteresting, complicated, but useful

[XKnight]

I started to think about this wonderful splitter's ability and realised that it is possible to implement item filtering without any inserters, using only splitters and belts.
So...

Filter

1.png (309.34 KiB) Viewed 67251 times

And example:

Test input

2.png (579.92 KiB) Viewed 67251 times

Result

3.png (416.14 KiB) Viewed 67251 times

Perfect!

Also, this setup has several limitations:
- it works efficiently only with yellow/red belts and red/blue splitters
- only with one belt-line
- doesn't support full compression

[ssilk]

It surprises me all the time, how the belts can be "missused" to make something cool. Good find.

[XKnight]

It surprises me all the time, how the belts can be "missused" to make something cool. Good find.

Could you share links to other interesting belt usages?

[Koub]

[XKnight]

Animation.gif (14.3 MiB) Viewed 65569 times

[rk84]

That is cool. I was bit confused until i saw those items in closed loops.

Old bug report about splitter's "feature" and counters getting tweaked:
[Resolved 0.3.2] Splitter error - not splitting

[vanatteveldt]

Pure curiosity, but is there any word on why splitters would have such a complicated memory setup (a counter of up to five per item type, with past unbalance compensated when a lane gets free)?

I would have just put a single boolean to remember if the next item should go left or right, certainly given that a splitter is not even supposed to be smart (no electricity usage -- although it does use an electric circuit, there's something magical going on there )

I can imagine that it is "nice" that lanes balance out even if they were clogged up, but isn't it the player's fault if s/he lets a lane clog up? And anyway, I would have expected that a basic splitter just does a left/right alternation, with optionally a "smart splitter" doing more advanced balancing stuff (requiring electricity, possibly allowing some sort of control via circuits - maybe the ability to close either exit with a signal to allow balancing based on e.g. the amount of items downstream?)

[ratchetfreak]

If you have an item per lane then in the plain alternation each belt tends to only get one item. One of the output belts needs to backlog until a good split is achieved

[vanatteveldt]

Right, so I guess a boolean state per lane would be needed. But that should be enough to function properly, right?

[Zeblote]

The way it works now also produces nonsense like this on compressed belts:



But appearantly that is how the devs want it to look. https://forums.factorio.com/forum/vie ... 23&t=16801

[XKnight]

Don't even ask "why?"

Animation2.gif (6.01 MiB) Viewed 65743 times

[RavenHexx]

This is just beautiful

[vanatteveldt]

Okay, I officially don't get it. Why does the second splitter produce such a neat sorted pair? How can the "symmetric" rule that keeps track of a side per type give an "assymetric" outcome?

Or does it depend on the order of the input ?

[daniel34]

Okay, I officially don't get it. Why does the second splitter produce such a neat sorted pair? How can the "symmetric" rule that keeps track of a side per type give an "assymetric" outcome?

Or does it depend on the order of the input ?

Note that at first the items are all on the top lane (what I will now call left, as seen from the belt direction).
The first splitter that then sideloads from the right onto the belt makes it so that the iron (or any other item) alternates from the left lane to the right. That is because one item stays on the belt, the next gets sideloaded, the next one stays on the belt, the next gets sideloaded, ...
Now the belt is doubled using a splitter, then you have the iron on the outside lanes and the copper on the inside lanes because the right-left altering items are distributed by the splitter so that the left items go to the top belt and the right items to the bottom belt (for iron, for copper it is the opposite).
Then you only need to get the lanes to go to the same side of the belt, this is done by using the underground belt trick (if you fill it from the side only one lane gets through, the other one is blocked).

It doesn't depend on the order of input. That's actually the whole point: to separate a belt with arbitrary input of 2 item types into a belt where the item types are ordered by lane, no matter what input is given.

I hope that explains it good enough to understand it, it seems a little long and confusing written out.