Three trains are at a station in automatic mode, each trying to navigate to another station, but that station currently has limit 0. On tick t_0 the station goes to limit 2. How do the three trains prioritize which two select the new station? How often do the trains poll for station availability, and does the train allocation all start on the same tick? By which tick will the C signal on the target station read 2?
Similarly: a train is at station A (and therefore the C_a signal is 1) and departs for station B. At some point C_b will go to 1 (as the station reads inbound train count). For how many ticks is C_a + C_b not 1? Is there a gap when C_a is zero (assuming we're also reading the parked train count) because the train is "leaving" but C_b hasn't become 1 yet? If I am transmitting C_b on the radar circuit, there'll be at least two ticks in my current design (combinator delay) but are those few ticks enough time for another train waiting for station A to get allocated to it? Will that always happen, or only if that (say) three tick window coincides with the (per the wiki) every-5 seconds polling of the engine?
I'm trying to set up some global demand / satisfaction mapping that puts supply stations in limit 0 mode when there is no global demand. When there is global demand, the stations turn on, ideally with a limit equal to min(global demand, possible station satisfaction) (so if there's demand for 2 trains worth of ore, we send 2 trains to that station). The problem here is that if I set a limit on the number of inbound trains, when the train arrives at the supply station and fills up, it will then depart for the drop station. While it is inbound to the drop station, the train is not counting towards global satisfaction or to local, inbound-to-that-station count (C by default).
What I want to avoid is a stuck train situation, where the first two trains arrive at the supply station and depart to the drop station, and then a third train arrives at supply and gets filled up. At that point it has nowhere to go (the drop station is satisfied and will not accept more trains), so it goes back to the parking lot and waits for a drop station to open up. At some point, all the cargo trains end up in this state in the degenerate case.
I have a couple of solutions to this (frustratingly one of them would be time-sharing on the radar network, but i don't want to put memory cells at each station ... yet), but a lot of them involve delays.
- When there's a global demand change (and supply stations would activate), delay a little while so that any stuck trains with supply on them route to the demand station instead, so we can unstick the system. This seems to work naturally, even with the very small number of ticks of delay already inbuilt between demand going onto the radar circuit and the supply stations activating.
- When a supply station calculates its inbound train count, don't reduce the station limit for a little while so that the second or third inbound train will be correctly routed to that supply station.
So that's what I'm sort of thinking about- I'd like to not recalculate demand / supply levels until I'm pretty sure that all the trains have had a chance to poll. This presupposes an excess of cargo trains- that there's always more trains than active demand, but trains are cheap, and parking lot train stations are plentiful. I guess an even better calculation would be stable - the supply station limits would only change once the supply trains depart.
All of this has gotten me thinking that maybe I need additional circuit network colors to tell the supply stations how many trains are inbound to the drop stations (radar at least would be helpful with blue / purple wires just for segmentation, or like i said, timesharing on the radar) or just run physical wires on my power bus alongside the radar network, but that's fiddly.
I *think* if I can understand the tick timing I can probably work around that.
