The following document is a blueprint by RTS in what we would find useful to include in any Run8 AI system that is currently under development. Feel free to edit this document, and I will post this on a forum and/or make sure this is passed along to the Run8 team for consideration.
Symbol Database Edit
A symbol database should be server defined and edited to include the following fields. Symbol ID that matches the tag and/or file located in the trains folder, referencing the route number. A spawn logic field to determine if the train is normally spawned or built. Train type so the AI system knows how to handle top speeds as well as any other criteria the AI needs. ETA of a typical time this train would arrive on territory in a 24 hour clock. Frequency as far as what days of the week this train would be generated. Lateness percentage and/or value at not only how often a train is late but how late a train can be (TD3 does this by percentage, but it may require 2 fields). Crew change, passenger, and other stop data so that the AI train stops for a minimum amount of time. The train could also hold until a particular time (passenger stop). Destination so dispatchers can note where the train is supposed to go
Network/ETA Tab Edit
The network tab is a feature that allows anyone to see where any given train is in Run8. ETA data for the next 24 hours can be shown or broadcast here so that clients know when to expect the arrival of the next spawn. To make things simple the ETA does not need to be updated through the course of the day. It can actually generate itself once every 24 hours at midnight. Any train that is delayed beyond 24 hours can carry over to the next day. Very similar to what a prototypical dispatcher line up sheet accomplishes. All services that are also in visible blocks would be shown here perhaps with last known location similar to ED. Those under AI control could have the username AI or AI and a number for example. If the AI system is calculating AI based on speed it could also give ETAs for the next control point (but that is just gravy).
Though I've heard trains are capable of spawning inside one another, my understanding is this is not supposed to normally happen. Spawning should only occur if a train has reached it's ETA for the day (with random variation). It needs to also match it's frequency so that trains not scheduled for that day are not spawned. As soon as the train spawns it should already be at it's normal speed (or in the process of slowing down for it's next crew change or signal). Ideally it would be nice to have trains NOT spawn if the dispatch has lined a route against the area of an oncoming train.
The queue is to be used for a build up of trains that have not had the opportunity to come onto a territory. In other words a train is already in the spawning block and it hasn't proceeded further on the territory. Perhaps this is due to no dispatcher on duty, or it can simply be backed up a bit and no further trains are cleared to enter. The queue would simply build up a line of trains waiting to come onto a territory. If there was a priority field the queue could possibly sort itself by priority first, then by actual ETA allowing priority trains to jump the line. The last would be gravy but would simulate what takes place outside the scope of the sim and make dispatching a bit easier to deal with the backlog when things free up.
Based on the database, trains can automatically stop at specified crew change and/or passenger stops not governed by signal indication. It could do a basic 5 minute stop or perhaps longer if necessary based again on schedule departure in the database. The point of relinquishing vs simply stopping is to allow a user to take control of the train and commence operations. All relinquished trains should also appear on the network/ETA tab
Stop And Switch Protection Edit
Goes without saying that all trains should stop at a red signal and not pass through a switch lined against it. I don't believe AI should be able to throw or clear any signals at this time. What this does is also allow the train to relinquish. It is a way for any dispatcher to make a train available for a crew change. It can also be used for a crew to take over an AI train and perform manual switching operations.
The AI system should be able to acquire any train that becomes a free agent. A value such as 5 minutes used in the example for crew changes can apply here as well. This will allow anyone who has a dropped carrier to reclaim their train once rebooting and/or logging back in. In order for an AI train to acquire it's tag must match what is shown in the database. It also must ensure a 5 minute or other specified time period has elapsed. Though a train can acquire on an approach, it must follow the stop and switch protection rules and relinquish accordingly at the first stop signal, or switch lined against it. In places such as Barstow perhaps it can also look for a green track signal in the yard tracks. That functionality can be added perhaps to West Colton at some point as well.
Speed & Other Gravy Edit
Though speed is very important as far as realistic operations, we are not as concerned about other gravy. What I mean by that is realistic physics though important for handling our own trains is not as important in others we see or pass. I suppose it would be nice to see it gradually slow down but not too concerned on what it's brake pressure is. Trains that honk at crossings, dim their lights, and call signals though appealing are just gravy and not necessary. Of course anything to add to the realism will make it better. From our standpoint though what is important is the movement of trains, and creation of traffic. The rest is gravy.
We hope the following document serves as a good step in what the RTS community is looking for. Like many of our documents it is editable and may change from time to time. We reserve the right to revert or reject certain changes. Feel free to comment or add your own ideas. We are looking forward to whatever the Run8 team brings us down the road.