Smart Splitter Experiments

eugenekay · Post by **eugenekay** » Tue Sep 23, 2025 4:26 pm

Continued from Splitter gives one side priority when both circuit conditions are true (which is "Not a Bug")

boskid wrote: Mon Sep 22, 2025 9:03 pm
robot256 wrote: Mon Sep 22, 2025 8:53 pm So the truth table is:
If you want a truth table for the "set input side", it is as follows:

09-22-2025, 23-03-21.png (8.83 KiB) Viewed 1031 times

robot256 wrote: Mon Sep 22, 2025 9:29 pm Thanks. So if you do happen to want the splitter to give equal priority when both sides are "requesting" it with a true condition, you will need to duplicate both conditions in combinators and, if they are both true, negate both of them before sending to the splitter.

The Splitter has a "Memory" now, so the behavior of the Priority switches is dependent upon the previous Setting. This works fine for the Default logic which uses the same Signal for the Left/Right lanes, since the I/O signal will either be Less than 0, or Greater than 0 - not both at once.

: 09-23-2025, 12-09-35.png (79.44 KiB) Viewed 1031 times

However, there are many more complicated mechanisms which may be desired, such as two "Demand lanes" coming off a single Feeder. I built this Mechanism to pass a L/R signal if the other signal is not active, which seems to work well. I prefer this over using a Negate signal (as suggested above) , but I don't like that it requires a separate Signal pair / Second Combinator to handle Input and Output.

: 09-23-2025, 12-22-34.png (152.09 KiB) Viewed 1031 times

I am curious if anybody else has a better idea to achieve this in a single Combinator? I fiddled with the Each/Anything/Everything signals to try to detect a "Transition" and reset the Splitter by not passing any Signals for 1 tick; but I was not happy with the results. What do you think?

robot256 · Post by **robot256** » Tue Sep 23, 2025 6:30 pm

If your input signals are only 0 or 1, you can do it with no combinators:

Left: L>R
Right: R>L

Then if R=L the priority will be equal.

If your signals are 0 or any positive number, you still need a single decider combinator, but the setting is simple "If Each > 0, output Each=1".

robot256 · Post by **robot256** » Wed Sep 24, 2025 1:10 am

I finally sat down and played with the existing implementation a bit. It is possible to accomplish basic tasks without being affected by the side-memory feature, but it's not intuitive at first.

I had two applications in mind. The first is sorting the output of a recycler. The second is prioritizing ingredient flow on a bus, for example of spoilable nutrients. The caveat is that most of this can technically be accomplished with enough wires on belts and inserters. So the goal of using splitters is to make it cleaner and more intuitive.

The sorting application turned out to be very effective, but requires a lot of combinators. The benefit is that using circuit-configured filters, "no filter" completely disables one side of the splitter and all items are sent to the opposite side.

: 09-23-2025, 20-57-02.png (3.1 MiB) Viewed 902 times

This is exactly what I want for a sorting machine overflow behavior. The complication is that it only works if you have a dedicated signal for each splitter that either contains the item you want, or nothing. You can't say "set the filter to Iron gear if Iron gear < 0" without the extra combinator. Setting the side selection at the same time as the filter doesn't help at all, and I'm doubtful that ability will ever be useful.

----------------------

The priority machine is more nuanced, and this is where we can potentially see the effect of the state memory.

Example 1: Set the splitter so that whichever side is low requests priority. This works at first, but as soon as one of them is full, the other one gets priority. When the first output becomes empty again, it can't get priority back until the second output is completely full, and then it ping-pongs back and forth unless both of them become full at the same time.

: 09-23-2025, 21-02-14.png (3.16 MiB) Viewed 902 times

Example 2: Set the splitter to equalize both outputs. This is what I normally do with inserters. It works fine if that's what you need.

: 09-23-2025, 21-04-19.png (1.93 MiB) Viewed 902 times

Example 3: Opposite of the first example. Set the splitter so that instead of "requesting" items for the empty side(s), whichever side is full requests it for the *other* side. This has the advantage that the splitter gets "stuck" in its memory state only after both sides are full. As soon as one side empties, the other side will force priority to the empty side.

: 09-23-2025, 21-06-25.png (1.43 MiB) Viewed 902 times

Example 4: Same as Example 3, but now with the extra combinator used to enforce "true/true = equal priority".

: 09-23-2025, 21-07-06.png (5.32 MiB) Viewed 902 times

Conclusion: In these basic examples, the memory behavior either doesn't affect it at all, or can be worked around in simple but non-obvious ways. I haven't thought of a simple case where it is advantageous yet.

fi5hii · Post by **fi5hii** » Thu Oct 02, 2025 3:40 pm

Continuing from splitter not resetting output side with "set filters" (declared not a bug)

There is currently no way to set the priority output back to middle when the "set filter" is checked (to basically choose when you want the splitter to act like a normal splitter and when to act like a regular splitter). This is currently possible with the splitter if you're not using the set filter. I would use this when rebooting bacteria on gleba, I have a looped belt with bacteria on it and if it backs up I have a machine that places the first bacteria on but I want the splitter to filter so the bacteria stays on the loop guaranteed and the iron ore goes off. When there's enough bacteria on the loop I want it to act like a regular splitter that way half of the bacteria stays on the balt and half of it goes off to spoil.

I managed to make a janky version of what I would need by pulsating filters every 2 ticks which makes the turbo splitter with no items filter work as if there weren't any filters on it and splits the belt in half.

here's a video (.mov file because travelling with macbook) demonstration how my janky setup fixed the issue.
And here's the blueprint of said janky fix:

eugenekay · Post by **eugenekay** » Thu Oct 02, 2025 4:12 pm

CuervoDePlaya wrote: Thu Oct 02, 2025 2:35 pm Having just downloaded 2.0.69 and got to work rightaway with a splitter connected to a decider combinator in order to split a belt into a 20/80-division. But I can't seem to get that working. Is there a little manual somewhere on how to accomplish that?

This setup switches between Left and Right output priority every 30 Ticks (half-second), using a single Combinator for a 60-Tick (1 second) Clock.

: 10-02-2025, 12-06-19.png (285.53 KiB) Viewed 583 times

When built with lower-tier Belts the output ends up slightly Biased towards one side, because "15/30/45" Items/Second (7.5 / 15 / 22.5 Items/Lane/Second) are not perfectly divisible by 2. You could probably use a different Clock length to account for this, but I always use Turbo belts anyway.

It could be improved by counting Items using "Read belt contents - Pulse" instead of a Clock, but I have not found a solution I am happy with yet.

computeraddict · Post by **computeraddict** » Thu Oct 02, 2025 5:02 pm

It should be easy enough to do a N:M split with a single decider in accumulation mode. Splitter goes left when count < N, right when >= N, and decider resets when count >= N + M. I've probably got some off-by-one errors in this logic, but the principle seems solid.

fi5hii · Post by **fi5hii** » Thu Oct 02, 2025 5:32 pm

computeraddict wrote: Thu Oct 02, 2025 5:02 pm It should be easy enough to do a N:M split with a single decider in accumulation mode. Splitter goes left when count < N, right when >= N, and decider resets when count >= N + M. I've probably got some off-by-one errors in this logic, but the principle seems solid.

I made this:

: 10-02-2025, 19-31-59.png (169.77 KiB) Viewed 538 times

it's a 60 tick timer, you enter the % of the amount you want on the left belt into the constant combinator that calculates percentage into negative ticks then removes that from the 60 tick clock and the splitter is set to be on left belt when the number is negative.

eugenekay · Post by **eugenekay** » Thu Oct 02, 2025 5:48 pm

Interesting combination of Timer + Counter! I will play around with that idea some more.

My 20/80 Counter-Splitter (work in progress):

: 10-02-2025, 13-42-54.png (349.98 KiB) Viewed 530 times

It only works "correctly" when the C signal adds up to exactly 100. When using Stack Inserters the value can go above 100, which throws off the output counts slightly. My desired use-case is to take proportional outputs from a Sushi belt / Scrap Sorting, so it has to be able to deal with heterogenous Item inputs - not just counting a single Item at a time.

coffee-factorio · Post by **coffee-factorio** » Thu Oct 02, 2025 11:16 pm

eugenekay wrote: Thu Oct 02, 2025 4:12 pm It could be improved by counting Items using "Read belt contents - Pulse" instead of a Clock, but I have not found a solution I am happy with yet.

This does in fact work. But there's some caveats to the system. It seems like it works best on persistent input, and you want to have it running over relatively long period. The other thing is that some splits aren't possible, at least on some periods. For instance: I did a 1/5 as Out < 5 ? left : right on a period 30 counter. Got 4 : 28, or 1/7. Tried on a Out < 8 ? left : right on a period 40 counter next. That got me 8:32, or 1 to 4 for a true 1/5 split. So I'm betting you want this to be a common multiple of 2 if you're balancing on a half full lane and 4 at all other times.

Someone should pin down if this suffers from combinator lag. Edit: or if there's some edge case from having entities inside the splitter.

Debussing a single item seems to be its best use. On Space Platforms, I drop my current 3 splitter setup to 1 splitter 1 combinator. I take 1 kw power, but if that kills me I probably deserve it. 2 splitters of any kind are going to be more expensive than a single combinator.

Another edit : I'm using a variation of robot256's setup: ( asteroids_at_workstation < magic_constant ) ? asteroid : None . Theirs is one for the wiki, since it shows how to manipulate onto 2 systems.

coffee-factorio · Post by **coffee-factorio** » Sun Oct 05, 2025 3:59 am

I put some more work into this.

Some things came up: timer based splits work conditionally because they don't actually count items that can be "predicted to move" between a ticks. But this isn't necessarily a clear fail, it's a case by case fail when you can't divvy up items between ticks. So we're talking about 3/16 splits of a belt.

And trust me, the first thing I did was set up a 192 tick clock to see if it could perform like the rest of what I observed.

It displeases me because people put good work into it. And it does work conditionally, but there's a tendency to not see a partial win as a win.

Another way they fail is that a splitter moves 2 items in sequence if it can. So a 1-4 split will never work with a condition set to say "move 1 part at some time" unless you limit i/o to one side of a belt.

To make matters even more fun. Splitters shove a certain amount of items through their feed. So a counter based split lives in a funny world where, yes it's simple to make a split that works. But that means you account for it pushing 2,4,6,8 items through the belt.

So what I do is take a m/b split. Say that means I set m items on side L and n items on side R. And b = m + n.
Then an accurate split is made by setting cb = cm + cn, where c is a constant determined by belt speed.
Bigger counts can be downgraded on a counter (on a timer, this is not the case since it counts ticks instead of items on a belt).

A constant count that "universally works" for a 1/4th split is a 32:96 splitter on a 128 counter.

A 2:6 will work on a yellow belt but as soon as you upgrade it to red it fails to feed. A 32:96 is going to take ~2.2 seconds to feed and then 6.4 seconds to feed the large side on a yellow belt. Granted the mechanism is manipulating output priority unless you set a proxy filter to make it not, so it's UTU until it sees something blessed like a promethium asteroid filter. But the outcome is going to be new fodder for the meme board on reddit.

And there's something odd where splitters that are divisible by 15 want n < Output, n >= Output. But splitters divisible by 30 want n <= Output, n >= Output.

coffee-factorio · Post by **coffee-factorio** » Sun Oct 05, 2025 4:06 am

: Screenshot 2025-10-04 220411.png (1.24 MiB) Viewed 235 times

A timer based 2:6 vs. a counter 2:6 when a belt is split 3/4.

Factorio Forums

Smart Splitter Experiments

Smart Splitter Experiments

Re: Smart Splitter Experiments

Re: Smart Splitter Experiments

Re: Smart Splitter Experiments

Splitter 30/30

Re: Smart Splitter Experiments

Re: Smart Splitter Experiments

Re: Smart Splitter Experiments

Re: Splitter 30/30

Re: Smart Splitter Experiments

Re: Smart Splitter Experiments