[0.10.9] splitter priority when joining

[arl85]

Probably a know problem, but still I prefer to report result of my (small) test.

Usually splitter prefers left input for joining, but in two specific configurations it prefers Right one.


(letter next to exit transport belt is the side that have priority)

[BurnHard]

I have also observed that the prefered input side of your examples sometimes change if one or the other tile directly before the splitters are curved or not. A lot of possible combinations with not really predictable behaviour.

[Rseding91]

I'm not sure I understand what you're saying is broken. Are you sure it's not because you're using splitters as joiners? (to me) splitters are meant to split income onto both output belts not join income onto one output belt (and that's why the results seem strange to you).

[arl85]

I'm not sure I understand what you're saying is broken. Are you sure it's not because you're using splitters as joiners? (to me) splitters are meant to split income onto both output belts not join income onto one output belt (and that's why the results seem strange to you).

I found lot of suggestion about using splitters as joiners, and almost all of them said that, in that case, left input is preferred. I'm just reporting that this is not always true.

I'm not sure it's a bug, because, as you said, splitters are used as joiners, so maybe this is not their role

[ssilk]

I've been looking quite a while now, why in some situations the splitters (in that case the joiners) seem to prefer the other side. I never came to the idea to systematically test it. The pic above makes sense!

Many thanks for the work!

In my eyes this should work either
- only one side (the left) is prefered or
- the connected side (the side where the single belt continues) is prefered.

I think the last option is in some cases more useful (and eventually more intuitive?) cause it enables the player to switch priorities.

[DaveMcW]

The workaround is to use blue joiners, and only on belts going down or to the left.

blue-merger.jpg (261.78 KiB) Viewed 9135 times

[ssilk]

Indeed, I can think that it is useful that the blue splitters behave so, that they equally join. But it is very questionable. It's in my eyes really a quite useful behavior, that splitters do prefer one side and for that, every splitter should behave in the same way.

[DaveMcW]

Red joiners also work going to the left.

red-joiner.jpg (262.43 KiB) Viewed 9111 times

[ssilk]

Stupid suggestion: If I plug the output to the left side it prefers the left input. If I plug it to the right it tries to output equally from both inputs.

[kovarex]

Well, currently the priority of joining is not defined explicitely. Sometimes the side that is joined to is always preferred because the side can move, so the items on that side are the first to be picked after free space is created for another item. But it can really depend on the way the items are put on the belt.

I'm moving it to not a bug for now.

[DaveMcW]

It turns out exactly 50% of express splitters will join correctly. At least one tile of the splitter must be in the same 2x2 block as the output.

I have made red and yellow splitters join correctly, but the chance is much less than 50% and I'm still trying to figure out the exact formula.

joiner-horizontal.jpg (138.54 KiB) Viewed 9217 times

joiner-vertical.jpg (135.77 KiB) Viewed 9217 times

[ssilk]

Wow. This is amazing. And it makes totally sense. One off and the splitter behaves differently. Quite useful, if you know it.

Why didn't I see that myself?

And how could I explain that in the wiki?

EDIT: This thread brought me to the point, that I now will test this completely through and make the results repeatable, so that it can be documented.

[micomico]

Wow. This is amazing. And it makes totally sense. One off and the splitter behaves differently. Quite useful, if you know it.

Why didn't I see that myself?

And how could I explain that in the wiki?

EDIT: This thread brought me to the point, that I now will test this completely through and make the results repeatable, so that it can be documented.

Well, this looks more like a bug to me than ever.

So, players are supposed to know about imaginary 2x2 blocks, in which splitters will work as predicted? Predicted, because most people with common sense will expect the joiner to pickup both inputs equally, even if you say that should not be the case.

The way I see it, even if you say explicitly that splitters will not work as perfect joiners, my reaction would be: "Why not, you lazy bastards...", which you're not, quite the opposite.

[kovarex]

But there are fundamental problems with equal joining. How exactly will you define it?

Once you have available item to move to the belt on left belt, you would have to wait, if some other item on the right belt don't arrive, as it would be the time for the right belt to be activated.

But how long do you wait? And once you wait you limit the throughout of the splitter.

[micomico]

I understand that speaking/writing is so much easier than coding. I was just expressing what I would think, if I was watching this behaviour as a new player.

I would expect that, given a clear output belt and constant input from both belts, the output would be perfectly balanced. Like splitters do when splitting. Of course, this might be impossible/too complex for the real returns obtained, to actually code it.

[Boogieman14]

But how long do you wait? And once you wait you limit the throughout of the splitter.

How about no waiting, but simply checking both inputs in turn? If an item isn't readily available, just forward an item from the other input.

[kovarex]

Well, maybe something that works quite ok might be done without too big of an effort, the splitter does the update of the left side and then on the right side.

It could remember the few last items balance of left/right and prioritize the one that was used less when moving items. That way it would probably work, but I would have to play with the details, definitelly this is not solving of a bug, but adding a new logic/feature, so it will be not solved for 0.10.x

[ssilk]

I've made a test, to prove the different theories, one test looks like so:

SplitterTesting.jpg (364.85 KiB) Viewed 9193 times

These are 8 test-drives, I place coal and alien eggs (due to the good visibility) on a belt, compress the stuff, so that it should be really one on one and then put it into a splitter and join that. The top row joins to the right belt, the lower row to the left. The other difference is the placing on even or odd tiles. See the rail-segments I placed besides the splitter, to understand that.

So I've 4 of those "tests" (one for every direction) and two extra double tests. All in all 48 test-drives. Didn't had enough resources left to make more.
I tried that also with faster belts (not in the save), and the result is about the same, even more complex.

What I can see is:
- Well, there are tendencies. A splitter to the left or up tends to join from the right side, to right or down from the left side. This matches fantastic with the inserter preferences (https://forums.factorio.com/wiki/inde ... =Inserters - top orientation for horizontal belts, or the left for vertical belts).
- There is no real dependency to the even tiles (look at the rails I placed near the splitter). I would say forget that idea...

Rules?

Found no rules. When you load the Splitter Testing Savegame and watch these test-drives a while, the picture changes. All the time.I think it is as Kovarex says: The result depends on how the items come into the splitter. So the dependency is, how the items are laying on the belts before the come into the splitter and when will the splitter look for the next time and when will the item before leave the placing-zone of the splitter?

More ideas how to see more:
- Adding faster belt after splitter or before only.
- Perhaps something without compression?
- taking randomly some item away from one side (inserter) to change the "order how the items are coming in".
- Add different tests, that show, that these test-drives are correct (or complete bullshit)

Maybe this savegame helps to stabilize this complex behavior, or someone finds a rule or so?


EDIT: I saw that this screenshoot is a bit too old, cause there are not all coal chests filled. This doesn't matter, even with full chests the picture is about the same.

[DaveMcW]

It looks like south and east splitters don't work unless they are express and share a 2x2 square.

North and west splitters always work if they share a 2x2 square.