If you load a yellow splitter using a blue belt, then prioritize a lane that is backed up, the next item to reach the splitter will receive an item that the splitter was "holding onto".
Pictures attached, along with save that demonstrates this (and obligatory logs).
I expected the splitter to have already "resolved" the last split, and that the same item that was coming down the lane would be "split" onto the non-prioritized output lane. Instead, the splitter appears to "resolve" the last split when it receives the next item, causing the wrong item type to proceed down the lane.
I've noticed that this doesn't seem to occur with non-compressed belts, but this should be re-verified.
Since I'm trying to develop a system where multiple item types share the same lane (at different time intervals, gated via circuit network), this bug is messing up my attempts at doing so, because if the belt gets compressed at any point, it will cause mis-sorting.
After typing all this up, I decided to see what would happen if I remove the priority on the splitter. When I do, the splitter immediately releases the "held" item onto the (formerly unprioritized) lane. It does this as soon as I click to remove the priority, even with no further items being input to the splitter.
[1.1.5] Priority splitter "hangs on" to item
-
ronnocerman
- Manual Inserter
- Posts: 1
- Joined: Sat Dec 26, 2020 7:54 pm
- Contact:
[1.1.5] Priority splitter "hangs on" to item
- Attachments
-
- factorio-current.log
- (248.33 KiB) Downloaded 90 times
-
- BugDemo.zip
- Place a solar panel to demonstrate the bug.
- (1.22 MiB) Downloaded 80 times
-
- Initial state. Left side has been fully loaded using a compressing, faster belt.
- Bug1.png (812.23 KiB) Viewed 2628 times
-
- Copper is placed onto belt.
- Bug2.png (1017.08 KiB) Viewed 2628 times
-
- Splitter "releases" iron it was holding onto. Starts holding onto the copper. (Bug)
- Bug3.png (984.88 KiB) Viewed 2628 times
-
- Loading an iron to show that the splitter is "holding onto" the last copper.
- Bug4.png (1.27 MiB) Viewed 2628 times
-
- Copper appears on the output belt. (Second demonstration of same bug)
- Bug5.png (1.32 MiB) Viewed 2628 times
Re: [1.1] Compressed(?), full belt with priority splitter causes splitter to "hang on" to a resource.
I'm fairly certain this is by design (splitters have a small internal buffer), let me look for a reference on that - I know there was some reason it was added.
There are 10 types of people: those who get this joke and those who don't.
Re: [1.1.5] Priority splitter "hangs on" to item
56446 is the closest I'm coming up with. I know I've seen something clearer elsewhere, if anyone else wants to jump in feel free.
There are 10 types of people: those who get this joke and those who don't.
-
NotRexButCaesar
- Smart Inserter
- Posts: 1120
- Joined: Sun Feb 16, 2020 12:47 am
- Contact:
Re: [1.1.5] Priority splitter "hangs on" to item
whatever the case, this is 100% not intuitive:
- Attachments
-
- 1.jpg (98.3 KiB) Viewed 2375 times
Ⅲ—Crevez, chiens, si vous n'étes pas contents!
Re: [1.1.5] Priority splitter "hangs on" to item
I'm not sure what you're trying to get at, but it's not the same thing as this report is about.
There are 10 types of people: those who get this joke and those who don't.
-
NotRexButCaesar
- Smart Inserter
- Posts: 1120
- Joined: Sun Feb 16, 2020 12:47 am
- Contact:
Re: [1.1.5] Priority splitter "hangs on" to item
I was responding to the content of the linked posts
Ⅲ—Crevez, chiens, si vous n'étes pas contents!
Re: [1.1.5] Priority splitter "hangs on" to item
That is also not the same as any of the linked posts. If you think there's a bug, report it.AmericanPatriot wrote: ↑Wed Jan 06, 2021 11:05 pmI was responding to the content of the linked posts
There are 10 types of people: those who get this joke and those who don't.
Re: [1.1.5] Priority splitter "hangs on" to item
A side effect of the tricks done in order to make the splitter work correctly (full compression in all situations etc.)
I consider this to not be a bug.
I consider this to not be a bug.