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.
Re: Inserter throughput
Posted: Tue Feb 04, 2020 7:01 pm
by 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.
Re: Inserter throughput
Posted: Tue Feb 04, 2020 7:25 pm
by 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.
Re: Inserter throughput
Posted: Tue Feb 04, 2020 8:38 pm
by 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.
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.
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."
Re: Inserter throughput
Posted: Tue Feb 04, 2020 10:08 pm
by 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.
Re: Inserter throughput
Posted: Wed Feb 05, 2020 6:46 am
by leadraven
Unfortunately, inserters simulation is oddly detailed. I'd prefer much simpler simulation with exact rotation speed and throughput.
Re: Inserter throughput
Posted: Wed Feb 05, 2020 10:47 am
by darkfrei
leadraven wrote: ↑Wed Feb 05, 2020 6:46 am
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.
Re: Inserter throughput
Posted: Wed Feb 05, 2020 4:17 pm
by 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...
leadraven wrote: ↑Wed Feb 05, 2020 6:46 am
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?
Re: Inserter throughput
Posted: Wed Feb 05, 2020 5:35 pm
by 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:
@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 6087 times
Pickup speeds from belt in 0.18.3:
The attachment GC expensive.gif is no longer available
Re: Inserter throughput
Posted: Wed Feb 05, 2020 7:57 pm
by darkfrei
How about this one?
Re: Inserter throughput
Posted: Wed Feb 05, 2020 8:21 pm
by disentius
First one is not bad:
G:\Profiles\keyuser\Desktop\2020-02-05 21_20_20-Window.png
Re: Inserter throughput
Posted: Wed Feb 05, 2020 8:34 pm
by darkfrei
So it can be good too.
2020-02-05T21_34_06-Factorio 0.18.3.png (156.07 KiB) Viewed 6066 times
2020-02-05T21_38_11-Factorio 0.18.3.png (185.59 KiB) Viewed 6064 times
Re: Inserter throughput
Posted: Wed Feb 05, 2020 9:48 pm
by 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 6050 times
Re: Inserter throughput
Posted: Thu Feb 06, 2020 9:20 am
by BlueTemplar
As eradicator already mentioned the devs have decided against this :
Twinsen wrote: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.
https://hotcrimestory.com/URL]
https://hotcrimestory.com/URL]
[URL=https://hotcrimestory.com]https://hotcrimestory.com/URL]
all it takes is only 4.125 iron."