Green Circuits are priority on the side
It is not always inserted, sometimes yes, sometimes not.
[0.16.49] Offloading belt can get priority when sideloading
[0.16.49] Offloading belt can get priority when sideloading
- Attachments
-
- Factorio 2018.06.10 - 14.46.24.02.gif (101.29 MiB) Viewed 3004 times
-
- New 16.zip
- Save
- (13.68 MiB) Downloaded 96 times
-
- factorio-current.log
- Log
- (51.77 KiB) Downloaded 103 times
Re: [0.16.49] Green Circuits
I don't see a bug there.
Re: [0.16.49] Green Circuits
The belt feeding from the top is backed up, so no items from the belt coming from the right should fit on it, yet items on the right lane of that belt squeeze into the left belt. Items on the left lane stay.
There is probably a split between two belt lines between the first and second belt in front of the splitter, which is exactly where the right belt is feeding into it. In that case, the belt in front of the splitter will unpredictably pull items from the top belt and right lane of the right belt, even though the player would expect it to only pull items from the backed-up top belt. This issue appears whenever a belt is side-loading into a split between belt lines.
There is probably a split between two belt lines between the first and second belt in front of the splitter, which is exactly where the right belt is feeding into it. In that case, the belt in front of the splitter will unpredictably pull items from the top belt and right lane of the right belt, even though the player would expect it to only pull items from the backed-up top belt. This issue appears whenever a belt is side-loading into a split between belt lines.
- TruePikachu
- Filter Inserter
- Posts: 978
- Joined: Sat Apr 09, 2016 8:39 pm
- Contact:
Re: [0.16.49] Green Circuits
If you really want priority merging over there, I'd suggest to, as a workaround, sideload those green belts onto an empty belt (possibly; this is so there's only a single lane) and feed that and the belt being merged into a splitter with the input priority correctly configured.
The belt changes that led to the always-compress functionality make this sort of sideloading compression slightly unpredictible (it depends on belt speeds and how backed up they are).
The belt changes that led to the always-compress functionality make this sort of sideloading compression slightly unpredictible (it depends on belt speeds and how backed up they are).
Re: [0.16.49] Green Circuits
That belt which is sideloading onto the belt before the splitter. If you want to use the splitter priority logic, then you need to actually feed the belt into the splitter, rather than sideload onto the belt. eg something like.
Re: [0.16.49] Green Circuits
101 MB gif! Please don't do that.
Re: [0.16.49] Green Circuits
That fixes the OP’s problem, but doesn’t change the fact that items from a sideloading belt are squeezing onto a fully backed-up belt, which is not what one would expect.Zavian wrote:That belt which is sideloading onto the belt before the splitter. If you want to use the splitter priority logic, then you need to actually feed the belt into the splitter, rather than sideload onto the belt. eg something like.
- TruePikachu
- Filter Inserter
- Posts: 978
- Joined: Sat Apr 09, 2016 8:39 pm
- Contact:
Re: [0.16.49] Green Circuits
Like I said, it's situational depending on factors such as the belt speed and I believe the actual positions of items on the belt being sideloaded onto. Sometimes it favors keeping the flow and preventing the sideloading, sometimes it prefers to sideload instead. It might also relate to belt segment split points from the belt optimizations, and segment update order (hopefully it isn't another build-order-dependent sort of thing).