[0.16.49] Green Circuits

Bugs that are actually features.
Post Reply
del24
Manual Inserter
Manual Inserter
Posts: 4
Joined: Sun Jun 10, 2018 12:59 pm
Contact:

[0.16.49] Green Circuits

Post by del24 »

Green Circuits are priority on the side

It is not always inserted, sometimes yes, sometimes not.
Attachments
Factorio 2018.06.10 - 14.46.24.02.gif
Factorio 2018.06.10 - 14.46.24.02.gif (101.29 MiB) Viewed 2483 times
New 16.zip
Save
(13.68 MiB) Downloaded 74 times
factorio-current.log
Log
(51.77 KiB) Downloaded 83 times

kovarex
Factorio Staff
Factorio Staff
Posts: 8078
Joined: Wed Feb 06, 2013 12:00 am
Contact:

Re: [0.16.49] Green Circuits

Post by kovarex »

I don't see a bug there.

kitcat
Long Handed Inserter
Long Handed Inserter
Posts: 66
Joined: Wed Apr 26, 2017 3:11 pm
Contact:

Re: [0.16.49] Green Circuits

Post by kitcat »

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.

User avatar
TruePikachu
Filter Inserter
Filter Inserter
Posts: 978
Joined: Sat Apr 09, 2016 8:39 pm
Contact:

Re: [0.16.49] Green Circuits

Post by TruePikachu »

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).

Zavian
Smart Inserter
Smart Inserter
Posts: 1641
Joined: Thu Mar 02, 2017 2:57 am
Contact:

Re: [0.16.49] Green Circuits

Post by Zavian »

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.
merge.jpg
merge.jpg (193.64 KiB) Viewed 2359 times

User avatar
darkfrei
Smart Inserter
Smart Inserter
Posts: 2903
Joined: Thu Nov 20, 2014 11:11 pm
Contact:

Re: [0.16.49] Green Circuits

Post by darkfrei »

101 MB gif! Please don't do that.

kitcat
Long Handed Inserter
Long Handed Inserter
Posts: 66
Joined: Wed Apr 26, 2017 3:11 pm
Contact:

Re: [0.16.49] Green Circuits

Post by kitcat »

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.
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.

User avatar
TruePikachu
Filter Inserter
Filter Inserter
Posts: 978
Joined: Sat Apr 09, 2016 8:39 pm
Contact:

Re: [0.16.49] Green Circuits

Post by TruePikachu »

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).

Post Reply

Return to “Not a bug”