I was just spending hours yesterday testing out different circuit configurations in attempt to solve the matter of dispatching only as many trains as necessary and making sure that no two trains go to the same location.
(For those not interested in my findings in how to do something that ultimately won't be necessary once train stop limits are included in the game, skip to the end.)
1 Request = 1 Dispatch
This requirement is simple, at least in the case of only having a single dispatcher. If the requesting station(s) can contact the dispatcher via circuit network, then then station can pulse a 1 of type requested resource for 1 tick. The dispatch station captures this tick, then, using some bitwise logic along with a primitive if-else-if statement, will dispatch a single train, assuming at least 1 is currently available.
The system is robust enough to handle situations in which two or more stations request a train on the same, as well as if one or more stations request a train when none are available. The input from the circuit network is captured and locally maintained until explicitly subtracted, which only occurs when a train is actually dispatched. Now that I think about it, a maintained value in that count could be wired to an alarm to signal when there are not enough trains to meet demand.
It's possible to have this work between multiple dispatch stations, but ultimately there MUST be no more than a single if-else-if statement to maintain the fact that 1 request results in 1 dispatch, meaning that the second dispatcher cannot even consider sending trains unless the first dispatcher has none, which prevents the potential benefits of dispatcher-requestor locality and pollutes the rail system's global circuit network channel.
Trains do not fight for destinations
As far as I can see, there was no good way to achieve this under current limitations. Even if you disable the requestor upon arrival of the dispatched train, if two requestors request a train around the same time, then one is likely to follow the other, and only head for the other station once the first train arrives at its destination.
I found
a thread with an interesting idea that, in short, mandated that each receiver of a particular resource had 1 additional "seeker station"
per train that could be dispatched to it. The dispatcher would then return the ID of the train dispatched, which the requestor would use to enable one of its seeker stations to ensure the train came to that specific location (assuming that all trains of a type have the seeker station in their schedule between dispatch and reception).
This was, as far I as could tell, the only real solution that worked, but it comes with 1 major problem: Your dispatcher and requestors become highly coupled, which defeats much of the purpose of the model in the first place.
The construction of a requestor station requires 1 additional seeker station per train that can be dispatched, along with all of the circuitry to faciliate enabling it. The addition of any trains to the dispatcher requires an update to all requestors of that particular resource. And, as train IDs are totally unique, if a train must be replaced for whatever reason, this also requires an update to all requestors of that particular resource.
On the topic of train stop limits
I very, very,
VERY much appreciate this change. Having the functionality built-in to stations will remove the dependency for massive inter-station circuit networks and bulky combinators (at least for this purpose, I don't personally use the circuit network for much, but I imagine many live and die by it). No longer will this limitation of the low-coupling, modular, request-and-dispatch train network keep me awake at night!
Oh, and the Tips GUI looks really neat, too. I don't have a whole lot to say on it other than it's clear that A LOT of time and thought was expended on shaking off its old limitations and increasing it relevance and helpfulness.