[0.18.8] - 1x1 Loaders doesn't support speed 240 items/second

[darkfrei]

1x1 loaders doesn't support belt speed 240 items/second and more.

The bug report: https://mods.factorio.com/mod/DoubleSpe ... 000b4b656f

[Rseding91]

Thanks for the report however I don't consider this a bug. There is an upper limit to how fast items can move on belts just due to how the logic works.

[posila]

I moved it to modding interface requests. I'd like to improve loaders (so it can connect to cargo waggons; at least matches UPS efficiency of stack inserters when interacting with container inventory), so this one could be looked into also. Today is not the day, though.

[Deadlock989]

I moved it to modding interface requests. I'd like to improve loaders (so it can connect to cargo waggons; at least matches UPS efficiency of stack inserters when interacting with container inventory), so this one could be looked into also. Today is not the day, though.

If you're looking for a wish-list ... The one that everyone wants is powered loaders.

Failing that, some kind of prototype flag or entity type whitelist/blacklist that optionally stops the loader from inserting into machines, so that they can only be used with containers (including cargo wagons if that ever happens).

Insane belt speeds are pretty much bottom of my list.

[Oktokolo]

The ideal loader would be Miniloader - just implemented in the engine instead of emulated by two ultrafast inserters.

[billbo99]

In the miniloader code base, it scale the number of invisible inserters to match the speed of the belt.
https://github.com/mspielberg/factorio- ... l.lua#L150

With a belt speed of 240 it uses 10 invisible inserters
https://github.com/mspielberg/factorio- ... s.lua#L168


My guess is a loader gets maxed out at 120 items per second due to the in game limit of one operation per tick. With two sides of the belt the loader can handle 1 item per tick per side of the belt. 60 ticks per second * 2 sides = 120 items per second.

[Optera]

I moved it to modding interface requests. I'd like to improve loaders (so it can connect to cargo waggons; at least matches UPS efficiency of stack inserters when interacting with container inventory), so this one could be looked into also. Today is not the day, though.

If you're looking for a wish-list ... The one that everyone wants is powered loaders.

Failing that, some kind of prototype flag or entity type whitelist/blacklist that optionally stops the loader from inserting into machines, so that they can only be used with containers (including cargo wagons if that ever happens).

Insane belt speeds are pretty much bottom of my list.

My loader wishlist is simpler. Fix the black hole glitch viewtopic.php?f=7&t=49523

But I'll take general optimization, setting filters from circuit signals like stack inserters, energy interface and vehicle interactions too

[Rseding91]

My loader wishlist is simpler. Fix the black hole glitch viewtopic.php?f=7&t=49523

But I'll take general optimization, setting filters from circuit signals like stack inserters, energy interface and vehicle interactions too

That has already been fixed? Unless you have new steps to reproduce the issue.

[Optera]

My loader wishlist is simpler. Fix the black hole glitch viewtopic.php?f=7&t=49523

But I'll take general optimization, setting filters from circuit signals like stack inserters, energy interface and vehicle interactions too

That has already been fixed? Unless you have new steps to reproduce the issue.

You are right it is fixed in 0.18.12.
I must have missed the patch notes for that fix. Finally I can remove all the circuit safeguards against overfilling assemblers.

[raiguard]

I'll add my own things to this list:

- Per-lane filters
- Show filters in alt info
- Let input loaders support filters (less important)

If the first two were implemented, along with supporting faster belt speeds, then I could significantly simplify Editor Extensions' infinity loaders. The third thing would also be nice, but is less important.

[posila]

As of 1.1.28, loaders should be able to handle more than 1 item per lane per tick ...
HOWEVER ... there are still some limitations/flaws.

For high speed loaders to work at max throughput, they need to be able to push/pull item far enough onto/from the transport line. If the transport line is not long enough (eg. because belts have not merged their transport lines yet, or the merge is not going to happen due to mixing belt speeds, side loading, inserter interaction, ...), loader is gonna fill (or empty) the entire length of the transport line in a tick and that's it. Similar problems probably happen with high-speed belts, and I consider it acceptable limitation of the engine.

Also loader inserting items from belt to a container might take the items so far down the transport line, the items will disappear before reaching the loader. This could be fixed by reversing order of update of transport line manager and loaders, but then the visual problem would appear on the other side (loader (or un-loader) taking from container and inserting onto belt), so we would need to update loaders, transport lines, unloaders, which we probably won't do, so I am just putting this out as known minor issue.

[ptx0]

For high speed loaders to work at max throughput, they need to be able to push/pull item far enough onto/from the transport line

any idea whether this changes their performance profile?

[Rseding91]

For high speed loaders to work at max throughput, they need to be able to push/pull item far enough onto/from the transport line

any idea whether this changes their performance profile?

Slightly yes; the loader was changed from: insert-to-line to while(insert-to-line) ... so at a minimum they are doing twice as many insert attempts. Now, if that's 2x the cost is super hard to know because attempt 1 will most likely need to pull in cold RAM and attempt 2 will be using hot RAM so probably not "2x" but not "1x" either.

[ptx0]

For high speed loaders to work at max throughput, they need to be able to push/pull item far enough onto/from the transport line

any idea whether this changes their performance profile?

Slightly yes; the loader was changed from: insert-to-line to while(insert-to-line) ... so at a minimum they are doing twice as many insert attempts. Now, if that's 2x the cost is super hard to know because attempt 1 will most likely need to pull in cold RAM and attempt 2 will be using hot RAM so probably not "2x" but not "1x" either.

bummer, even with a long transportline and 270/sec belts i don't get that throughput, so they're slightly faster than 120/sec but not really terribly faster, and now consume potentially 2x the time? sounds like an overall loss

[posila]

bummer, even with a long transportline and 270/sec belts i don't get that throughput, so they're slightly faster than 120/sec but not really terribly faster, and now consume potentially 2x the time? sounds like an overall loss

In test I wrote for this change I am using 360 items/s loaders and belts. 720 items were transported between 2 chests 15 tiles apart within expected time so I don't know why you are not getting the expected throughput.

[ptx0]

bummer, even with a long transportline and 270/sec belts i don't get that throughput, so they're slightly faster than 120/sec but not really terribly faster, and now consume potentially 2x the time? sounds like an overall loss

In test I wrote for this change I am using 320 item/s loaders and belts it transported 720 items between 2 chests 15 tiles apart within expected time so I don't know why you are not getting the expected throughput.

okay - me neither. I'm not sure how many tiles I did. perhaps 10?

it's a loader pulling from an assembler - Schall Machine Scaling +6 assembling machine 3, which is essentially 4096x AM3s compressed into one big chunk.

the other end is a loader dumping into a passive provider chest.

nothing else in between the two

[posila]

okay - me neither

If you provide a save demonstrating the issue, I am willing to look into it further.

[ptx0]

okay - me neither

If you provide a save demonstrating the issue, I am willing to look into it further.

i'll have to curate that later.