[Lutz_s]

I only wanted to show what is possible with an Excel macro. So it's fine if it is of any use.

I also tried to find out if a path runs through a station (platformitem), so there could be a dropdown list only containing stations on this path, but this seems to be beyond my knowledge. Anyway, dropdown lists for consists and for paths could be made, so it would be easier to choose them.

Lutz

[nicober]

HI Rob!

Quote

The major problem I encountered is the accentueted characters of french languge use in many route. At this Sation name with these king of characters the trains don't wont to stop at these stations.

Quote

See A Tejesember's post : http://www.elvastowe...ost__p__152550.
He had problems with Hungarian characters but managed to save the .csv file in Unicode which sorted this problem.

How to save a CSV file in Unicode in Excel?
I use Excel 2003 and I have 3 possibilities to create a CSV file:
- CSV (Comma delimited ) (*.csv) - I use this Oprtion and OR Timetable can read it.
- CSV (Macintosh) (*.csv)
- CSV (MS_DOS) (*.csv)
When I use the first option Excel save my file as CSV without any thing else to do. No option to save as Unicode like my text editor.

If I open my CSV file newly created, I can see the accented characters in the text with commas.

My observations about this:

On acivity on a french route Brest-Rennes, I made a path with 4 stations to stop and one of this station have an e accented, Plounérin. My 2 AI trains stop at the 3 other stations, but don't want to stop at this station. Why?

A simple test:
If I remove the e accented and replace it by a simple e, at all Station and PlatformName in the TDB, my two trains stop correctly at this station. In the timetable file I made also this little change for the e of Plounerin.

:birthday:

[Lutz_s]

Hi Nico,

it seems Excel can't save to unicode, but you could try a trick. Open the saved file with the windows editor and choose "save as". Here you choose unicode as coding. I don't know if it works here, but that's the way we have to do it at work, when importing csv-files from Excel

Lutz

[nicober]

Hi Lutz

I made a test like you have suggested and now it's work fine.

If I open The CSV file with my text editor, the Encoding type of the file is in Plain Text. I need to check Unicode and save my CSV file. With this manipulation, everything works in the timetable and my 2 trains now stop at this station with accented characters.
Thanks for your help.

In resume with many special characters we need to:
1- Save the project in Excel format XLS
2- Save this file in CSV format
3- Open this file in a text editor and save it as Unicode
4- Transfert this file in ACTIVITES/Openrails folder
5- Rename it with the extension .timetable_or

A lot of manipulations but it's work now. :birthday:

[A Tejesember]

I suggest using Notepad++ after exporting from Excel. Just hit Encoding -> Convert to UTF-8 and save. Works for me.

[Gary54]

Rob,

I have finally started work on a timetable for the NEC4 route. At this point, I am working on only the southbound Amtrak traffic out of Philadelphia. Over time, I will bring in the northbound traffic and eventually the SEPTA runs from Philadelphia south to Newark, Delaware, and back. All times are taken from the most recent Amtrak schedules.

I am to the point where OR recognizes the timetable file and includes a list of trains that I have documented (I have yet to add consists and paths). I have a few questions. First, given that all of the southbound trains start from Philadelphia, do I have to include a departure time for the Philadelphia station, or does the provided start time correspond with the path start point, which in this case would be a track in the Philadelphia station? In this case, it would seem that no entry would be required for the Philadelphia station.

It seems that generating paths for this route should be relatively straightforward. However, I would assume that one must explicitly place the end point of a particular train on a specific track within the station (the end points, Philadelphia and Union Station, Washington, DC, contain multiple tracks). Also, it could get tricky when one begins to produce traffic running in the opposite direction. Again, opposing traffic on the mainline shouldn't be too much of a problem given that it is a four-track main, but entering station limits could require a careful selection of paths. My thinking is to bring trains into Washington, DC, on the west side of the station and outbound traffic on the east side.

Regarding the #dispose row; my thinking at this early stage is to just have each train disappear at the end of its run (this may change in the future). Is there a specific command for this or we simply not enter anything in this row?

Many thanks for bringing this option to OR. I hope you don't mind if I ask questions as I work through this.

Gary

[roeter]

The usual morning round-up of questions :

Quote

I haven't tried to place a static consist yet, I presume it currently requires a short path to introduce a static consist, does this work with consists that have no motive power? A rake of freight cars for example. Also, would the consist move to the end of the path before becoming static or would it become static immediately?

If the train has power, it will run to the end of the path.
If there is no power, the train is placed at the beginning of the path, with the end of the train at the start-position of the path.
Admittedly, I have not tested that yet - so the above is the theory - let's wait and see what it will do in reality :) .

Quote

First, given that all of the southbound trains start from Philadelphia, do I have to include a departure time for the Philadelphia station, or does the provided start time correspond with the path start point, which in this case would be a track in the Philadelphia station? In this case, it would seem that no entry would be required for the Philadelphia station.

The start time is the time the train will 'appear' (for AI trains), or when the 'activity' will start (for player train). To make sure the train runs to the timetable you will still need a departure time. Generally, I set the start-time 2 mins. before departure time, which is enough time for the player to get the train ready to depart without sitting there wasting your time.

Quote

Regarding the #dispose row; my thinking at this early stage is to just have each train disappear at the end of its run (this may change in the future). Is there a specific command for this or we simply not enter anything in this row?

You can either not define a #dispose row at all, or just leave it empty. There is no specific command.

As for linking in and outbound trains : it can be very complex but does make it all a lot more interesting.
If the station is very busy, you will need to make a platform allocation diagram to sort things out properly.
For the NEC, you have two options :

• Use all platforms for both arrival and departure, and keep trains in platform between arriving and departing.
  
• Use one side of station for arrivals and other side for departures, and use 'stable' command to move trains from one side to the other side at 'quiet' times.

If trains spend a very long time at the station (e.g. between rush-hours) you probably would need the 'stable' command to get them out of the way anyway.
If you have trains which require loco run-round you can also use the 'stable' command to perform the run-round, or use the 'trigger' command to change the train into the reverse set.

Quote

I hope you don't mind if I ask questions as I work through this.

Not at all - it might help others to find out how things work.

Regards,
Rob Roeterdink

[Csantucci]

Rob,
also here people are beginning to prepare timetable-based activity sets.
One person asked me to forward you a - I hope - small request.
In some cases OR does not display the station names when it loads the .csv file. The content developer noticed that this happens because in some routes there are station names referenced as follows in the .tdb and .tit file (example): Station ( "Bologna Centrale " ) . The space after Centrale is the problem. Only solution as of now is to eliminate such spaces within the .tdb file, which is not something that can be required to anyone.
So the request is to load station names also in this case.

I hope you can accomodate for that.

[Gary54]

Rob,

Thanks very much for your responses to my recent questions. I now have the entire Amtrak southbound (Philadelphia to Washington, DC) schedule into the timetable. I have several more questions about handling trains that have arrived at Washington. Assuming that I enter nothing under a particular train in the #dispose row, will that train simply disappear upon reaching the end of its route?

If I want that train, let’s refer to it as NER 123 (Northeast Regional train 123), to sit at its platform for a short time, would I enter $static? However, it would seem that this command would hold the train until it would depart at some stipulated time but this time running in reverse (?).

You had mentioned the use of the $stable command. Suppose I wanted to use NER 123 for a return run to Philadelphia, but this time as NER 321 (with the engine running at the front of the train rather than push-pull mode). And let’s stipulate that NER 123 arrived in Washington at 09:00 on platform 5 and will depart Washington as NER 321 for Philadelphia at 11:00 from platform 11. It seems that $triggers=NER 321 (or is it $forms=NER 321 ?) entered in the #dispose row under NER 123 might be one way to do this. As I read it, the syntax $stable/$triggers=NER 321 entered in the $dispose row for NER 123 may be part of this. However, the examples in the text that you generated seem more involved than my example. For example, does one have to make a path that takes train NER 123 from platform 5 to platform 11 where is becomes NER 321? Further, given that train NER 123 is essentially reversing its orientation for the trip to Philadelphia, is there a specific command for that? Also, the timing must be addressed. The incoming NER 123 (09:00) will go out at 11:00.

I suppose another (simple?) solution would be to terminate (make disappear) NER 123 when it arrives at Washington at 9:00 on platform 5 and have train NER 321 start on platform 11 a few minutes before 11:00.

Again, many thanks for your help. I am making progress.

Gary

[roeter]

A lot of questions here, so it's going to be a long answer.

Keep train in platform for certain time.
If you use $static, the train will stay in the platform 'forever'.
To keep the train in the platform for a certain time only, you must set an arrival and departure time for that train.
For instance, if the train arrives at 10:00 and you want it to stay in the platform until 10:20, define time for that stop as : 10:00-10:20, even though it is the final stop. In this case, leave the #dispose row empty.

Move to other platform - no change in consist.
This can be used for trains which can reverse without change of consist, e.g. multiple units or push-pull sets.
First of all, define both trains (in your example, NER123 and NER321) as normal. If you do nothing else, clearly both trains would run independently.
If you want to use the stock of the incoming train for the outgoing train but leave from a different platform, you must indeed use the $stable command.

The process of the $stable command runs through the following steps :

• The train arrives, and forms the 'outward' leg of the stable run. There is no change in consist.
  The name of the train for the outward leg is set to SO_xxxx, in which xxxx is the internal number of the incoming train (as shown in F5 Dispatcher HUD).
  
• The train moves out of the platform to the stable position : the outward leg.
  The outward leg is defined by the path to the stable position, and the time the outward move is to take place.
  Command parameters :
  
  • /out_time = HH:mm : the time the outward move must take place.
    This is optional; if not set, the outward move will take place as soon as the station stop of the incoming train has ended.
    
  • /out_path = path : the path from the arrival platform to the stable position.
    This is just a 'normal' MSTS path which must be defined separately.
  
  
• The train is at the stable position and forms the 'inward' leg of the stable run. Again, there is no change in the consist.
  The name of the train for the inward leg is set to SI_xxxx, in which xxxx is the internal number of the outgoing train.
  
• The train moves back into the station into the departure platform : the inward leg.
  The inward leg is defined by the path from the stable position back to the departure platform, and the time the inward move is to take place.
  Command parameters :
  
  • /in_time = HH:mm : the time the inward move must take place.
    This is optional; if not set, the inward move will take place immediately following the outward move.
    
  • /in_path = path : the path from the stable position to the departure platform.
    This is just a 'normal' MSTS path which must be defined separately.
  
  
• The train arrives at the departure platform, and forms the outgoing train.
  To define which train it is to form, set the /form = <name> command.
  Note that the consist as defined for the formed train is ignored - the consist of the incoming train is used without changes.

Move to other platform - requiring new consist.
The move is the same as above, except that the consist as defined for the outgoing train will replace the consist of the incoming train.
The definitions are also the same, except that in pt. 5 you must use /trigger=<name> instead of forms.
The change over of the consist will take place at the 'stable' position. Note that care is taken with regards to any required reversals, either within the 'inward' path or between the 'inward' path and the path of the outgoing train, and the direction of the consist as placed at the stable position is such that it will form the final outgoing train in the correct direction (I hope ... :( ).

Move to other platform - using existing consist but with engine run-round.
In this situation the train itself does not change, but the engine is run-round so the train can properly run in the reverse direction.
This would, for instance, be required at both Washington and Philadelphia for trains which have do not have driving cabs at both end (normal loco-hauled stock).
The run-round can take place at either of the three positions where the train is stopped : at the arriving location, the stable location or the departure location. In both Washington and Philadelphia, however, it is not possible to run round in the station itself so it would always have to be at the stable location.

Command parameters :

• /runround = <path> : the path for the engine to run round its train.
  If the engine itself has to reverse (e.g. Genesis engines), the path must obviously include a Y or triangle.
  
• /rrpos = <position> : the position where the runround is to occur : value is either out, stable or in.
  This parameter is compulsory.
  
• /rrtime = HH:mm : the time the runround is to start.
  If not set, the runround will take place as soon as the train is ready (i.e. it has completed the previous move).

Now, if you think all this is complicated, than prepare for a bit of a shock - for there is an alternative way to do all this.
The alternative is to explicitly include the empty stock movements in the timetable.

Which of the two ways is preferable depends on the situation.

These are the main differences between these two options :

• Using stable command :
  
  • Plus : no need to define moves explicitly.
    
  • Minus : moves can not be influenced, e.g. it is not possible to set $wait commands etc. for the stable moves.
  
  
• Using Empty Stock Movements :
  
  • Minus : moves must be defined explicitly.
    
  • Plus : moves can be influenced and can be regulated in relation to other trains, e.g. using $wait commands.

In general, explicit ECS movements should be used in complex situations where deadlock conflicts can occur and must be avoided using train control commands.

So, this is how explicit ECS movements work :

• Define the empty stock movements between arrival platform and stable position, as well as between stable position and departure platform, just like any other train.
  Names can be derived from incoming and outgoing train, e.g. using prefix EW_ (for Empty stock - Washington).
  
• Paths for these trains would be the same as used for /out_path and /in_path parameters for the stable move.
  
• Timings would also be the same as set in /out_time and /in_time. Note that all trains need a start-time.
  
• $forms=<name> must be used to make the arrival train form the outgoing ECS, and to make the incoming ECS form the outgoing train.
  
• At the stable position, to form the incoming ECS out of the outgoing ECS, use $forms=<name>, with /runround if required, or $trigger=<name>, as appropriate similar to use as for the stable command.
  Note that if you use $trigger, you must take care of any reversals between the stable position and the final direction of the train, so you might need to define a consist in reverse order to get the correct final train.

Finally, some general notes on linked trains.

Linked trains and delays or cancelations.

• If the incoming train is running late, the formed train will not be started until the incoming train has arrived.
  As a result, the start of a formed train can be delayed.
  
• If the incoming train gets stuck (e.g. deadlock situation), the formed train will not run at all.
  
• If a formed train is not run because the incoming train did not arrive, any further formed trains will not run either.
  
• If a train is removed (for going out-of-control, e.g. due to "SPAD"), any 'forms' links are removed as well and so any formed train will run as planned.

Linked trains and player train.
If the selected player train is formed out of another train, all the above for delays and cancelations also apply to the player train.
This means that :

• If the incoming train is late, the start of the player train and, with that, the start of the actual 'activity' may be delayed.
  
• If the player train can not be formed before midnight (24:00), the activity is abandoned.
  Note that the present report on this defines this as a bug but that is not correct - that needs to be altered in another message.
  
• At the end of the player train run, it is not yet possible for the player train to form into the next working, either again as player train or as AI train.
  That bit is still under development.

Consist used for player train.
Normally, if a train is linked to another train using 'formed', the existing consist is used.
For the player train, however, the consist as defined in the timetable will always be used regardless of the link to the preceding train.

Well, I said it would be a long post.
I will try and make examples for the various situations. But it's now well passed lunch-time and I'm getting hungry.

Regards,
Rob Roeterdink