Factorio Forums

Hello. Community, I need your help in solving my today's "puzzle". Saying it short, solving an issue the eligant way may result in being helpful for me. So, consider this as a thing to do, if you have nothing else to do.
I will definitly try to solve this one myself (mainly because I need this for my planwork), but I am absolutely sure I am not the smartest and most resourceful guy in this game, and community will come up with better solutions.
I am not a novice either, I have solved dosens of this-kind-of issues, which looked harder at the first glance, than this one. But spent over 30 minutes of trying to create a stable theoretical plan, and came up with nothing working like it should.

So it is either hard puzzle, or I've got a brain lag, and can't see an obvious solution.

Here is the puzzle description:

- Create a belt mechanism with specifications: 2 blue belt inputs, 2 blue belt outputs. Let's specify, that outputs are called O1 and O2, inputs - I1 and I2. Let's also specify, that "1" is a fully loaded output (max throughput is achieved with no gaps), "0" - is an empty belt, and all the possible throughputs are fractions.
- Mechanism's logic:
Informal explanation:
Create a durable throughput sorter, which supplies maximum throughput to O1, pushing whats left to O2.
Formal explanation:
if (O1 is not filled externally) then
_{if (I1 + I2 <= 1) then
__{O1 = I1 + I2; O2 = 0} else
__{O1 = 1; O2 = I1 + I2 -1}} else
_{O1 = 0 (O1 is filled); if (O2 is not filled externally) then
__{O2 = I1 + I2} else
__{O2 = 0 //Which results in a whole mechanism blocked}}
- Inputs can have any combination of incoming throughputs, example "1+0", "0+1", "1+X", "X+0", ect. It should be stable in any case.
- No usage of mods. Vanilla solution is required.
- Mechanism should be as light on game resources, as you can come up with. Imagine, that a map will use hundreds of those, and think about UPS. I am not really interested in large solutions.
Examples of a solutions, which are not acceptable for me: large inserter-based reloader with a sleeve merge, Bot-based reloading station.

I will be really glad and probably learn some more tricks, watching your submissions, if there will be!

There is no elegant (small, simple, 100% accurate) way to do it. Assume that it is impossible, and design your factory a different way.

Maybe split your assembly line in half, and run each blue belt though a different half. That way upstream assembly machines still get priority, and you still get 2 blue belts of throughput.

Thank you for providing your thoughts. I was thinking about pure belt-splitter setup being impossible too, with the exact conclusions of 1/inf you came with, but I was scared that I may be wrong.
Past hour or more was trying to figure out splitter-belt-combinator way to do this, but no luck. What you wrote about completely full belts is true, but I was thinking a bit simplier, considering >38.5i/sec as a full belt, as my consumer does not need more than that. Thechnically not full, but adds simplicity with throughput mesurement. But I ran into another problem I struggle to solve - how to properly find out (during measurement), that belt is externally throtteling after the output?... Couldn't make determination of either the throughput is really <38.5, or the belt is throtteling, and "things are fine" with 2 wired belts.

Yeah, just clearifying - I will think of another solutions of my problem, if we won't find out, how to make such a "sorter" the eligant way. I am just theorycrafting and doing abstract plans.

For me this one is almost funny... It's like a Ferma's theorem - the action is logically-easy, but the implementation of this thing may waste dosens of hours of theorycrafting and thinking.

I am really bad with wires and generally just play without them, but i do thinkk this should be possible with wires.

This was the first thing I intuitively tried, when this puzzle came upon me. One splitter and two wired belts, one with gate and the other one with a signalgen.
Sadly, this won't work as the puzzle requires, because the moment "gate" opens and splitter switches from "merge in one" to "equalize", both equilized outputs will be less than 1 in all cases except both inputs are 1. And sag on O1 will be quite large, if I1+I2 were not close to 2. I also don't think those pre equalizers make a difference - as they do not synchronise gaps to flow at exactly same places. Which makes them useless, considering wired belt can only turn on/off both sides simultaniously. Add on top of that your early mention, that 1 wired belt can either contain 6 or 7 items, which results in 2-itemed spits from the O2. And the latencies...

Yeah, that was the moment I understood, that it's harder than it seems at first glance. And made this thread

This is indeed not that easy to achieve. I fooled around for a few minutes but gave up trying to make it small enough to fit your problem.

You need to count the overflow of items which won't fit onto one belt, which can be done pretty easily. One belt can handle 10 items every 15 ticks. By counting the inflow and saving the overflow every 15 ticks you get the exact amount of items that should be extracted from the belts and send to O2. Everything else goes to O1.
The extraction of a specific amount is not that simple. You need to split the two belts into four lanes so you can let a single item pass, if necessary, and you need to evenly distribute the overflow among all four lanes.
That contraption won't be cheap nor compact at all.

You could rethink your problem though. Maybe process the items from both belts and whatever remains is considered your O2, if your factory extracts exactly the amount one fully loaded belt can handle.

Okay community, I had some luck to find out this thread when I was searching for something completely different.
https://www.reddit.com/r/factorio/comme ... ompressor/
Seems like someone already asked for this 5 month ago, and this is called "prioritised splitting".
And there is a solution in that thread, first post. It's very close to the DaveMcW's last picture, and I am doing the test regarding the difference.

But due to:

Losash wrote:Sadly, this won't work as the puzzle requires, because the moment "gate" opens and splitter switches from "merge in one" to "equalize", both equilized outputs will be less than 1 in all cases except both inputs are 1. And sag on O1 will be quite large, if I1+I2 were not close to 2.

I think that both solutions struggle to fill O1 if inputs are not stable. I need to do a deeeper test on this. Will update when I'll clearify if things really work or not.

UPDATE 1: Regarding second spletter - yes, it is needed. Test on "1+0.5(lanes eq)" inputs showd, that DaveMcW's sollution throttles the "1" input externally, even though O2 could throuput the excess. Splitter before the measurer does exactly what is needed to solve that problem of unequal throttle: (I1+I2)/2.

I came up with something simpler. It's still pretty bulky though.



It needs a lot of testing, but I think it's very accurate. I'm sure it can be optimized as well.

Actually I was playing all day today, working on this single project, nothing else. First I made tons of tests, and found out, that Reddit solution, I posted higher in the thread works pretty accurately, only making some gaps if inputs have fast inconsistent flow change. Well, still it outputs close to what I need (38.5i/s).

So, Reddit sollution, or slightly modified DaweMcW's solution are fine answers to the problem I gave at the start of this post.

But during those tests I found out, that I wanted to make a more complicated version of "prioritised splitter", in terms of features.

Even though I already kind of think of either using completely other principle in the part of my base, I decided to finish this project:

It is a lot more complicated than basic "prioritised splitter" (with 2 splitters and 3 linked conveyers) because my version has following addons:

1) If I1 provides "1", lanes become fully isolated. I2 goes to O2 bypassing main mechanism.
1) If O2 is blocked (filled externally), I2 becomes blocked, if I1's rate is less than 1. So if I1 can provide "1", I2 is not used.
3) If O1 is blocked (filled externally), no matter what was the combination of the inputs, only I1 becomes blocked due to that, I2 continues flowing at it's rate to O2.
4) Maybe other stability improvements, can't remember. I've already quited the game for today.

Third feature was extremely hard for me to do, because it was not working as described with separated inputs less than "1". I even had to add 2 combinators, because found no better solution.

I needed those features, because I wanted to be able to have stable inline connection of several of those. What I mean is to connect O1 of one of those to the I1 of the other one, and so on. This would allow "feeding up" the main, first, line with any amount of completely independent "second lines", which are not throttled by the main line conditions, and only share with the main line, if it's not full or blocked.

I'm sorry, but General Board is not Help Board.
Moved.