Inserter throughput

[kitters]

Let me whine a little.
After launching a rocket in Death-maraphon world with a base of 1sciencepack per sec, i wanted to try some massive production, with beacons and modules. I launched creative mode (my first mode) to project production sections. Was projecting green circuit section during 20-30 hours. According to calculations and data from wiki and other sourcers. And faced the problem.
An assembler with 4.25 rate. Must take 17 iron/s. Suspecting a stack inserter to have throughput more than 13 item/s, I fed assemblers with two blue belts and two inserters from two sides.
And it appears to be not enough. Two belts supposed to be enough throughtput to feed two assemblers, but second one, which gets not full belts can't get enough iron. And even puting one more inserter doesn't help. (3 more need for cables, 6 in sum). My assemblers are still stopping with 3 inserters.
I set up an experement and found that inserter thoroughput depands on type fo belt (not tier) and decreases significantly for underground belt, different for begin and end of undergroung belt.
You can see thoroughput through a repetitive pattern on the belt.
Taking from belts. Take 2, miss 1 from full belt. 2/(1)/2/(1)/2/(1)/2/(1)/2/(1)/2 . Total 5 misses. Only fifth assembler stops.
https://hotcrimestory.com/URL]
Taking from ends of belts. Pretty much the same, 5 misses. 2/(1)/2/(1)/2/(1)/2/(1)/2/(1)/2, 3/(1)/1/(1)/3/(1)/1/(1)/3/(1)/1. BUT even SECOND assembler stops.
[URL=https://savepice.ru] https://hotcrimestory.com/URL]
Taling from beginings of belts. 2/(3)/3/(3)/3/(3)/3/(3)/1. 12 misses. More than two times slower. And even FIRST assembler stops, can't take 17 iron from full belts.
[URL=https://savepice.ru] [URL=https://hotcrimestory.com]https://hotcrimestory.com/URL]

What i want to say. When the game comes to fast assemblers, big throughputs needs. And now inserters are unstable and can give less throughput than expected. Put 12 inserters to each assempler is not an option. Because you want to project not separated superbuffed assemblers, but a line, when beacons speed up several, not only one assembler.

There is not need of increasing inserters' throughtput. I think they should be fixed to have stable throughtput in different situations. To be able to take from belt constant amount of items per sec (if there are on belt) no matter how they spread or other circumstances.
Or our big factories are continuing to work unstable and give much less production capacity.

thanks for reading
sorry for language mistakes, it isn't my native one.

UPD. (05.02) Inserters spend a part of time being inactive. So, they don't want to work, maybe because of the limit.
The limit is The ingredients for 1 craft in addition to the ingredients for the number of crafts that can complete during one full inserter swing; but at least the ingredients for 2 crafts and at most the ingredients for 100 crafts.rafts.
But this buffer is not enough, just because inserter is not only swinging but collect items from the belt most of the time. And buffer have enough time to be exhausted.
So, solving the problem becomes much simpler.
My suggestion to game developers is just to increase this buffer size.

[coppercoil]

I made a quick test and got 12.8 item/s throughput. I think this is normal. Actual inserter throuthput depends on items distribution on the belt, there also are other not-so-intuitive factors. AFAIK this is by design, this make the game slightly more realistic and more complex.

[kitters]

I reported about the case, when three inserters can't get 17/s.
And in configuration when inserters take from beginings of undeground belt, two of them can't get 17/s even from a full belt per each inserter.
A case, when an inserter takes from full belt (not underground) into a chest - okay, it can be 13/s, i heard about it, of course it's normal.
But this is not the point.

[coppercoil]

You mean, you can't achieve expected throughput when inserting into assembling machine while inserting into a chest works well? Three chests worked for me.

I guess it’s because assembling machine has very small internal buffer (12 plates), so stack inserters must idle because destination point is full. In that case you need lots of fast inserters using small stack size to deliver iron in very high frequency. I may be wrong, haven’t tested it.
Or maybe, an intermediate chest could work for it as a bufer.

[disentius]

I see 5 beacons with 2 speed modules, and assembly machine with 4 prod modules.
the iron intake for that configuration is 4.125 iron plate/s.
ref:
https://kirkmcdonald.github.io/calc.htm ... 8+dQuvHw==

[kitters]

You are wrong, an assembler has a larger buffer, i can see more than 30 plates in while working.

UPD. But you give me the idea. You are right, inserters spend a part of time being inactive. So, they don't want to work, maybe because of the limit you refered.
And i found some info. The limit is The ingredients for 1 craft in addition to the ingredients for the number of crafts that can complete during one full inserter swing; but at least the ingredients for 2 crafts and at most the ingredients for 100 crafts.rafts.

But this buffer is not enough, just because inserter is not only swinging but collect items from the belt most of the time. And buffer have enough time to be exhausted.

So, solving the problem becomes much simpler.
My suggestion to game developers is just to increase this buffer size.

[kitters]

I see 5 beacons with 2 speed modules, and assembly machine with 4 prod modules.
the iron intake for that configuration is 4.125 iron plate/s.
ref:
https://kirkmcdonald.github.io/calc.htm ... 8+dQuvHw==

Deathworld+maraphon, dude, I've told. Expensive recipes.
Six beacons.
Dude. Seriously. Who am I you think?
I told i have problems to get 17 iron with 2-3 inserters, assemblers stop. And you like "hey, watsproblem, all it takes is only 4.125 iron."

[GiftGruen]

Looking at what you wrote, it seems like they simply used the time for one full inserter swing as a shortcut because computing the real number of resources needed to never run out would be more expensive to compute? In that case, you are right that simply increasing the buffer size would solve the problem. However, the question is by how much, as buffers that are too large can also be annoying and should be avoided.
The answer seems to lie in changing the buffer rules you mentioned above from "the number of crafts that can complete during one full inserter swing" to "the number of crafts that can complete during the time it takes to collect one 'handful' of a resource" which, as you already observed, is different because the amount of time is slightly longer.
It is, however, also something that changes over the course of the game whenever you research Stack Inserter Capacity techs. Maybe this would have to be done differently depending on the tier of the assembling machine? A tier 1 assembling machine might account only for blue inserters with a capacity of one, a tier 2 assembling machine for blue inserters with capacity of two (not because you cannot double up on inserters but because a higher-capacity inserter is slower, and there should not be an incentive to lower max inserter capacity on high-throughput machines). Assembling machine 3 can then use the longest time, the time needed for a stack inserter with max capacity.

But whatever the case, it seems like the current formula still has some bugs and should be changed.

[leadraven]

Unfortunately, inserters simulation is oddly detailed. I'd prefer much simpler simulation with exact rotation speed and throughput.

[darkfrei]

Unfortunately, inserters simulation is oddly detailed. I'd prefer much simpler simulation with exact rotation speed and throughput.

Yes, it would be nice if they have hardcoded paths with inverse kinematic motion. Maybe also good UPS optimization, nothing must be calculated, just showed.

[disentius]

Sorry, i totally missed the "expensive" part.

Inserters are slow picking from a full moving belt. Has to do with tracking and slow extend/retract speed for switching between inner and outer pickup lanes.
They are fast enough when picking from a single lane on the far side.
This setup works as intended, i believe: (used /editor mode to build this with marathon-expensive freeplay settings)
[EDIT] hmmm.. still short on iron some ticks. better use 2 inserters...

GC expensive.gif (10.86 MiB) Viewed 6850 times

[eradicator]

Unfortunately, inserters simulation is oddly detailed. I'd prefer much simpler simulation with exact rotation speed and throughput.

Yes, it would be nice if they have hardcoded paths with inverse kinematic motion. Maybe also good UPS optimization, nothing must be calculated, just showed.

As far as i remember the "don't simulate inserters" idea was scrapped after being mentioned in an FFF.
Here's an old thread with pictures about how inserter grabbing times differ depending on belt layouts: viewtopic.php?f=194&t=69863&start=20

@disentius: shouldn't the last belt segment be yellow belt?

[eradicator]

When doubling up the inserters it produces at full speed just fine. I noticed however that at this speed the output can become a bottleneck. If the output is blocked for a few ticks the input will also stall until the output is cleared.

Note that each set of inserters prefers a different lane of the input belt:

0eNrNm+1uqzgQhu+F3+HIH2BDb2VVRYQ4rbUEkIHqdKve+xrSfGzrHF6PtFL6qy3N47HxzLxjTz+SXTOZ3tl2TJ4+Elt37ZA8/fWRDPalrZr5d+N7b5KnxI7mmGyStjrOP5nfvTPDkI6uaoe+c2O6M82YfG4S2+7N7+SJf25WITtT+fFuPiQ+nzeJaUc7WnMyY/nhfdtOx51xnno1oDH16Gydmta4l/fUT8C4Q1Ubj++7wRM82Q/sqan6lW+Sd/9N8Sv3g+2mw8G47WD/8SDOLl+zxd/GE5fxhmk3jNVC/TmAPg+Q+wECGAlh5AolW1v9n4ZxcSJmftp76/ySLQ+zAD0n0HmQrgJ0RaAzmK7j6SUML+LhBQwv4+Eahs8rGEtXOJ3H03OcLuLpGU6X8XSJ0wmeKnA6xVNxeryn4n7K4x01wvJ4R41Y9HhHxfeLiPdTfKuLeDfFvVTEeykeYES8k+KxUcT7KB7VRbyL4vlIXD3Utgfb+mdp/WqGkPPceM/5b7eDGUfbvgzz3zhz7N7MdvLPGq+fzH47KzT/aHST2SSn356U2HlI17Vp31TjLLTqbpp1o9dQm+TY7efn1Zg2plqMuSjB55CaEZouZ8S6nBEFHS8BfPldxd6VGLOxX6vqFXFvzD71azU1JpWz4g3JRbYOV2Q4X4dLMlyswhmZLVfZdLuzVTZ9wcnBQAZxiooLW/fTDZuu2vtHd6OJWKqoWwfZnOu7bhr7aS4Df45TwOOc/ZDdH8e294Yp6W7P190+Y1S9zv4LFyE4p1YaCFxQ1ToCl9RCA4FnVK3OgBeaU8sMxHJFVeoIXFOLDAReEIU6wi6JFQbAzhlRpiNsTqwvELYginSELYnVBcLOiBIdYefE2gJhk5MoDyXRXBNxLEgriKUJMvF45+McDaaKUeFI7lUcrnvOKV2Q6p7QO1FXB62GwRx3jUelx6p+te0s/e4lz7mU8LOy/fXMumttndbW1ZNdqqSzmOyd15F+/m/zxK6aMguac3OiPFb136ltB+PGoJo6OQWywBkOzWFoTs3efH03K4VbLC87Yg2qqVk7GBtUQc3TyAKUET5BdIlD1Qzhs4C663vj0rraNTenAYJyGqAZPhHx0BPhkYFC/J9xQgvYQVjIP4KXLXjskWiU0HjoCfqG/7h/587ZvdkugK/bvTw0Vk7NUsCxk1ZUOLJKOrqGlksNvVY1a/IdV/CIQpd4WNaX7b92DceoNgY9o+CxNiJXhSI2H2XrMb6QsVAJQLPYxJE9Zrwt8tiJyAediIrNgI/6RnTsRB71jRSRyROJEGUkE4iMJSMeHgSDd0m9LwyG2RKPiBkau0oZyQSCbJlR8zbQWlOSFQdwE1Uq8ol3sMuopN/LqSCvIDcWKWDvl9TWH4X0zzBy2xKEJx/4Q/SfZ4pD39jxTxon/37l4jfX6U5n2zvbOT+Axzn78hrUkZxJ6oyCe5GzjHprAa1QTr22gOiKevIB0TX14gKiF9QzEIheUo9EEDqh6w03ndD0hscDQs8bvmEILW8Ra54RRQMEz4kXGBBcES0PByxCh5vGbS0iIrq6E9CD4JJ444BYTehuwzM0obstIkET2ttw6cIJ/W1f9HxdFvKbBjeod70IN53zm162lX6hIro1ht/0sv25X4jC1lFd98v8n0+jzOZc/i1ik7z5GnP5gNaSlXkmMuaH/Bce+pdj

Copy blueprint

preferredlanes.png (900.74 KiB) Viewed 6833 times

[disentius]

@Eradicator: I tested, yellow and blue are the same (18.00) Red doesn't work as well, strangely.
If you use the Vegemeister unload trick ,one inserter works fine, like this:

GC expensive.gif (2.6 MiB) Viewed 6819 times

Pickup speeds from belt in 0.18.3:

The attachment GC expensive.gif is no longer available

[darkfrei]

How about this one?

[disentius]

First one is not bad:
G:\Profiles\keyuser\Desktop\2020-02-05 21_20_20-Window.png

[darkfrei]

So it can be good too.

2020-02-05T21_34_06-Factorio 0.18.3.png (156.07 KiB) Viewed 6798 times

2020-02-05T21_38_11-Factorio 0.18.3.png (185.59 KiB) Viewed 6796 times

[quyxkh]

I thought I'd see how far I could push it, I got one assembler up to over 800/minute, with a cs8 assembler theoretical peak is 8/0.5*60*1.4=1344 so max-boost expensive recipes is going to require bot-fed chests, but belts can feed your cs4.25 assemblers and then some, 4.25/.5*50*1.4 is 714.

pic

Screenshot from 2020-02-05 13-20-22.jpg (98.51 KiB) Viewed 6782 times

[BlueTemplar]

As eradicator already mentioned the devs have decided against this :

Inserters should not chase items
What I always liked about Factorio is that it's a very precise game. Ratios, throughputs, crafting times are all well explained and even if it gets complicated, everything can be calculated to the last item. Miners mine resources at a precise rate, smelters and assemblers craft items at a precise speed, belts move the items at a precise throughput. But inserters... due to their behavior where they track items on the belt before grabbing them, they don't have a precise throughput. This really grinds my Iron gear wheels, as it's hard to even know if an inserter will be fast enough to load a simple assembler. There are Wiki Tables and References, but they are ridiculously complex since it depends on the inserter type, source, destination, belt type, belt orientation and inserter capacity bonus. Even after accounting for all that, the numbers are still not precise since it depends on timings and how items are placed on the belt.

My proposition is to remove this complex movement of item chasing and have inserters move to their predefined pickup location and immediately pick up the closest item (in the case of a belt). This will:
- Make inserters have a constant throughput. It will still depend on some factors like stack size (e.g. stack inserter will pick up faster from chest than from belt), but it should simplify things significantly and allow us to have a calculated throughput for chests and belts that we can show in inserter tooltips.
- Prevent all the issues with inserters getting stuck (e.g. burner inserters running out of fuel because they chase items they can not grab). We often argue if this is a bug or not and if it should be fixed.
- Improve performance (maybe significantly). Inserters currently chase items throughout it's entire swing, tracking the items on the belt each tick and searching for a new item each time one goes outside the belt (which happens quite often for blue belts). Removing this requirement would mean less memory access to other entities and much simpler mathematical calculations. Since inserters are the second most common built entity, these improvements could lead to a big UPS boost.

But on the other hand, this will mean:
- It will graphically look much worse. While I believe we can do many things to make this look good enough (by separating drawing animation logic from game logic), it will probably not look as nice as it does now.
- It will remove some of the nice organic feel of the game. And it will remove some (arguably) fun emergent situations.

Combine this with the fact that changing something so core to Factorio in such a significant way would have big implications. So we decided this wont be done.

[disentius]

@Darkfrei:
Yes. Vegemeister made me aware of this trick with his trainloader:
https://www.reddit.com/r/factorio/comme ... rom_belts/

And we had a discussion about loading belt to chest related to train loading here:
viewtopic.php?f=194&t=69863