www.factorio.com
https://forums.factorio.com/
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.Optera wrote: Results:
splitter: 0.315 ms/tick
loader: 0.260 ms/tick
miniloader: 0.171 ms/tick
Scripted on-tick will be several magnitudes less efficient than anything using native entities.darkfrei wrote: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.
Indeed, this is why I created miniloaders in the first place.Optera wrote: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.
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 movementeradicator wrote: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)
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?Therax wrote: losing filtering and circuit control capability as a result.
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.eradicator wrote: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?
Miniloader inserters are locked to stack size 1, with very high arm movement speed.eradicator wrote: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.
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 wrote: 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.
It matters for input filtering and fancy lane-aware splitters. Thank you. :/.Zavian wrote: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 wrote: 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.
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.eradicator wrote:Mine had speed = 0.99 (because i assumed float with max 1?), but i only tried for 5 minutes or so.
My experiments suggest the same. If someone figures out a way to do this, I'd be happy to hear about it.eradicator wrote: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.
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.eradicator wrote:And those "inactive" loaders you tal about..are they simply speed = 0? Or active.false?
Unless you use the new 10/20/30/40/50/60 speed setting.Therax wrote:Indeed, this is why I created miniloaders in the first place.Optera wrote: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.
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 movementeradicator wrote: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)
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.
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")?Therax wrote: 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.
If you try to create a loader with no collision_box, you get the following:eradicator wrote: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")?
Code: Select all
Error while loading entity prototype "miniloader-loader" (loader): Transport belt connectable entities must have a non-zero collision bounding box defined.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...)Therax wrote: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.
That's good too.eradicator wrote:would love 1x1 splitter that splits to all three sidesbobingabout wrote:would love.
Oh great, my :sulking: ascii-smiley gets converted into a :mad face: picture-smiley when other people quote it.bobingabout wrote:That's good too.eradicator wrote:would love 1x1 splitter that splits to all three sidesbobingabout wrote:would love
.