Until now I always thought that if you sideload a belt into another belt which is already fully compressed on that side, that the items on the incoming belt will wait.
But now I saw a different behaviour. I designed a production line for a full blue belt of green science. According to my math, I need 36 assemblers for that. As inserters sometimes might leave gaps due to timing, I built 2 rows of 20 assemblers with their output belts merged afterwards. The "spare" assemblers should fill any potential gaps. To be really sure to have no gaps, I also added extra output belts to the last of the two assemblers, each sideloading the main output belt, just in case. I expected that these belts would back up and fill up any left over gap should one still happen.
Now the result is like that:
It works like I expected on the lower half. But on the upper half, somehow the sideloaded science packs always manage to sneak in into the already fully compressed belt.
What is happening there? Is this a bug or a known issue?
Dark belt magic? Sideloading from two sides working differently?
Re: Dark belt magic? Sideloading from two sides working differently?
Those cases are not same because top sideloading puts items close to the left edge of transport belt while the sideloading from the bottom puts items close to right edge of the transport belt. On the left you also have sideloading which will force transport lines to be cut after 2 tiles which in this case will be really close to where the top sideloading happens from the last assembler. This behavior is just a corner case of how transport lines are woken up and their update order which for 1 tick when activating some lines may not be accurate causing sideloading to have apparent priority and being able to insert items into in between of 2 directly connected transport lines.
I am aware of this behavior but i have no better solution to get rid of it as other solutions would cause performance penalties.
I am aware of this behavior but i have no better solution to get rid of it as other solutions would cause performance penalties.
Re: Dark belt magic? Sideloading from two sides working differently?
Thanks for the reply. It's nice to understand the deeper mechanics in here. Well, it's not really an issue as I'm overproducing by a safe margin. And in doubt I can just lengthen the belt and merge them later.
Re: Dark belt magic? Sideloading from two sides working differently?
Hi Folks
so while i was creating a somewhat new Train-Unloading-Station i found something interesting.
This is what i've expected with my understanding of balancing and sideloading: A nice balanced Belt with almost no gaps
But the Outcome was this: Now, if you look closely, the only difference here is the red belt coming from the underground belt which is then sideloaded to the Output. This reminded me of this Thread. And yes, the problem is that Items can be sideloaded onto a belt even this belt is saturated and even worse, this sideloading belt can block the belt it is loading onto which means priority is messed up.
Not a big problem. But as i tried to understand whats going on there in the details, that really boggled my mind.
This image shows the exact same setup, but they behave differently. The upper one works as expected (Priority for the Items coming from the right Inserter). But the lower one had the issue that boskid mentioned (Priority for the Items coming from the left Inserter).
(To keep track of whats going on i placed those red and greens constant combinators)
The Video attached shows this in Action. (Recorded at 30UPS)
And now, to put this even further i made this testing setup:
So far so good. Until i removed a powerpole and everything... well... was messed up again. Belts that worked before now did that sideloading and vice versa. Removed the powerpole again. Nothing happened. Cut out segments of the build and copied back in again and stuff randomly changed. Moved segments a few tiles over and their behavior changed, moved them back, up, down, rotate, flipped, changed distances and all that.
Well, i tried to understand whats going on and i must say that this is the only thing that behaves inconsistent in the entire game. And from different posts i knew that Factorio was "fully deterministic"... so what if it wasn't?
Lets say i made blueprints for my unloading-stations and they behave differently?
Indeed, they are all the same, wired to a single master-combinator but the outcome is different. (The arithmetic combinators have no other use than to show the ingridients of the left and right chests)
In my case, this leads to uneven unloading of the chests which will delay the next train for unloading... and moving the belt one tile further does the fix. So not a big deal.
This Blueprint includes the Setup shown in the above image:
(After the Filterinserters are done with loading, deactivate the constant combinator (Iron) and activate the other (checkmark))
I'm not saying that this is "non-deterministic" or "random", this sure works as intended but the problem i have with this behavior is that it's out of my scope of understanding. I cannot reproduce the same outcome or maybe i just haven't found the right answers
So folks, keep an eye on your belts, maybe they do their own things. And with that i don't mean stuff like "WHY is there stone on my coal belt?"
so while i was creating a somewhat new Train-Unloading-Station i found something interesting.
This is what i've expected with my understanding of balancing and sideloading: A nice balanced Belt with almost no gaps
But the Outcome was this: Now, if you look closely, the only difference here is the red belt coming from the underground belt which is then sideloaded to the Output. This reminded me of this Thread. And yes, the problem is that Items can be sideloaded onto a belt even this belt is saturated and even worse, this sideloading belt can block the belt it is loading onto which means priority is messed up.
Not a big problem. But as i tried to understand whats going on there in the details, that really boggled my mind.
This image shows the exact same setup, but they behave differently. The upper one works as expected (Priority for the Items coming from the right Inserter). But the lower one had the issue that boskid mentioned (Priority for the Items coming from the left Inserter).
(To keep track of whats going on i placed those red and greens constant combinators)
The Video attached shows this in Action. (Recorded at 30UPS)
And now, to put this even further i made this testing setup:
So far so good. Until i removed a powerpole and everything... well... was messed up again. Belts that worked before now did that sideloading and vice versa. Removed the powerpole again. Nothing happened. Cut out segments of the build and copied back in again and stuff randomly changed. Moved segments a few tiles over and their behavior changed, moved them back, up, down, rotate, flipped, changed distances and all that.
Well, i tried to understand whats going on and i must say that this is the only thing that behaves inconsistent in the entire game. And from different posts i knew that Factorio was "fully deterministic"... so what if it wasn't?
Lets say i made blueprints for my unloading-stations and they behave differently?
Indeed, they are all the same, wired to a single master-combinator but the outcome is different. (The arithmetic combinators have no other use than to show the ingridients of the left and right chests)
In my case, this leads to uneven unloading of the chests which will delay the next train for unloading... and moving the belt one tile further does the fix. So not a big deal.
This Blueprint includes the Setup shown in the above image:
(After the Filterinserters are done with loading, deactivate the constant combinator (Iron) and activate the other (checkmark))
I'm not saying that this is "non-deterministic" or "random", this sure works as intended but the problem i have with this behavior is that it's out of my scope of understanding. I cannot reproduce the same outcome or maybe i just haven't found the right answers
So folks, keep an eye on your belts, maybe they do their own things. And with that i don't mean stuff like "WHY is there stone on my coal belt?"
- BlueTemplar
- Smart Inserter
- Posts: 3110
- Joined: Fri Jun 08, 2018 2:16 pm
- Contact:
Re: Dark belt magic? Sideloading from two sides working differently?
Let me guess... show-tile-grid strikes again ?
BobDiggity (mod-scenario-pack)