Conveyor Splitter: Controlled resource distribution between asteroids

[Meltdown]

Conveyor Splitter is a contraptition than allows to split the contents of a single conveyor into multiple conveyors in defined ratios. Actually, I came up with this idea back when Banhi's Automation Pack was released. I made it as a fun challenge inspired by factorio, and quickly forgot about it, because there was no strong use cases for it (at least in my regular playthroughs).

With introduction of Spaced Out, the concept gained a good use case: Distribution of resources between asteroids. For example, I used Conveyor Splitter to setup centralised food production at my starting asteroid, and distribute food between main asteroid and warp pipe asteroid. With new durability mechanic in may also be convinient to centralise reed fiber production or even the whole production and repair cycle in one colony, distributing the products between all other colonies.

How does it work?

Conveyor Splitter is based on counting the amount of packets that go towards output rails and periodically preventing access to those rails based on defined raitos.

For example, let's imagine that there are two rails, and cargo has to be distibuted between them in the ratio X:Y. In other words, for each X packets of cargo coming to the first rail, the second rail should receive Y packets. This can be achieved by counting how many packets are coming to each rail, and shutting down the rail that reaches the target number of packets first until the other receives the rest of it's target amount, when resetting the count and unblocking that first rail.

For the purpose of counting, Conveyor Splitter utilizes combinations of Conveyor Element Sensors and Signal Counter Sensors. This imposes two restricions on the setup:

1. It may only work with one type of elements at time.
2. Possible ratios are restricted by the limited range of numbers accepted by settings of Counter Sensors. This may be avoided by replacing singular Counter Sensors with complex counter systems that allow to define multi-digit numbers. However, exploring this problem is out of scope of this post.

The setup

I decided to use 3-rail version as an example. The number of rails can be easily adjusted to conver any amount of rails is needed - the space is the only limitation.

Let's take a look at the conveyor part first.

Each output rail has a corresponding "branch" from the main line. Each branch has a priority-flow Conveyor Shutoff that connects it to the output and a bridge that leads back into an input conveyor rail.

This is how conveyor part looks like without shutoffs and bridges

The "branching" part is essential. Having a continious rail packets stream makes it hard to detect individual packets, which is essential to control their split ratio. It also makes it hard to prevent extra packets from going into the wrong output. Having branches solves this problem. When game detects branch with an input port, it periodically redirects single a packet towards it. This guaranties that each branch would always receive individual packets instead of streams and batches of consecutive packets. Bridges and feedback to the input rail are needed to prevent packets from stacking on Shutoff's input when it is locked by an automation signal.

Now, to the logic part.

As explained above, each branch has an Element Sensor, which is used to count packets with corresponding Counter sensor. In this setup, outputs of Element sensors are connected to Ribbon Writters, with each Writter set use a separate bit. Each Counter Sensor has it's input is connected to Ribbon Reader, that reads a bit that is used by corresponding Element Sensor. Ribbon wires are not required. With 2-rail version it may be easily replaced with direct connections. However, with more rails ribbons save space and improve visibility of the setup.

Each Counter operates in a simple mode. When the number of packets detected by corresponding Element Sensor reaches matches the set ratio, Counter sensor should block the Shutoff. When all shutoffs are blocked, all Counters should reset and unblock shutoffs. Therefore, each Counter Sensor's output should be passed through NOT gate and connected to two separated destinations: the inputs of corresponding shutoffs and Reset Subcurcuit. Connections to shutoffs are implemented in the same way as connections from Element Sensors - each Counter is connected to the Ribbon Writter that uses it's unique bit, and corresponding Shutoff is receiving it's signal from Ribbon Reader that reads that bit. Again, the use of Ribbon wires is optional. However, in addition to saving space it allows easy separation of Reset Subcurcuit from input signals.

The Reset Subcurcuit is used to reset Counters, which automatically unblocks shutoffs. The reset signal shouldn't be produced unless all Counters produce red signal. Easy way to achieve this is to direct negated outputs of Counters into single wire, connect it to NOT gate, and connect the output of the gate to reset ports of Counters. That way, if any single Counter still allows packets through shutoff, their collective output would be green, and reset signal would be red.
The moment the last Counter blocks it's Shutoff, the reset wire turns green and all Counters unblock Shutoffs, turning it red again.

That's it! I hope this post was interesting and userful.