HOW to set up OR timetable

[forevergone]

Hi everyone,

I have been playing around with my model for a while now in OR (originally had the activity set up in MSTS), and I came across the timetable mode in OR.

My goal is to set up AI trains around the player activity, however there are a lot of AI trains to set up my entire day.

I found the manual for the OR timetables, however when the timetable starts, the train does not run by itself as an AI but rather require the user to drive it.

I need some advice on how to set up the OR timetable for some train sets.

This is what my timetable_or file looks like at the moment with just one train, however I would like to include more trains on this list, specifically the AI. The timetable below starts, but does not drive by itself on that path.

,#comment,T150
#comment,TEST,
#path,,T150.pat
#consist,,MPI-L12.con
#start,,7:02

Can I add more trains to it ? perhaps some timetable times as well ? I was thinking something like the code below for the timetable.

,#comment,T150
#comment,TEST,
#path,,T150.pat
#consist,,MPI-L12.con
#start,,7:02
,#comment,T152
#comment,TEST,
#path,,T152.pat
#consist,,MPI-L12.con
#start,,7:05

Any help with this task would be greatly appreciated.

[Vince]

There is a writeup in the Manual.PDF found in the **\Documentation folder. (**= your OR installed path)

Timetable Mode starts in Chapter 11 on page 124 but the meat you want can be found on page 127.

enjoy!

[baldwin]

Timetable mode is not the same as an activity. In timetable mode, any train can be used by the player, so if you set up a 24 hour timetable, you can jump in on any train at any time in the 24 hours.

[forevergone]

Many thanks for the helps guys, I will be working on this over the weekend to set up my timetable. Just a few more questions...

Timetable mode is not the same as an activity. In timetable mode, any train can be used by the player, so if you set up a 24 hour timetable, you can jump in on any train at any time in the 24 hours.

Would jumping be done through Alt + 9 in OR ? I have not had any luck setting up more than one train in OR timetable mode so I was the only train in the simulation. I will have to use the suggestion in setting it up and then try it out.

Say I have 10 trains, and I jump to train 1, would the other 9 run as AI trains following the timetable setup in the timetable file ? That is what I am after.

Not sure if the timetable can set up times for each trip for each station perhaps ? or just a #start time i guess for the entire service.

There is a writeup in the Manual.PDF found in the **\Documentation folder. (**= your OR installed path)

Timetable Mode starts in Chapter 11 on page 124 but the meat you want can be found on page 127.

enjoy!

Thank you Vince, I will read more into it and post progress.

[forevergone]

There is a writeup in the Manual.PDF found in the **\Documentation folder. (**= your OR installed path)

Timetable Mode starts in Chapter 11 on page 124 but the meat you want can be found on page 127.

enjoy!

I can not find a manual.pdf in my install or documentations folder. Perhaps there must be a different link ?

This the guide I have been following:

http://www.openrails.coalstonewcastle.com.au/doku.php?id=wiki:building_content:timetable:table_of_contents

[baldwin]

The ability to change trains midstream is not yet available. All you do in timetable mode is select which train you want as the player and all the rest run as AI. If you go to http://openrails.org/download/program/ and download the Supporters version this includes an fairly up to date manual which includes a section on programming timetable mode.

[roeter]

Say I have 10 trains, and I jump to train 1, would the other 9 run as AI trains following the timetable setup in the timetable file ? That is what I am after.

On start in the menu, you select the train you want to run as player. All other trains will run as AI - even those that have started and terminated before the player train starts, will be run (in pre-run mode), as this may affect what happens later.

A timetable run always starts with the first train that moves, regardless of the start time of the player train. Up to the start of the player train, the trains are run in 'pre-run' mode, which is a speeded-up run, so to speak, without graphics, but with everything (trains, signals, station stops etc.) working as usual, but at a much lower interval-rate. Because of this pre-run process, the time it takes to start a timetable run will vary, and the later the start-time of the player train, the longer the start-up will take. On very intensive timetables on large routes it can take several minutes.

Not sure if the timetable can set up times for each trip for each station perhaps ? or just a #start time i guess for the entire service.

Each train has its own start-time, and each train can detail as many station stops as required (except that you cannot have two stops at one station for a single train).
As mentioned above, the start-time of the pre-run process is always the start-time of the earliest train.
The start of the graphics - comparible to the start of an activity - is the start-time of the selected player train.
But note : if the player train is 'formed' out of another train (for instance, it is the return working of another train as detailed in the timetable), and that other train is running late, the start of the player train is delayed until that first train has arrived.
Clearly that makes sense : you cannot run a return train if the incoming train has not yet arrived.

Regards,
Rob Roeterdink

[eric]

Each train has its own start-time, and each train can detail as many station stops as required (except that you cannot have two stops at one station for a single train).

This is where I think there may be a subtle naming convention issue. The timetable stop is based on a platform name, not the station name, correct?

If you use define unique names for each platform, you should be able to have two stops at one station. In my first attempt on testing, I defined unique platform names based on the track they were serving.

I'd have to fall things back to test this, but in theory, if I build a path that leaves Chicago-T1 out to Harvard-T1, leaves thru a switch and reverse point, returning to Harvard-T2 and Chicago-T9, technically, I've had the train stop twice at both Harvard and Chicago.

[roeter]

This is where I think there may be a subtle naming convention issue. The timetable stop is based on a platform name, not the station name, correct?

No - the timetable stop is based on the station name. This needs to be that way, otherwise the 'connect' command would not be possible - if the platform name was used, there would be no common ident, so trains in different platforms would not 'know' they are in the same station.

For complex stations, it may be required to have different station names for different platforms or part of platforms. This is particularly the case in stations with long platforms which is split by a cross-over, at such stations the two platform 'halves' can be used separately for short trains, but long trains use the full platform. To make sure trains stop in the right part of the platform, two different stations are required.

Regards,
Rob Roeterdink

[eric]

Ah, hadn't considered that. I don't use the connect function, so it hadn't come up in my testing.

[forevergone]

No - the timetable stop is based on the station name. This needs to be that way, otherwise the 'connect' command would not be possible - if the platform name was used, there would be no common ident, so trains in different platforms would not 'know' they are in the same station.

For complex stations, it may be required to have different station names for different platforms or part of platforms. This is particularly the case in stations with long platforms which is split by a cross-over, at such stations the two platform 'halves' can be used separately for short trains, but long trains use the full platform. To make sure trains stop in the right part of the platform, two different stations are required.

Regards,
Rob Roeterdink

That makes sense, I spent a lot of this weekend setting up my testing timetable and I am going through more manuals now just to figure out the extra coding that allows commands with respect to signals, and #dispose line commands. The #dispose line has added a lot of realism to my simulation.

Couldn't have done any of this without Eric's (eric) prompt help and example.

[scottb613]

Hi Folks,

Been following along on this topic with interest - both here and at Elvas... All the discussion I've seen seems to focus on passenger train operations - is there any reason this won't work for freight operations as well ? Obviously - you wouldn't be stopping at stations...

[forevergone]

Hi Folks,

Been following along on this topic with interest - both here and at Elvas... All the discussion I've seen seems to focus on passenger train operations - is there any reason this won't work for freight operations as well ? Obviously - you wouldn't be stopping at stations...

I am running equipment (deadhead) moves for passenger trains which would be similar to freight, just give it specific stop times that are specific to your start and end destinations only and it should be fine.

The document in the OR documentations folder name "manual.pdf" is a true eye opener with examples of how to make timetables and the definitions. I am still learning the possibilities now. It is pretty awesome indeed.

My next step / question for the forum would be with regards to a siding, can a train be given a siding time ? Sidings dont have a station name so when times are inputted I wonder if it will read the station/siding correctly.

Many thanks again for the progress, and I hope this search comes easily to help others like myself with this topic.

[eric]

Hi Folks,

Been following along on this topic with interest - both here and at Elvas... All the discussion I've seen seems to focus on passenger train operations - is there any reason this won't work for freight operations as well ? Obviously - you wouldn't be stopping at stations...

That's one of my next attempts... I'm assuming if a yard track gets a platform name, it will behave.

I'd love to see siding names get treated the same as a station or a platform. In the TIT/TDB, there isn't much of a difference -- the only additional fields for a platform are Station(), PlatformMinWaitingTime(), and PlatformNumPassengersWaiting().

It should only be a matter of a case statement, e.g. if the station name is not present (which it isn't in a platform) then set the value used for calculations to the siding name.

[roeter]

The problem with sidings is that siding names apply to one track only, unlike station names which apply to all platforms. MSTS does not require siding names to be unique, and many routes have names like just "siding", or "siding 1", "siding 2" etc. all over the place.
It is very likely, therefor, to run into multiple occurances of the same name within a path. Clearly, that would create problems.
Another problem for freight trains, particular for North American routes, is that yards are often unsignalled. If a train comes of a signalled route into an unsignalled yard, it will always clear a path through to the next signal - which means in that situation a path will be set right through the yard to the exit or even back onto the main line. This path would be locked all the time the train would stand in the yard. One possible way to overcome this problem is to terminate a freight train in the yard and form it into a new train starting at that position.
But apart from these limitations there is no reason why freight trains could not be included in a timetable.
There are many freight-only (or almost freight-only) routes where the present activities have no intermediate timings for freight trains, and a timetable for such a route would simply set start-times only, and have no intermediate stops at all. Combined with the 'passing path' logic, the system itself will work out where trains will be held to meet.
And if you know your way around the route-editor, you could set up 'dummy platforms' anywhere on the route just for timing or control purposes.

Regards,
Rob Roeterdink