Combining, Splitting, and Balancing Large Numbers of Belts

[eradicator]

I have to admit i expected splitters not to properly split when there's not enough input to compress all outputs. I expected that the first loader would grab all the input and the other two would go empty. But alas it magically works:

balance.jpg (134.66 KiB) Viewed 10709 times

[Optera]

I just ran 3 different 4x4 balancer builds through 10k ticks benchmarks and the results where surprisingly definite.

The setups:

2018-07-07-16-02-03-2543866.jpg (184.06 KiB) Viewed 10708 times

Results:
splitter: 0.315 ms/tick
loader: 0.260 ms/tick
miniloader: 0.171 ms/tick

Conclusion:
Miniloader are nearly twice as ups friendly as splitter based balancers with loader somewhere in the middle.
For larger balancers the advantages of loader and especially miniloaders will only increase. Next time I need a 16x16 balancer slapping miniloaders next to a wide chest is the way to go.

Sidenote:
Only the splitter build is count perfect. The loaders distribute according to build order and chunk update.

[eradicator]

Results:
splitter: 0.315 ms/tick
loader: 0.260 ms/tick
miniloader: 0.171 ms/tick

Not too suprised about splitters being last, after all they have to do per-lane logic and count-precision splitting etc. Loaders being that much slower than inserters ... i guess they never get any optimization love.

[darkfrei]

And what about script-based inserter/loader?
On tick
If in this place we have item on the ground an we have place inside the chest, then insert the copied item and delete old entity.

[eradicator]

Hm. Fiddling inserters into the right position is a bit tricky... but i'd say n-belt-splitters should be moddable then, even with filtering.

fiddle.jpg (73.47 KiB) Viewed 6667 times

[Optera]

And what about script-based inserter/loader?
On tick
If in this place we have item on the ground an we have place inside the chest, then insert the copied item and delete old entity.

Scripted on-tick will be several magnitudes less efficient than anything using native entities.
You can see this when loader redux is used to fill/empty wagons.

I guess this demonstrates how optimized inserter-belt and inserter-chest interactions actually are.

[eradicator]

Loaders have one benefit over inserters though. They can "bend" belts into them, which looks nicer. Inserters on the other hand could have 5 filters per lane.
(Upper is 3-wide-chest, lower is 1x1 chest)

nanoloader.jpg (229.41 KiB) Viewed 6655 times

[Therax]

Scripted on-tick will be several magnitudes less efficient than anything using native entities.
You can see this when loader redux is used to fill/empty wagons.

Indeed, this is why I created miniloaders in the first place.

Loaders have one benefit over inserters though. They can "bend" belts into them, which looks nicer. Inserters on the other hand could have 5 filters per lane.
(Upper is 3-wide-chest, lower is 1x1 chest)

Note that miniloaders are actually 3 entities, 2 inserters and a loader. The loader is only present for belt connectivity, and doesn't move any items under normal circumstances. A 3-way splitter along the same lines is doable and would retain the performance, circuit control, and filtering advantages of using inserters to actually do the item movement

The downside to inserters is that they have a hard cap at 1 item/tick (60 items/second) when taking from a single belt segment. According to Twinsen this is because all inserters select an item at the beginning of the tick, and then they all chase that item, but of course only one can successfully pick that one item up in a tick. Bob's top tier belts move items at 5x yellow speed, or 66.66... items/second, which makes miniloaders just barely not able to utilize them at full throughput in the belt->chest configuration. Tyarns' Ultimate Belts are even faster, which is why miniloaders has to use actual loader entities for them, losing filtering and circuit control capability as a result.

Side note:

I frequently use a Warehouse + miniloaders to make 6x6 balancers, or 6x(3x6) splitters, etc.

[eradicator]

losing filtering and circuit control capability as a result.

I'm not sure about circuit control...but loaders DO have filters. Just not seperated for each belt-lane, though i doubt mini loaders have that implemented?

Btw, how do mini-loaders handle stack-bonus? In the pictures two posts above (with the four stack inserters on a chest) it only barely worked if they had a stack size of 3, wich stack-size-override = 1 it was too slow on the input.

[Therax]

I'm not sure about circuit control...but loaders DO have filters. Just not seperated for each belt-lane, though i doubt mini loaders have that implemented?

Loader entities have 5 filters, but cannot be connected to a circuit network. It would be possible to implement per-lane filtering in miniloades, with custom GUI work.

Btw, how do mini-loaders handle stack-bonus? In the pictures two posts above (with the four stack inserters on a chest) it only barely worked if they had a stack size of 3, wich stack-size-override = 1 it was too slow on the input.

Miniloader inserters are locked to stack size 1, with very high arm movement speed.

[eradicator]

Ah. So they can't circuit :x.
Yea, that miniloaders "could be" per-lane filtered i said before, it was the "but does it?" part i didn't know.
Mine had speed = 0.99 (because i assumed float with max 1?), but i only tried for 5 minutes or so. Also...can you force inserters to only take from one lane? As far as i can tell you can only force one-sidedness on the output.
And those "inactive" loaders you tal about..are they simply speed = 0? Or active.false?

[Zavian]

Also...can you force inserters to only take from one lane? As far as i can tell you can only force one-sidedness on the output.

If you are loading from a chest/assembler then there is no pickup lane. If you are loading from belt, then I don't see that it matters which lane they pick up from, if they are emptying a full belt.

[eradicator]

Also...can you force inserters to only take from one lane? As far as i can tell you can only force one-sidedness on the output.

If you are loading from a chest/assembler then there is no pickup lane. If you are loading from belt, then I don't see that it matters which lane they pick up from, if they are emptying a full belt.

It matters for input filtering and fancy lane-aware splitters. Thank you. :/.

[Therax]

Mine had speed = 0.99 (because i assumed float with max 1?), but i only tried for 5 minutes or so.

I haven't actually tested, but my guess is that rotation_speed is in radians/tick, while extension_speed is in map tiles/tick, same as belt speeds. Just a guess though. Express Miniloader internal inserters have rotation_speed and extension_speed of 1.5. I force stack size of 1 so that output is appropriately evenly spaced, for example when power is low and the inserters slow down and can no longer keep up with the belt.

Also...can you force inserters to only take from one lane? As far as i can tell you can only force one-sidedness on the output.

My experiments suggest the same. If someone figures out a way to do this, I'd be happy to hear about it.

And those "inactive" loaders you tal about..are they simply speed = 0? Or active.false?

I set container_distance to 0. This way they fail to find a container to load/unload, which lets the engine put them to sleep permanently. However, they are still "active=true" and with the correct speed so that the visible belt fragment has the correct moving animation, and when backlogged, items "flow" into or out of the miniloader for some distance before reaching the end of the internal belt and stopping.

[mrvn]

Scripted on-tick will be several magnitudes less efficient than anything using native entities.
You can see this when loader redux is used to fill/empty wagons.

Indeed, this is why I created miniloaders in the first place.

Loaders have one benefit over inserters though. They can "bend" belts into them, which looks nicer. Inserters on the other hand could have 5 filters per lane.
(Upper is 3-wide-chest, lower is 1x1 chest)

Note that miniloaders are actually 3 entities, 2 inserters and a loader. The loader is only present for belt connectivity, and doesn't move any items under normal circumstances. A 3-way splitter along the same lines is doable and would retain the performance, circuit control, and filtering advantages of using inserters to actually do the item movement

The downside to inserters is that they have a hard cap at 1 item/tick (60 items/second) when taking from a single belt segment. According to Twinsen this is because all inserters select an item at the beginning of the tick, and then they all chase that item, but of course only one can successfully pick that one item up in a tick. Bob's top tier belts move items at 5x yellow speed, or 66.66... items/second, which makes miniloaders just barely not able to utilize them at full throughput in the belt->chest configuration. Tyarns' Ultimate Belts are even faster, which is why miniloaders has to use actual loader entities for them, losing filtering and circuit control capability as a result.

Side note:

I frequently use a Warehouse + miniloaders to make 6x6 balancers, or 6x(3x6) splitters, etc.

Unless you use the new 10/20/30/40/50/60 speed setting.

[eradicator]

(In the interest of not unnessecery dilluting your interface request i'll continue discussing here...)

I could use a loader to move items from a belt to a container in the same map tile as the loader, then use an inserter to transfer from the container to the target cargo wagon. Currently, it is impossible to reliably set up an inserter with the container as its pickup_target, instead of accidentally having it select the loader or other belt entity in the same tile.

I wasn't even aware inserters can pick up from loaders. And i don't know too much about inserters. But don't they select their pickup_target based on the pickup vector and collision box? If yes then you should be able to achieve 1x3 by having loaders without a collison_box. So maybe the real problem is the inserters ability to deviate from it's original drop/pickup target (does it even? or does it just look like that because collision_"boxes" are not collision_"points")?

Sidenote: Bilka posted another mysterious interface request which - depending on what he actually requested - might or might not enable inserters picking up only from one belt lane.

[Therax]

But don't they select their pickup_target based on the pickup vector and collision box? If yes then you should be able to achieve 1x3 by having loaders without a collison_box. So maybe the real problem is the inserters ability to deviate from it's original drop/pickup target (does it even? or does it just look like that because collision_"boxes" are not collision_"points")?

If you try to create a loader with no collision_box, you get the following:

Code: Select all

Error while loading entity prototype "miniloader-loader" (loader): Transport belt connectable entities must have a non-zero collision bounding box defined.

As far as I can tell from my testing, Factorio uses the collision box only to determine which tiles the entity covers. Setting a tiny collision box on one side of the tile and pointing the inserter pickup/drop_position to the opposite side of the tile will still frequently result in the loader being selected as the pickup/drop target.

[eradicator]

As far as I can tell from my testing, Factorio uses the collision box only to determine which tiles the entity covers. Setting a tiny collision box on one side of the tile and pointing the inserter pickup/drop_position to the opposite side of the tile will still frequently result in the loader being selected as the pickup/drop target.

This makes me very sad :|. I guess you tried spawning them in in the "right" order? Or do they reselect new targets even after being built? (And what about if the loader wasn't active when the inserter is placed...)
I think i'm down to wild guessing.

[bobingabout]

would love

would love 1x1 splitter that splits to all three sides .

That's good too.

[eradicator]

would love

would love 1x1 splitter that splits to all three sides .

That's good too.

Oh great, my :sulking: ascii-smiley gets converted into a :mad face: picture-smiley when other people quote it.
Thank you forum software for making me look like an idiot.
Let's hope Therax at least succeeds in making the splitter .