Log In
Register Now!
Help
The timetable concept is an alternative way to define when and where trains are running. It is intended as an alternative for activity definitions, not as a replacement to it.
So what is it and how did it come about?
Well, to start with the latter - the idea was born out of sheer frustration from using the MSTS Activity Editor - and in particular the traffic definition.
I like to run routes with heavy AI traffic, for instance the London & South Eastern route, or East Coast Mainline and such, with their busy passenger services. And I like to set up traffic according to real timetables. Not activities with AI trains starting a few miles ahead of you and disappearing again after they passed - but all trains running along the full route as timetabled.
Building such traffic in the MSTS AE is, however, little short of a nightmare - in particular for trains with many intermediate stops.
So, the idea was really quite straightforward : if running according to a timetable is what is required, then why not use an actual timetable to define this?
And that's how it works.
A timetable can be created using a spreadsheet - with the columns as trains, and the rows as stations. The spreadsheet is saved as *.csv file, and that file is processed by OR. Trains use paths and consists just as in an activity. Start times of the trains, and intermediate stops etc., are all defined in the spreadsheet.
No distinction is made between AI train and player train - any train in the timetable can be selected as the player train.
So, defining a timetable for a route actually means creating a whole set of activities - depending on the route and density of traffic, the total number of equivalent activities can range from about 10 to 100's.
But that's not all. The timetable allows interaction between trains which can not be made in an activity. For instance, trains can be set to wait for another train at a certain location, or to follow another train (and keep behind it).
Furthermore, AI trains do no longer just 'fall out of the air' when they start, and vaporize when thy reach the end of the route. If an AI train is to terminate at a station in the route, it can be defined to form a new working - e.g. a return service.
It can form that service in the platform, or it can be detailed to shunt out to a siding, and shunt back into the station again in time to start the new service. Loco-hauled trains can be ordered to have the engine run round the train in order to run in the opposite direction.
Full details of all options and commands - admittedly not all of them implemented yet - can be found in the attached document.
Obviously, some routes are more suited for use of timetables as others. Clearly, routes with dense passenger traffic are prime candidates for such use.
But it does also depend on the way the route was build, and in particular on the signalling. For instance, on a route with many single track sections and signals which clear too far ahead and too early, keeping trains running to a timetable is very difficult. Also, some routes rely on "Obtaining Permission" for access to yards and sidings, making this areas inaccesible to AI trains, which also limits the options, e.g. for stabling units in sidings between duties etc.
Creating a proper timetable - and keeping all trains running throughout the day - is not easy. It is, actually, a lot more difficult then creating an activity. There are various reasons for this. First of all, in a timetable, AI trains run in both directions. That is rarely done in an activity. Furthermore, depending on the start-time of the selected player train, it could be that AI trains have been running for hours before the actual player train starts. If anything in the timetable is wrong, trains may get stuck - and by the time the player train is to start everything is blocked. This is made worse as trains form into return workings - if the incoming service is somehow stuck, the formed train will never run. All this needs to be sorted out bit by bit, hour by hour, and commands added, paths or timings changed etc. to keep things moving. But remember - when completed, it's not just one activity which can be run - but lots of them, probably enough to run different trains for months if not years to come.
OK - back to what's been introduced now : it still is a preliminary version, and it still is very much a work in progress.
Attached is a document describing the timetable concept and defining file contents and commands etc.
Also attached is a working example - it is for route Surfliner2. It totals 470 trains, but 204 of those are the tram shuttle services at San Diego - that's just eye candy. A further 162 trains are just short 'stumps' of services on lines not included fully in this route, and also empty stock workings to and from yards and sidings.
But that still leaves 104 trains which can be properly run as player trains - these are all Surfliner trains, the San Diego Coaster services, AMTRAK's Coast Starlight between LA and San Luis Obispo, and the Metrolink trains on the Ventura Valley and Orange County lines.
The services vary from the short Burbank Airport shuttles (just 25 mins.) to the Surfliners running the full length of the route between San Diego and San Luis Obispo (eight and a half hours). The timetable does not contain any freight trains yet.
And remember - whatever train you select as player train, all AI traffic which you could meet is included automatically.
And once started, all sets used in services which are contained within the route will remain visible until the end of the day - stabled in a siding or platform in between duties, or at the end of the services. It's quite impressive to pass the Metro Yard just north of LA around midday - about 20 Metrolink units are stored there in between morning and evening services.
Well, I just hope you like the idea.
Regards,
Rob Roeterdink
Timetable document :
TimetableConcept.pdf (146.92K)
Number of downloads: 1653
Timetable example :
OR_SurflinerTimetable.zip (108.46K)
Number of downloads: 1480
