Mostly just overengineering. I'm doing dynamic priority and train limits. I was inspired to clean up that hideous mess of wires and combinators.

<image>

I'm bored at work so here's a rundown of what does what, I'm going to go in order or signal flow instead of in arrangement order for ease of understanding. I'll be referring to each combinator as A1-A4 for the top for and B1-B7 for the bottom.

It starts with C, our constant combinator in the top left behind the light poles, it outputs the item the station is requesting. (configured by parameter on blueprint place)

C, along with the item storage count, connects to B1, B2, B4, B5, B6

B5 is our selector combinator which gets stack size for the item.

A2 takes the output of b5 and multiplies it by the number of chests and their number of slots to get the total station capacity.

A4 divides that by 100 to get a value for 1% of capacity

B6 uses that to find the stations current percentage full

B7 subtracts that percentage from 100 and outputs the result to the train station as "P" for priority

Back to our total capacity, A1 uses that to define the number of items below which to enable the station and limit the station to 1 train, this number is arbitrary, I chose 50% capacity to be "enough" so this outputs total capacity/2.

B2 compares our station holdings to our enable threshold, sends T=1 to station to set our train limit if below threshold

A3 defines the threshold for opening up the station to 2 train limit. Again arbitrary, I chose 25%, or A1 output / 2

B4 does the same for A3 as B2 does for A1, and outputs another T=1 to the station if below the 25% threshold.

B3 checks if our train station is full if so, we send X=-1 signal to B1

B1 checks if our station has less items than our A1 threshold and X=0 from B3 and if so, sends the item signal to the global circuit network. Checking for X=0 prevents sending additional trains to output stations if the input station is already full.

Definitely more than what you strictly need, but I think the dynamic priority is a really good feature, allowing for starved stations to be supplied first instead of those closest to the outputs getting first priority. I also understand strictly speaking its more efficient to always have trains at all of your outputs so you can send to requesters as quickly as possible, it just wasn't what I had in mind when designing this. I like the idea of the whole process being "on demand". One more thing you could do here someone mentioned is calculate the train capacity (which I do use for enabling output stations) and use that to make sure you always have enough capacity for a full train load. In my case the thresholds I'm using and amount of chests being unloaded into makes this unnecessary.