[0.10.9] splitter priority when joining

[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 9194 times

joiner-vertical.jpg (135.77 KiB) Viewed 9194 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 9170 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.