When you side load a belt, the side loaded belt cannot achieve maximum throughput. This is not mentioned in the info database - not clear if this is purposeful or bug.
To emphasize this, when a priority splitter input is sideloaded the timing results in using the secondary input as the primary.
If sideloading is intended to result in a loss of throughput, this should be added to the info database and clarified.
#Sideloading cannot achieve max throughput /Priority Splitter & Sideloading doesn't prioritize.
1 messages · Page 1 of 1 (latest)
The problem of side loading is...
The main belt is keeping the distances between items. If between such a gap another item doesn't fit or the gap is not exactly the multiple of a round number of items' length, the main line will keep small gaps between items.
With a balancer an item on the "main line" will be stopped for a fraction of a second to allow an item from the "secondary" line to squeeze itself into the resulting material flow.
I guess this behaviour is intended. But you are right it should be mentioned in the tutorial pictures.
the part that messes with me and why i flagged it as a bug, if you side load it at all, it doesn't get to max rate
so not even with sideloading a in use line, but an empty line it can't handle a full belt
so these are from creative/void chests to make testing easier, but the side loaded belt isn't able to get to 640. This can be checked fairly easily by building up some items in a chest and sending it to a void chest with the same belt count. in=out it should maintain a quantity in the intermediary chest. if it goes down it's input is less, and goes up input is more.
the balancer is an odd case because in reality it should work, but because side loading has no priority it locks up in a weird way. but primarily it's making sure everyone is aware that side loading doesn't work if you need/want max throughput
you want to know the really weird thing. Side loading is prioritized by what is the oldest belt present. If two same placed belts have incorrect priority, just delete the belt you don't want with feeding priority and replace it - it'll go last.
That's what I would call a serious bug. It's not visible what belt is placed last.
Version 0.5.2.16455 - 1177434657
Think it makes sense. The gap situation doesn't apply, but you still have the time for the piece to move out of the way of the next piece before the next piece can start moving onto the belt. And the first piece moves a bit down the line before the following piece gets fully onto the conveyor, thus creating a small gap.