So, the situation is like this: I had 2 lines of 5 LDS factories 12 beaconed feeding from 2 lines of copper plates. Over time I noticed a slight decrease of LDS even though the feeding lines were backed up and Max Calculator showed me I should produce slightly more. Upon investigating I discovered that the 2nd,3rd and 4th factory from the first line had input shortage delays, while the second line had plenty of stock and acted as it should.
The lines were similar with one slight modification in design: 1st line was feeding from the undeground IN (the head that goes underground) the second line was feeding from the OUT underground (the head where items come out from the ground). Each of the two lines of factories was feeding from a separate belt and both belts were backed up. Insertion was at a rate of 8 copper plates per second by a green inserter in each case.
So I played with it a bit more and it looks like when trying to insert from the underground head that sends the items underground the game messes up. Apparently simultaneously calcullating what the inserter picks up and what goes underground from the same tile somehow confuses the game.
Not only that, but it also affects the throughput of the belt itself. The 5th factory in line which was feeding directly from the belt had shortage of items as well even though after the first 4 it should still have 13 items on the belt (45 - 4*8).
My opnion is that something like this happens: the game marks some items as going under, the inserter picks them up after they've been marked but they most likely do not count towards the qty of inserter hand (it's like it takes them from the belt but with zero qty) and then it struggles to fill it's hand with non marked items up to 12.
The result is the inserter actually needs to pick up more items, because some have been marked as going under so it starts to strugle. On the other hand the belt now has some items marked as going under which don't appear on the other side because they have been actually picked up by the inserter.
So this way, the inserter will pick up probably 13-14 items but drop in the factory 12 because the rest have a different flag and the belt now instead of having 8 less items per second after the insertion probably has 9-10 less after each insertion. So the 5th factory shows shortage of items because items do not appear on the belt anymore.
This looks like a multithread race issue if inserters and belt are running on separate threads, which I suppose they are.
Hope it makes sense what I have described.
Picking from underground belt input screws up the belt
Picking from underground belt input screws up the belt
Last edited by tasemagu on Thu Dec 22, 2022 7:08 pm, edited 1 time in total.
Re: Picking from underground belt input screws up the belt
Post the most simple save that lets your reproduce the issue, describe what to do, what happens and what you expect to happen instead, see
How to report a bug - READ BEFORE POSTING
How to report a bug - READ BEFORE POSTINGRe: Picking from underground belt input screws up the belt
Please find the link to a save.
https://www.dropbox.com/s/4bxu372u8yio66b/Test.zip?dl=0
I created 2 Low Density Structure lines. Please note the ever so often ingredient shortage for the line on the left for factories 2,3 and 4 compared to the one on the right which has no problems, the only difference between the two being which head of the underground belt the copper is being inserted from.
Please ignore the rest of the base.
https://www.dropbox.com/s/4bxu372u8yio66b/Test.zip?dl=0
I created 2 Low Density Structure lines. Please note the ever so often ingredient shortage for the line on the left for factories 2,3 and 4 compared to the one on the right which has no problems, the only difference between the two being which head of the underground belt the copper is being inserted from.
Please ignore the rest of the base.
Re: Picking from underground belt input screws up the belt
To be sure, what you consider the bug is, that an inserter can take faster from an underground belt outlet than inlet?
Re: Picking from underground belt input screws up the belt
As far as I understand the belt mechanics, this is expected behavior. It's just because of the very exact belt simulation.
Underground entries and exits have only half the space for the inserter to pick up stuff. The other half is underground and not accessible. The inserter starts to look for items from the center of the belt.
For belts west-to-east and the inserter facing north:
On entries, items appear on the left and disappear on the center. On exits, items appear on the center and disappear on the right. It can happen that if the inserter is about to grab an item just in the center of an entry, it disappears just before the inserter is able to actually grab the item, so the item isn't grabbed but grabbing time wasted. If the inserter is about to grab an item from the center of an exit, the item flows over the whole half of the belt, so there is much more time to grab, so the item is grabbed and time not wasted.
Because of this behavior, the inserter needs to change lanes more often on entries with missing items on the near lane, and this is what really slows it down. The first inserter on your production line works good, because the near lane is still full, and this provides enough items even with the items disappearing in the center. But starting with the 2nd inserter, the near lane isn't full enough any more so the inserter changes to the far lane. The last inserter is good again, because it accumulates items on both lanes, because it is the end of the belt.
"Issues" like this, and I rather call them challenges, make it really interesting work to design production lines with no item shortage. For most beaconed setups, it's more work to avoid shortages than it is to do the general design itself. And because of that, 12-beacon-designs for recipes with a huge amount of input material are not always feasible.
ps.
Short comment about your rocket silos: this is the same type of challenge. To feed a fully beaconed rocket silo, one need 2 buffering chests+stack inserters for each of the 3 items inside the beacon area to satisfy demand. Given the very tight available space, designs tend to converge to mostly the same general design, because there are not many different ways to achieve this.
Underground entries and exits have only half the space for the inserter to pick up stuff. The other half is underground and not accessible. The inserter starts to look for items from the center of the belt.
For belts west-to-east and the inserter facing north:
On entries, items appear on the left and disappear on the center. On exits, items appear on the center and disappear on the right. It can happen that if the inserter is about to grab an item just in the center of an entry, it disappears just before the inserter is able to actually grab the item, so the item isn't grabbed but grabbing time wasted. If the inserter is about to grab an item from the center of an exit, the item flows over the whole half of the belt, so there is much more time to grab, so the item is grabbed and time not wasted.
Because of this behavior, the inserter needs to change lanes more often on entries with missing items on the near lane, and this is what really slows it down. The first inserter on your production line works good, because the near lane is still full, and this provides enough items even with the items disappearing in the center. But starting with the 2nd inserter, the near lane isn't full enough any more so the inserter changes to the far lane. The last inserter is good again, because it accumulates items on both lanes, because it is the end of the belt.
"Issues" like this, and I rather call them challenges, make it really interesting work to design production lines with no item shortage. For most beaconed setups, it's more work to avoid shortages than it is to do the general design itself. And because of that, 12-beacon-designs for recipes with a huge amount of input material are not always feasible.
ps.
Short comment about your rocket silos: this is the same type of challenge. To feed a fully beaconed rocket silo, one need 2 buffering chests+stack inserters for each of the 3 items inside the beacon area to satisfy demand. Given the very tight available space, designs tend to converge to mostly the same general design, because there are not many different ways to achieve this.
Re: Picking from underground belt input screws up the belt
Well, yes and no! If that would be the behaviour then all 5 factories in the line would have shortage of items since they all pickup from the same underground type. The fact that in a line of 5 factories just number 2,3 and 4 behave like this, that means it can't be just the inserter behaviour picking up from an inlet. So there must be a combination of belt behaviour (underground inlet) and inserter. Also please keep in mind the line is backed up. Which means there's for sure no shortage of items on the belt. Further more the green inserters only have to supply an average of 8 pcs/s to each factory and this is quite far from the maximum inserter qty a green stacker can deliver (which is roughly 12/s).
So technically there should be no reason for such behaviour since we are not close to any throughput limit for the belt or inserter!
I do believe this must be a race between threads, once again, assuming belts and inserters run on separate threads!
Re: Picking from underground belt input screws up the belt
What you say makes total sense, however the green inserter only has to deliver 8 pcs per second to each factory. I get what you say about the fact that the first factory has the close half belt full and then for the second factory it's not as full, but think about it... it's pretty insane!Tertius wrote: ↑Thu Dec 22, 2022 11:05 pmAs far as I understand the belt mechanics, this is expected behavior. It's just because of the very exact belt simulation.
Underground entries and exits have only half the space for the inserter to pick up stuff. The other half is underground and not accessible. The inserter starts to look for items from the center of the belt.
For belts west-to-east and the inserter facing north:
On entries, items appear on the left and disappear on the center. On exits, items appear on the center and disappear on the right. It can happen that if the inserter is about to grab an item just in the center of an entry, it disappears just before the inserter is able to actually grab the item, so the item isn't grabbed but grabbing time wasted. If the inserter is about to grab an item from the center of an exit, the item flows over the whole half of the belt, so there is much more time to grab, so the item is grabbed and time not wasted.
Because of this behavior, the inserter needs to change lanes more often on entries with missing items on the near lane, and this is what really slows it down. The first inserter on your production line works good, because the near lane is still full, and this provides enough items even with the items disappearing in the center. But starting with the 2nd inserter, the near lane isn't full enough any more so the inserter changes to the far lane. The last inserter is good again, because it accumulates items on both lanes, because it is the end of the belt.
"Issues" like this, and I rather call them challenges, make it really interesting work to design production lines with no item shortage. For most beaconed setups, it's more work to avoid shortages than it is to do the general design itself. And because of that, 12-beacon-designs for recipes with a huge amount of input material are not always feasible.
ps.
Short comment about your rocket silos: this is the same type of challenge. To feed a fully beaconed rocket silo, one need 2 buffering chests+stack inserters for each of the 3 items inside the beacon area to satisfy demand. Given the very tight available space, designs tend to converge to mostly the same general design, because there are not many different ways to achieve this.
1. If you check the first factory inserter movement you will notice it's wobeling on both halves of the belt, so it doesn't just pick up from the half in front which would actually take a long time given the belt speed and inserter speed. The inserter would have to wait for the belt to provide all items on the closest half.
2. We are talking about a full blue belt, so the second factory inserter has to pick up from a belt still having 37 items on it. 37!!! I mean come one. You can't tell me this is expected behaviour!
3. And thirdly as I already said, each inserter has to provide just 8 pcs/s on average to the factory... which is far from a green stacker full potential
I do have factories where I input or output with 2 or even three inserters because I understand the timings of the inserters, the delays from getting a command to picking up, swinging and put away, but this example seems so far of the limit it just seems it's bugged!
I even have factories that produce 44.8 items/second and I do the output with 4 inserters. So believe me when I say I understand what is normal behaviour and what is not. This doesn't seem normal at all.
Re: Picking from underground belt input screws up the belt
That is not what is happening. Taking from the inlet is slower because the inserter is hovering closer to the vanishing point and fails pickups more often than an inserter on the outlet. When the items on the belt thin out, the path for the inserter to the next item increases and the assembler stalls, when the belt ends items do not vanish anymore and the last assembler can work continuously. NaB.
Re: Picking from underground belt input screws up the belt
I get what you say and I answered Tertius. The second inserter has 37 items on the belt and only has to deliver 8 items/second.... this is not a thin belt with 37 items on it. It's thinner than the first inserter but c'mon... it's 37 items. Also picking 8 items is far from the inserter capabilities...Loewchen wrote: ↑Fri Dec 23, 2022 2:31 amThat is not what is happening. Taking from the inlet is slower because the inserter is hovering closer to the vanishing point and fails pickups more often than an inserter on the outlet. When the items on the belt thin out, the path for the inserter to the next item increases and the assembler stalls, when the belt ends items do not vanish anymore and the last assembler can work continuously. NaB.
Basically this makes the inlet completelly useless for picking purposes unless you want to pick up 2-3 items/second, but probably the UPS usage for picking up those 2-3 pieces might not even be worth it.
Well. Anyway, my design alowed me to change it to the outlet pickup and I could have even added a second inserter so it wasn't a "problem"for me, just thought I'd report it. I didn't know the inlet behaviour would be expected to be like this!
Thanks! If this is expected behaviour I believe we can close this thread!
Re: Picking from underground belt input screws up the belt
Factorio is fully deterministic. Any given situation will always result in the same outcome, regardless of how fast or slow the users computer is. If there were any races or unchecked parallelism, this would immediately break this determinism, and, as consequence, synchronisation in multiplayer.
But since we're not getting bug reports about inserters causing desyncs, it's safe to say that your observation isn't caused by racing threads.
If you happen to be a programmer or something related, whether professional or hobbyist, searching for and reading the technical bits and pieces in the Friday Facts blog series is probably worth your time.