Factorio Forums

Hi,

I think I found a bug about splitters (or I just don't fully understand how they should work) :
When I have full compressed input belts (a blue, express belt and a red, fast belt) the output (also a blue and a red one) is not fully compressed anymore, even when the splitter should support this throughput (i think) : When I update some of the red belts (not all, so the throughput is still limited to a red belt) it resolves this issue. Note that I must upgrade at least 3 belts to let this work, even with 1 or 2 blue belts this keeps happening. I can replicate this problem, But i'm not sure if this is a bug.
I just try to help as showing my support for this amazing game,
Lovely Santa

Splitters logics has been greately revised in belts optimization (comes 0.16). One particular thing about splitters - they allowed more items to be stored inside than regular belts (i.e. sequence of splitters allow to pack more items inside than same sequence of belts). Another thing - there were two bugs about splitters spotted during that optimization. One - splitters had incorrect recursion order, so that may have caused decompression at output. Second - switching inputs was caused by any movement of input transport line, not just the act of throwing an item from input to output. All of this should change with 0.16

Thanks for the quick answer,
I'll stick with the 3 blue belts in front as solution.

Lovely santa

Harkonnen wrote:Splitters logics has been greately revised in belts optimization (comes 0.16). One particular thing about splitters - they allowed more items to be stored inside than regular belts (i.e. sequence of splitters allow to pack more items inside than same sequence of belts). Another thing - there were two bugs about splitters spotted during that optimization. One - splitters had incorrect recursion order, so that may have caused decompression at output. Second - switching inputs was caused by any movement of input transport line, not just the act of throwing an item from input to output. All of this should change with 0.16

So no chance to get belts optimization in for 0.15 ?

Harkonnen wrote:Splitters logics has been greately revised in belts optimization (comes 0.16). One particular thing about splitters - they allowed more items to be stored inside than regular belts (i.e. sequence of splitters allow to pack more items inside than same sequence of belts). Another thing - there were two bugs about splitters spotted during that optimization. One - splitters had incorrect recursion order, so that may have caused decompression at output. Second - switching inputs was caused by any movement of input transport line, not just the act of throwing an item from input to output. All of this should change with 0.16

Did you also fix the issue where splitting a compressed belt causes 1 lane to go left, and 1 lane to go right?

orzelek
It's very desync-prone optimization, just because of how much stuff it touches. Not that many of them happened, I am just very scared of that, so belts optimization comes in only when all major bugs are gone, otherwise it will be very hard to tell what have caused just another problem.

Zeblote
That might be the case with splitter changing input/output lines logics - should be fixed. Famous splitter filtering thing still should be operational though.

Harkonnen wrote:Zeblote
That might be the case with splitter changing input/output lines logics - should be fixed. Famous splitter filtering thing still should be operational though.

Did you change the splitter to split each lane separately? Been waiting for that change since quite a long time...

Each lane is split separately already. lefts to lefts, rights to rights. there is per-item-type stats to balance outputs, and logics (which had bug on sparse transport lines) to handle inputs. I will check your example to see why it behaves like this.

Harkonnen wrote:Each lane is split separately already. lefts to lefts, rights to rights. there is per-item-type stats to balance outputs, and logics (which had bug on sparse transport lines) to handle inputs. I will check your example to see why it behaves like this.

I didn't test in 0.15 specifically, but in 0.14 (where I took the screenshot) it was not the case.
It was only per-item-type, with both lanes being split together. So the 1-left 1-right logic causes all the left lane items to go to the left belt and all the right lane items to go to the right belt.
(Your belt has to be fully compressed to replicate the issue)

If it's now per-lane, per-item-type, that's perfect

My belts branch gives some weird results, and still not what you meant I will investigate why that happens.
Still, I am afraid to touch this logics because filtering items with splitter has become somewhat popular contraption, and this behavior has direct connection to it.

I don't think changing it to per-lane, per-item-type will prevent those contraptions from working. You'd just have to prime each lane separately, then you got an even better filter

lovely_santa
On how splitters operate internally - express splitter technically consists of 4 express transport belts 0.5 tiles long, but this is not the real cause of the problem. Let's suppose that express-belt moves items 0.3 units per tick and fast-belt moves items 0.2 units per tick (actual numbers are different). Whenever item crosses boundary between consecutive belts (or between splitter and belt) it makes part of its movement along current belt, and applies residual movement onto next belt it was put onto. So for example if item is 0.1 units to the end of express-belt, it will be put 0.2 units from the beginning of the next belt or closer if there is no space for it.(in my belts-optimization branch this is also compensated for speed difference, but this does not matter here).

So now about splitter throughput - you have 0.3 speed for left/right primary line and 0.3 speed for secondary left/right line, so total throughput is 0.6 units of movement per tick for left lines + 0.6 units of movement per tick for right lines. From now on speaking about left lines - they are independent from right ones in terms of throughput. Each time you get item thrown from express part to fast part - you loose part of that residual movement because items on red belts do not advance fast enough. E.g. you were about to move item 0.3 units from express belt, item was 0.1 units from its end, but nearest item on next red belt is just 0.05 units ahead, so overall movement becomes 0.15 units instead of full-fledged 0.3, and the other 0.15 is the wasted throughput which results in gaps on express side. Solution could be keeping this unused residual movement to augment the other output of splitter, but this doesn't look quite logical to me because that will cause items in that direction to propagate through splitter at speed faster than express belt - for example if you would setup everything with blue belts (two inputs, two outputs), but secondary output is clogged up, then primary output would receive double speed as items leave the splitter fed from both inputs.

Zeblote
On your part - splitter balances outputs by tracking how much items of each item type has passed to primary and secondary part and balances on that thing. The reason you get pictures like this is that this counter is cumulative for left and right lanes, so when you send fully compressed belt into splitter with same items on both sides, you start getting left-primary/right-secondary alternating pattern. This could be solved by making these counters distinct for left and right lanes, but that would break XKnight splitter filters from here 19114 because this is the feature they actually exploit. "Priming" wouldn't help because these counters are limited to 5.

Could this be also a reason for this strange behavior?
top input belt has 100% throughput while the bottom lane has the same throughput as the top output belt. (red belt)
this happens only sometimes by chance after stacking items up and releasing them again.