Factorio Forums

Here's a design for overflow splitting in vanilla Factorio. Two input belts, two output belts, one output belt is filled and overflow goes to the other belt. Tearing is caused by some V-sync issues I couldn't figure out.
There are a couple weaknesses (beside that the solution isn't as compact as I'd like it to be):

• When there's very few items on the input belts some items will end up on the overflow belt even if the prioritized belt isn't full. This can actually easily be solved by adding a Constant combinator that output 1 of the item on the belts and that's connected to the three circuit belts. You'll also have to (or should) increase the enabled condition on the top left circuit belt from 12 to 13. I did not add it because it isn't really a significant issue, and because the design as it is works with any types of items on the belt. If you add a Constant combinator you'll have to change the output signal depending on what kind of item is on the input belts.
  Or you can simply set the belt with enabled condition to be "Anything > 8" instead of "Everything > 8". Blueprint updated.
• Sometimes sideloading takes precedence over the belt you're sideloading onto (even though the belt is fully saturated). I suspect this might be a bug in the game. This cause the bottom belt (in this case) to stutter on the input side.
  Stuttering

  

  overflow_splitting_stutter.gif (7.4 MiB) Viewed 12681 times

  Sorry about the bad quality, didn't have the right encoding settings and deleted the video source before I could fix it.

Edit: Changed condition from "Anything > 12" to "Anything > 8". In some cases "Anything > 12" could result in reduced throughput, changing it to "Anything > 8" prevents this from happening, but increase the probability that gaps will occur in prioritized output belt when there are abrupt changes in input belts.

I have yet to see anyone make one here that is reliable and doesn't kill your throughput. The top lane was clearly stutter stepping when you removed the inserters.

The fundamental issue is how the signals pulse for items on belts in hold mode.. they stutter step between 6 and 8 even for a fully compressed belt, so you can't rely on a fully compressed belt having anything other than > 5.

Innomin8 wrote:I have yet to see anyone make one here that is reliable and doesn't kill your throughput. The top lane was clearly stutter stepping when you removed the inserters.

Can you elaborate a bit on this?
I know the top output belt (the overflow) is creating some "pulses" when I removed the inserters, but this is due to the "buffer" (the two belts after the second splitter) catching up. As far as I've tested neither the two input belts stutter regardless of how many items are going through, as long as the output is fully consumed.

I've gotten good results by simply scanning a bunch of belt sections on the priority line at once, and telling the overflow line to wait until there's an average of 6-7 belts components across all of them the priority output belt section.

Mehve wrote:I've gotten good results by simply scanning a bunch of belt sections on the priority line at once, and telling the overflow line to wait until there's an average of 6-7 belts across all of them.

Without testing, I'm fairly sure that if both input belts receive about 3 fully saturated belts at the same time (while output belts are completely empty), that will cause both input belts to be slowed as the overflow belt is disabled as the average of the belt tiles on the prioritized output won't average to 6-7 before a fair amount of output has been processed in the splitter.

I'm otherwise curious what benefits the "Overflow manager 1" brings to my design, can you elaborate what you're trying to achieve here?

Completely unrelated, but I like your username. Any chance you've taken it from Nausicaä of the Valley of the Wind?

Heh, I've used this handle for a decade or two by this point, but that was the origin way back, yes These days, it's still usually up for grabs, eliminating the need for adding random numbers at the end.

The first image was just a direct build off the original design. It used to be (and I'm fairly certain it still is the case) that side-insertion wouldn't give you full compression, and couldn't insert into a nearly-compressed belt, pretty sure that hasn't changed, so if the primary belt was only mostly full, the balancer section wouldn't actually improve things.

The second design is purely splitter and can therefore compress fully, but won't move stuff across lanes to fully fill a belt.

Not quite sure what you mean by the first part, but I think I mistyped. Average of 6-7 components/belt section, I meant. Does that make more sense?

Mehve wrote:Heh, I've used this handle for a decade or two by this point, but that was the origin way back, yes These days, it's still usually up for grabs, eliminating the need for adding random numbers at the end.

Studio Ghibli <3

Mehve wrote:The first image was just a direct build off the original design. It used to be (and I'm fairly certain it still is the case) that side-insertion wouldn't give you full compression, and couldn't insert into a nearly-compressed belt, pretty sure that hasn't changed, so if the primary belt was only mostly full, the balancer section wouldn't actually improve things.

I believe they actually fixed side loading pretty well some time ago. I saw someone write about a very specific case where side loading didn't produce a fully saturated lane, but that was some time ago and I can't recall where. In my testing I've not seen this issue myself. Both lanes have been fully saturated as long as the top input is also fully saturated (with the possibility of a small hickup just as the "buffer" before the sideloading is being filled up).
In fact, side loading compress the belt so well now that it even moves items backwards on the belt to fill in those tiny gaps. This on the other hand is likely what's causing the stuttering I mentioned in the "weakness" section.

Mehve wrote:Not quite sure what you mean by the first part, but I think I mistyped. Average of 6-7 components/belt section, I meant. Does that make more sense?

I can try to explain differently:
Am I assuming correct if you set the 5 circuited belts on the prioritized output to "read" and "hold"? And the circuited belt on the overflow output to "enable" if "anything > 30" (or another number in that region)?
If so, when both input belts receive a fully saturated stream of items on the belt, the overflow output will be blocked until the items have passed at least to the 4th belt on the prioritized output (with a max of 8 items per belt, you need to fully saturate 4 belt tiles). This means that for a time you're joining two fully saturated input belts, but only have one output belt for a short time. The inputs have to be slowed until the overflow belt is enabled.

If side-loading now gets 100% compression, that would be awesome. I may have to do some testing myself, to see if things have changed.

Edit: Yeah, I see what you're talking about now. The situation only arises when you go from both input belts equaling less than 100% of one input belt to more than 100%. At that point, you would have a delay equal to the belt speed X number of circuited belt scanners that need to re-saturate. During this delay, anything over 100% of the primary belt wouldn't be allowed to pass through. Your situation incorporates a buffer that would mostly eliminate that. So I guess it's a question of how stuttery or sporadic your input lanes are? But I can see where you would want to double-check on that.

Alright, this design should handle that little delay issue better. Sandwich the belt scanners between two splitters, put the overflow stop after the second splitters. The gap between the two seems to buffer enough to ensure that pretty much all the input can be accepted through the stoppages. See picture below - I've tested with a variety of red and yellow belts as chokes on the input side, it seems to take everything in stride. The lane balancer up top is optional and can easily be replaced with a straight belt section.

Interesting design and I honestly thought it could work well, but alas I was able to make the input belts stutter for a while with this setup: Simply starting the item source for the bottom input belt first and then the item source for the top input belt caused some temporary stutter on both input belts.

I can try to explain what's going on in my design, but I realize that my teaching skills are quite subpar.
The problem is that even though you're reading from multiple belts, you still can't tell whether the items on the belt are stationary or moving. Neither can my solution, but I've used a trick: I'm splitting one of the input belts into two belts, then I read the contents for the two new belts. There's something we can deduce from this: If these two belts together contain no more than 8 items, then we're fully consuming the items, and if the belts exceed 8 items then consequentially we know that we're not fully consuming the items. When you don't split up one belt into two tracks then you can't possibly know if the items are fully consumed. Anything > 5 can both mean that the track is backed up and is moving at full throughput. By splitting one track into two you have a way to tell whether the items on the belt are fully consumed or not.
That's part one of the solution, here's part two:
We need a way to join the items from two tracks to one track, without slowing down either track. We've solved this for one track by splitting it up into three tracks; The first track is the one we block when the two next tracks aren't building up items on the belts. The two last tracks also acts like a small buffer.
It's tempting to just slam on a couple splitters to join the tracks again, but the problem with splitters is that when you have two inputs and only one output, then you will slow down both inputs as long as they're fully saturated. It's possible you can achieve something by giving the other input (that wasn't previously split into two tracks) a small buffer by splitting this too into a couple tracks, but this design will likely become complex and have a fairly large footprint. Simply side loading onto the track is a much simpler solution as the side loading will not happen as long as the output track is fully saturated*.

* Again as mentioned earlier, sometimes the game prioritize side loading over a fully saturated belt. I don't know why and it doesn't happen every time (for me it's been fairly rare). When it happens it seems like the side loading happens exactly every 40th tick in the game**. Another point I mentioned earlier is that side loading can push items backwards on the belt, this can cause a single stutter when the bottom belt in my design goes from not saturated to fully saturated.

** Edit: I believe it should be mentioned that I'm using Creative Mode mod to fully saturate a belt. I can't rule out that this mod doesn't fully saturate a belt, it is possible that this mod leaves tiny gaps which is causing the stuttering that sometimes happen.

Just a little note: I've used Anything > 12 in my setup to allow a slightly larger buffer. I could've used > 8, but I feared timing or entity prioritization in the game could cause some hickups.

You might wanna try to use "U" shape turned belts to fill up the gaps.