15. OR-Specific Route Features¶
As a general rule and as already stated, Open Rails provides all route functionalities that were already available for MSTS, plus some opportunities such as also accepting textures in .dds format.
15.1. Modifications to .trk Files¶
Many of the features described in this chapter require additional parameters to be
added in the route’s .trk file. The additional parameters can be directly added at
the end (just above the last parenthesis) of
the route’s .trk file residing in the route’s root folder. Don’t add such parameters
in other positions of the file, because this would create problems if you want to use
the MSTS editors with the related route. However, to avoid
modifying the original file, the Include method described
here is also applicable to the .trk file, creating a
new .trk file inserted into an
OpenRails folder in the root folder of the route.
As an example, in case of the parameter needed to avoid forest trees on tracks ( see
here), this additional .trk file will contain:
include ( ../Surfliner2.trk ) ORTSUserPreferenceForestClearDistance ( 2 )
Only OR will look in the
For a full list of parameters, see Developing OR Content - Parameters and Tokens
15.2. Repetition of Snow Terrain Textures¶
OR provides a simple way to add snow terrain textures: the following default
snow texture names are recognized:
ORTSDefaultDMSnow.ace, to be positioned within folder
the concerned route. For the snow textures that are missing in the
subfolder, and only for them, ORTS uses such files to display snow, if they
are present, instead of using file
To have a minimum working snow texture set, the file
also be present in the
15.3. Snow Textures with Night Textures¶
MSTS did not allow snow textures to be used with night textures.
This meant having dark buildings when running an activity at night
when the weather is set to snow. It turns out that OR is able to run
with snow textures and night textures. To do this, you have to create
Night\ folder in the
Textures\Snow\ directory and copy the needed textures
Night\ folder. Doing this will allow night textures to be visible when operating
in snow at night. Keep in mind that the current night textures such as buildings do not
include snow so new textures will have to be created.
One warning, if you decide to do this, there is a possiblility of experiencing resource issues.
15.4. Operating Turntables and Transfertables¶
A cool feature available in OR is the one of operating turntables and transfertables. In MSTS they are static, and can’t rotate and transfer trainsets. Turntables and transfertables are managed in a similar way by OR, and share also a significant portion of code. Therefore here reference to turntables will be made, and then only the differences for transfertables will be described.
Turntables and transfertables can’t be directly connected to a leading switch. A track section of at least 1 meter must be laid in between.
The best way to get a turntable to be operational is to refer to an example.
So here are the instructions and the files to test this function, both for route
Catania-Messina (SICILIA 1) and for other routes using
Route Catania-Messina can be downloaded from
A .ws file within the World subdirectory must be replaced with file
available in the Open Rails pack in the
(this has nothing to do with turntables, it’s a file that contains incoherent data that
can cause a crash).
Pls. note that also the other sample files cited in this paragraph are available in such subfolder.
Two test paths, included in file
Turntable_PATHS.zip, one for each turntable in the route, which can be used either
in explore mode or within activities are available in the Open Rails pack.
Within the route’s folder an OpenRails subfolder must be created, that must contain
2 files. The first one is following file
turntables.dat, which contains the data needed
to OR to locate and specify the turntable.
2 Turntable( WFile ( "w-005625+014198.w" ) UiD ( 1280 ) XOffset ( 0 ) ZOffset ( 13.4 ) TrackShapeIndex ( 253 ) Animation ( "TRACKPIECE" ) Diameter ( 27 ) ) Turntable( WFile ( "w-005631+014158.w" ) UiD ( 638 ) XOffset ( 0 ) ZOffset ( 13.4 ) TrackShapeIndex ( 253 ) Animation ( "TRACKPIECE" ) Diameter ( 27 ) )
To generate this file for other routes following has to be taken into account:
- the first line must be blank
- the number in the second line (2 in the above file) is the number of operating turntables within the route
- WFile is the name of the .w file where the turntable is present
- The number in the UiD line is the UiD number of the TrackObj () block within the .w file related to the turntable
- XOffset, YOffset and ZOffset are the offsets of the center of rotation of the turntable with respect to the zero of the turntable shape
- TrackShapeIndex is the index of the TrackShape () block within tsection.dat that refers to the turntable; please note that if a new TrackShape () block for the turntable is needed, it is not necessary to modify tsection.dat; it is possible to proceed as described here
- The Animation parameter is the name of the Matrix of the rotating part within the .s file
- the Diameter value is the diameter of the turntable in meters.
The above file refers to turntables using the a1t27mturntable.s shape.
The second file to be inserted within the route’s Openrails subfolder is a small
integration .trk file that indicates the name of the .sms sound file to be associated to the turntable. For
the route SICILIA 1 such file is therefore named
SICILIA 1.trk, like its parent file.
Here is the file content.
include ( "../Sicilia 1.trk" ) ORTSDefaultTurntableSMS ( turntable.sms )
The first line must be empty.
a1t27mturntable.s must be modified to add the animation data, as MSTS has provided
it as a static file. To do this, uncompress it with Route Riter or Shapefilemanager and insert just above
the last parenthesis the contents of file
If other .s files have to be used for turntables, or new ones have to be developed, it must be considered that
the rotation animation should be as follows:
animation ( 3599 30 anim_nodes ( .. .. .. .. anim_node TRACKPIECE ( controllers ( .. tcb_rot ( 5 tcb_key ( 0 0 0 0 1 0 0 0 0 0 ) tcb_key ( 900 0 0.7071068 0 0.7071067 0 0 0 0 0 ) tcb_key ( 1800 0 1 0 0.0 0 0 0 0 0 ) tcb_key ( 2700 0 -0.7071068 0 0.7071067 0 0 0 0 0 ) tcb_key ( 3600 0 0 0 -1 0 0 0 0 0 ) )
or as follows:
animation ( 3599 30 anim_nodes ( .. .. .. .. anim_node WHEEL1 ( controllers ( 1 tcb_rot ( 5 slerp_rot ( 0 0 0 0 1 ) slerp_rot ( 900 0 0.7071068 0 0.7071067 ) slerp_rot ( 1800 0 1 0 -1.629207E-07 ) slerp_rot ( 2700 0 -0.7071066 0 0.7071069 ) slerp_rot ( 3600 0 0 0 1 ) ) ) )
The above names of the anim_nodes are of course free choice. The animation rotation direction as defined above must be counterclockwise.
Within the base Sound folder (not the one of the route) the .sms file
turntablesSOUND.zip has to be added to provide sound when the turntable rotates. It uses the two default
MSTS .wav files for the sound. They have a bit a low volume. It is open to everyone to improve such files.
Discrete trigger 1 is triggered when the turntable starts turning empty, discrete trigger 2 is triggered when
the turntable starts turning with train on board, and discrete trigger 3 is triggered when rotation stops.
To help generating the tsection.dat entries for new turntable types a rough
spreadsheet (turntable_sectionidxs.xls) can be found in
It computes the X, Z and degree parameters to be inserted in the SectionIdx lines of the
TrackShape block within the tsection.dat file. You only have to insert the diameter of
the turntable and the degree step. Of course you have to take only the lines up to the
one preceding the one with degrees = 180.
Already many existing turntables have been successfully animated and many new other have been created. More can be read in this forum thread .
Info for transfertables is stored in file
turntables.dat too. This file may contain
info for transfertables and turntables together. Here is an example of such file for
a turntable and a transfertable:
2 Turntable( WFile ( "w-005625+014198.w" ) UiD ( 1280 ) XOffset ( 0 ) ZOffset ( 13.4 ) TrackShapeIndex ( 253 ) Animation ( "TRACKPIECE" ) Diameter ( 27 ) ) Transfertable( WFile ( "w-005578+014976.w" ) UiD ( 72 ) XOffset ( 0 ) ZOffset ( 15.0) TrackShapeIndex ( 37300 ) Animation ( "TRACKPIECE" ) Length ( 29.4 ) )
Parameters have the same meaning as for turntables. “Length” is the length of the transfer bridge (therefore the length of the track above it or a bit less, depending from the dimensions of the basin of the transfertable).
The integration .trk file format described in preceding paragraph can be used also for transfertables, using the same sound.
In the standard
tsection.dat there are no usable transfertables defined. Therefore
at least a new TrackShape block has to be created. Also in this case it is suggested
to define the additional block in the route’s specific
Here below is an example for a route’s specific
tsection.dat containing a
TrackShape for a transfertable:
include ( "../../../Global/tsection.dat" ) _INFO ( Track section and shape addition for transfer table derived from turntable 27m ) TrackSections ( 40000 _SKIP ( No change here ) ) TrackShapes ( 40000 _INFO(TrackShape for for 30 m transfer table derived from turntable 27m) TrackShape ( 37300 FileName ( A1t30mTransfertable.s ) NumPaths ( 9 ) SectionIdx ( 1 0 -0.18 -1.1 0 339 ) SectionIdx ( 1 4.985 -0.18 -1.1 0 339 ) SectionIdx ( 1 9.97 -0.18 -1.1 0 339 ) SectionIdx ( 1 14.955 -0.18 -1.1 0 339 ) SectionIdx ( 1 19.94 -0.18 -1.1 0 339 ) SectionIdx ( 1 24.925 -0.18 -1.1 0 339 ) SectionIdx ( 1 29.91 -0.18 -1.1 0 339 ) SectionIdx ( 1 34.895 -0.18 -1.1 0 339 ) SectionIdx ( 1 39.88 -0.18 -1.1 0 339 ) ) )
The first line must be empty.
The animation block for the above transfertable is as follows:
animations ( 1 animation ( 3600 30 anim_nodes ( 2 anim_node BASIN ( controllers ( 0 ) ) anim_node TRACKPIECE ( controllers ( 1 linear_pos ( 2 linear_key ( 0 0 -1.92177 0 ) linear_key ( 3600 39.88 -1.92177 0 ) ) ) ) ) ) )
3600 is not a mandatory value, however to have a reasonable transfer speed a number of animation keys equal to 60 - 90 every meter should be selected.
15.4.3. Locomotive and wagon elevators¶
The elevator is managed by ORTS as a vertically moving transfertable. So files needed are the same as used for a transfertable, with content modified where needed.
Info to identify an elevator in a route is stored in file turntables.dat, as it is for turntables and transfertables. The same file can store info for moving tables of different types. Here a turntables.dat file that contains info for an elevator:
1 Transfertable( WFile ( "w-005578+014976.w" ) UiD ( 75 ) XOffset ( 0 ) YOffset ( -0.18 ) ZOffset ( 13.405) VerticalTransfer ( 1 ) TrackShapeIndex ( 37301 ) Animation ( "TRACKPIECE" ) Length ( 26.81 ) )
What identifies this as an elevator is the presence of the VerticalTransfer parameter with value 1. The other difference to a transfertable is the presence of the YOffset parameter, which is the vertical offset of the zero position of the elevator with respect to the shape file zero.
An example of the animation block in the elevator shape file is shown here below:
animations ( 1 animation ( 1800 30 anim_nodes ( 2 anim_node BASIN ( controllers ( 0 ) ) anim_node TRACKPIECE ( controllers ( 1 linear_pos ( 2 linear_key ( 0 0 -1.92177 0 ) linear_key ( 1800 0 6.07823 0 ) ) ) ) ) ) )
wich generates a vertical movement with a span of 8 meters which is covered in 60 seconds. Of course the 1800 value may be modified to get the desired motion speed.
The elevator must also be defined as a TrackShape in tsection.dat. It is suggested
to define it in a route specific
tsection.dat extension file, which, for the
sample elevator, is as follows:
include ( "../../../Global/tsection.dat" ) _INFO ( Track section and shape addition for transfer table derived from turntable 27m ) TrackSections ( 40000 _SKIP ( No change here ) ) TrackShapes ( 40000 _INFO(TrackShape for for vertical transfer table derived from turntable 27m) TrackShape ( 37301 FileName ( A1t27mVerticalTransfertable.s ) NumPaths ( 2 ) SectionIdx ( 1 0 -0.18 0.0000 0 338 ) SectionIdx ( 1 0 7.82 0.0000 0 338 ) ) )
To insert the elevator in a route using TSRE5 it must be reminded that the latter doesn’t look at the tsection.dat file within the Openrails subfolder. So, for the sole time of the editing of the route, the TrackShape() block must be inserted in the global tsection.dat. After route editing is terminated, the block may be removed. Tsection.dat build 38 or higher is required within the main Global folder.
At runtime the elevator is moved with the keys used for transfertables and turntables. Alt-C moves the elevator upwards, while Ctrl-C moves the elevator downwards.
15.4.4. Path laying and operation considerations¶
By building up a path that enters the turntable or transfertable, exits it from the opposite side and has a reversal point few meters after the end of the turntable or transfertable, it is possible to use the turntable or transfertable in activity mode. The player will drive the consist into the turntable or transfertable and stop it. At that point the reversal point will have effect and will logically lay the consist in the return subpath. The player will put the consist in manual mode, rotate the turntable (in case he is using a turntable) by 180 degrees and return to auto mode. At this point the consist will be again on the activity path.
If instead the player wants the consist to exit to other tracks, he must drive the consist in manual mode out of the turntable or transfertable. If he later wants to drive back the consist into the turntable or transfertable and rotate or translate the train so that it exits the turntable or transfertable on the track where it initially entered it, he can pass back the train to auto mode after rotation, provided the path is built as defined above.
By using the feature to change player train it is possible also to move in and out any locomotive on any track of e.g. a roundhouse or use a shunter to shunt a wagon in and out of a trasfertable.
15.5. .w File modifiers¶
Openrails subfolder can be created within the route’s
Within this subfolder .w file chunks can be positioned. ORTS will first read the base
.w files, and then will correct such files with the file chunks of the
This can be used both to modify parameters or to add OR-specific parameters.
Here an example of a w. file chunk for USA1 .w file w-011008+014318.w:
SIMISA@@@@@@@@@@JINX0w0t______ Tr_Worldfile ( CarSpawner ( UiD ( 532 ) ORTSListName ( "List2" ) ) CarSpawner ( UiD ( 533 ) ORTSListName ( "List3" ) ) Static ( UiD ( 296 ) FileName ( hut3.s ) ) )
With the two CarSpawner block chunks OR interprets the CarSpawners with same UiD present in the base .w file as extended ones (see here). With the Static block OR replaces the shape defined in the Static block with same UiD within the base .w file with the one defined in the file chunk. WAny Pickup, Transfer, Forest, Signal, Speedpost, LevelCrossing, Hazard, CarSpawner, Static, Gantry may have parameters modified or added by the “modifying” .w file.
If the route is edited with a route editor, UiDs could change and so the .w file chunks could be out of date and should be modified.
Entering wrong data in the .w file chunks may lead to program malfunctions.
15.6. Multiple car spawner lists¶
With this OR-specific feature it is possible to associate any car spawner to one of additional car lists, therefore allowing e.g. to have different vehicles appearing in a highway and in a small country road.
The additional car lists have to be defined within a file named carspawn.dat to be inserted in an
Openrails subfolder within the Route’s root folder.
Such file must have the structure as in following example:
SIMISA@@@@@@@@@@JINX0v1t______ 3 CarSpawnerList( ListName ( "List1" ) 2 CarSpawnerItem( "car1.s" 4 ) CarSpawnerItem( "postbus.s" 4 ) ) CarSpawnerList( ListName ( "List2" ) 3 CarSpawnerItem( "policePHIL.S" 6 ) CarSpawnerItem( "truck1.s" 13 ) CarSpawnerItem( "postbus.s" 6 ) ) CarSpawnerList( ListName ( "List3" ) 2 CarSpawnerItem( "US2Pickup.s" 6 ) CarSpawnerItem( "postbus.s" 13 ) )
3 defines the number of the additional car spawner lists.
To associate a CarSpawner block to one of these lists, a line like this one:
ORTSListName ( "List2" )
has to be inserted in the CarSpawn block, in any position after the UiD line.
If the CarSpawner block does not contain such additional line, it will be associated with the base carspawn.dat file present in the route’s root directory.
If the route is edited with the MSTS route editor modifying the .w files referring to the additional car spawners, the above line will be deleted.
To avoid this problem, two other possibilities are available to insert the additional line. One is described here. The other one is to use the OR specific TSRE route editor, that natively manages this feature. Also in the latter case, however, if the route is later edited with the MSTS route editor, the above line will be deleted.
15.7. Car spawners used for walking people¶
The OR specific TSRE route editor is able to generate car spawner paths also outside roads. This has many applications, one of which is to generate paths for walking people. Walking people have the peculiarity that on an inclined path they don’t incline like a vehicle does, instead they remain vertical. To enable OR to handle these car (or better person) spawners specifically, the parameter IgnoreXRotation () has to be inserted in the car spawner list, just after the number of the car spawner items.
Here is an example of a car spawner file specific for walking people to be inserted in the route’s Openrails subfolder ( see here ):
SIMISA@@@@@@@@@@JINX0v1t______ 1 CarSpawnerList( ListName ( "People1" ) 3 IgnoreXRotation () CarSpawnerItem( "walkingperson1.s" 3 ) CarSpawnerItem( "walkingperson2.s" 1 ) CarSpawnerItem( "walkingperson3.s" 1 ) )
15.8. Route specific TrackSections and TrackShapes¶
It quite often occurs that for special routes also special TrackSections and TrackShapes
are needed. Being file tsection.dat unique for every installation, for such routes a
so-called mini-route installation was needed.
The present feature overcomes this problem. The route still uses the common tsection.dat,but it can add to it route-specific TrackSections and TrackShapes, and can modify common ones. This occurs by putting in an
OpenRails subfolder within the route’s root
folder a route-specific chunk of tsection.dat, which includes the TrackSections and
TrackShapes to be added or modified. Here a fictitious example for route USA1 (first
line must be blank):
include ( "../../../Global/tsection.dat" ) _INFO ( Track sections and shapes specific for USA1 ) _Skip ( Further comments here ) TrackSections ( 40000 _Skip ( Comment here ) _SKIP ( Bernina ) TrackSection ( 33080 SectionSize ( 0.9 1.5825815 ) ) TrackSection ( 19950 SectionSize ( 0.9 12 ) ) ) TrackShapes ( 40000 _Skip ( Comment here ) -INFO(Bernina Pass narrow gauge sections / wood tie texture) _INFO(by Massimo Calvi) _INFO(straight sections) TrackShape ( 30000 FileName ( track1_6m_wt.s ) NumPaths ( 1 ) SectionIdx ( 1 0 0 0 0 33080 ) ) TrackShape ( 19858 FileName ( track12m_wt.s ) NumPaths ( 1 ) SectionIdx ( 1 0 0 0 0 19950 ) ) )
In this fictitious example the first TrackSection and TrackShape is present also in the Global tsection.dat, so the effect is that the original TrackSection and TrackShape are modified; the second ones are not present, and so they are added to the lists.
To be able to use these modified items with the actual MSTS RE and AE it is necessary that these modified items are present also in the original tsection.dat file. However, when the work with the RE is terminated and route is distributed, it is sufficient to distribute the above route’s specific tsection.dat.
15.9. Overhead wire extensions¶
15.9.1. Double wire¶
OR provides an experimental function that enables the upper wire for
electrified routes. The optional parameter
ortsdoublewireenabled in the
.trk file of the route can
force the activation or deactivation of the option overriding the user setting in the options panel.
In this example the upper wire is enabled overriding the user setting:
OrtsDoubleWireEnabled ( On )
while in this one the upper wire is forced to be disabled:
OrtsDoubleWireEnabled ( Off )
Another parameter (
ortsdoublewireheight) specifies the height of the upper wire relative to the contact wire;
if not specified the default is 1 meter.
In this example the upper wire is 130cm above the main wire (as in most Italian routes):
include ( "../tures.trk" ) OrtsTriphaseEnabled ( Off ) OrtsDoubleWireEnabled ( On ) OrtsDoubleWireHeight ( 130cm )
Of course you can use any distance unit of measure supported by OR.
15.9.2. Triphase lines¶
The modern electric locos are powered by DC or monophase AC, but some years ago there were triphase AC powered locos. A triphase circuit needs three wires (one for each phase, no wire is needed for neutral); in rail systems two wires are overhead and the third is made by the rails.
OR can enable the second overhead wire with the parameter
ortstriphaseenabled this way:
OrtsTriphaseEnabled ( On )
If the parameter is missing or its value is
Off the usual single wire is displayed.
Another parameter (
ortstriphasewidth) specifies the space between the two wires with a default (if the parameter
is not declared) of 1 meter.
15.10. Loading screen¶
.trk file of the route the parameter
loadingscreen can be used as in this example:
LoadingScreen ( Load.ace )
If in the main directory of the route there is a file with the same name but with extension
and the DDS texture support is enabled
the latter is displayed instead of that with
If the parameter is omitted then the file
load.ace is loaded (as in MSTS) or
(if present and, again, the dds support is enabled).
The loading screen image can have any resolution and aspect ratio; it will be displayed letter-boxed on the screen keeping the aspect ratio.
Another optional parameter
ortsloadingscreenwide, can specify the image to show when the user
loads the route on a wide (16:9) screen. This parameter is ignored when a traditional 4:3 display is used.
15.11. MSTS-Compatible semaphore indexing¶
When a signal shape has a semaphore (moving part), and its animation definition within the
.s file has only two lines (e.g
slerp_rot lines), MSTS interprets the
SemaphorePos() lines within
sigcfg.dat accordingly to following rule:
- SemaphorePos (2) is executed as SemaphorePos (1) - SemaphorePos (1) is executed as SemaphorePos (0) - SemaphorePos (0) is executed as SemaphorePos (0).
Open Rails follows this rule, in case one of the SemaphorePos lines has 2 as parameter. It does not follow this rule in case only 1 and 0 as parameters are present, because in such a case following the above rule they would be both executed as SemaphorePos (0) and therefore the semaphore would be static.
It is however strongly recommended to always have three animation lines within the .s file, where usually the third line repeats the parameters of the first line (except for the animation step).
15.12. Automatic door open/close on AI trains¶
The feature is explained here.
To override the selection made in the Experimental Options Window, a command line must be inserted in a small integration .trk file, that must be located in an Openrails subfolder within the route’s folder, and must have the same name as the base folder. Here below an example of such file:
include ( "../Platformtest.trk" ) ORTSOpenDoorsInAITrains ( 1 )
The first line must be empty.
ORTSOpenDoorsInAITrains ( 1 ) forces door open/close for this route even if the
option within the Experimental Options Window is not checked.
ORTSOpenDoorsInAITrains ( 0 ) disables door open/close for this route even if the
option within the Experimental Options Window is checked.
15.13. Removing forest trees from tracks and roads¶
OR and MSTS determine differently the position of trees in forests. This may result in trees appearing on tracks or roads. To avoid trees on tracks following OR-specific parameter can be added to the .trk file of the route:
ORTSUserPreferenceForestClearDistance ( 2 )
where the parameter represents a minimum distance in metres from the track
for placement of forests.
Alternatively, the original .trk file can be left unmodified, and a new .trk file
inserted into an
OpenRails folder in the root folder of the route. This is
To avoid also forest trees on roads following line:
ORTSUserPreferenceRemoveForestTreesFromRoads ( 1 )
must be added below line:
ORTSUserPreferenceForestClearDistance ( 2 )
either in the route’s root .trk file or in the “Include” .trk file.
It is not possible to remove trees only from roads and not from tracks.
15.14. Multiple level crossing sounds¶
This feature allows to have level crossing sounds different from the default one for a specific level crossing on a route or for a specific level crossing shape. To get a level crossing sound different from the default one for a specific level crossing sound on a route a line like following one has to be inserted in the .w file LevelCrObj block:
ORTSSoundFileName ( "differentcrossingsound.sms" )
where “differentcrossingsound.sms” must be replaced with the desired .sms file name.
If the route is edited with the MSTS route editor modifying the .w files containing such line, the above line will be deleted.
To avoid this problem, two other possibilities are available to insert the additional line. One is described here. The other one is to use the OR specific TSRE route editor, that natively manages this feature. Also in the latter case if the route is later edited with the MSTS route editor, the above line will be deleted.
To get a level crossing sound different from the default one for a specific level crossing shape a line like following one must be inserted in the .sd file of the crossing shape:
ESD_ORTSSoundFileName ( "differentcrossingsound.sms" )
If both lines are present, the first overrides the second. For the first case it is suggested to place the sound file in the sound folder of the route, although it will also be searched in the general Train Simulator Sound folder. For the second case there is no suggestion. The file will again be searched in both folders.
15.15. Defining Curve Superelevation¶
This feature allows curves within the route to be assigned a value for superelevation. It is inserted either in the route’s root .trk file or in the “Include” .trk file.
It should be noted that currently this information only applies to physics calculations for superelevation. The visual movement of the train due to superelevation is set within the option menu.
The values are assigned by inserting the following parameter:
ORTSTrackSuperElevation ( x y .......... )
where x and y are a series of paired parameters specifying the curve radius in metres (x value), and the amount of superelevation in metres (y value). The statement will take as many paired values as desired. Each paired set of values must have an x and y value present. If it is desired to ‘hold’ a certain value of SuperElevation for a number of different radii curves, then the same y value needs to be used for succeeding values of curve radius. Where the y value changes between curve radii, then Open Rails will extrapolate the y value between the two points.
15.16. Overhead (catenary) wire¶
Open Rails uses texture overheadwire.ace to display the overhead wire. Such
texture must be present in the route’s
TEXTURES folder. If the texture is not found
there, Open Rails looks for it in the
GLOBAL\TEXTURES folder. If the texture isn’t
there either, Open Rails selects texture
GLOBAL\TEXTURES\diselsmoke.ace. It is however
strongly suggested to use a specific texture to display the overhead wire. A possible
texture to be used can be downloaded here
15.17. Fading signal lamps¶
In Open Rails, signal lamps fade on and off for a visually pleasing transition
effect. The fade time defaults to one-fifth of a second. It can be customized in
SignalType block of the
sigcfg.dat file using the
SignalTypes( ... SignalType ( "AM14Light" ... ORTSOnOffTimeS ( 0.2 ) ) )
The value is the fade time in seconds. Use
0 to disable the effect
15.18. Animated clocks¶
Animated clocks that show the simulation time can be added or retro-fitted to a route. The clocks can have a second-hand that ticks each second, or one that moves smoothly or none at all. Typically clocks could be station clocks, church tower clocks or clocks at other public buildings. They are placed as normal static shapes in a route, similar to other shapes such as houses or trees.
Note: Loco cabs already have provision for both analogue and digital clocks.
You will need:
Shape and Texture Files
A shape file which defines each shape of clock, its hands and their animation and the texture files used by the shape.
For each shape of clock in the route, a reference to the shape file in the reference file.
The location of each clock in the world must be given in the world file.
Shape and Texture Files
Create a clock just like any other shape. The hands of the clock must be sub-objects within the shape. They must have specific names and an animation.
Open Rails looks for the following names of clock hands in the shape file and animates them according to the simulation time.
The names for the clock hands must start with:
- “ORTS_HHand_Clock” for the hour hand
- “ORTS_MHand_Clock” for the minute hand
- “ORTS_SHand_Clock” for the second hand
- “ORTS_CHand_Clock” for the centi-second hand
This last is used to provide a smooth movement in hundredths of a second whereas the second hand ticks forward once a second. It is suggested to use either the second hand or the centisecond hand or neither.
If a clock is to have several hands of the same type, simply append a number to the names of the hands, like this:
The animation requires 4 key frames at the 12, 3, 6 and 9 positions and calculates the intermediate positions using linear interpolation.
anim_node ORTS_HHand_Clock01 ( controllers ( 1 tcb_rot ( 5 slerp_rot ( 0 0 0 0 -1 ) slerp_rot ( 1 -0.707 0 0 -0.707 ) slerp_rot ( 2 -1 0 0 0 ) slerp_rot ( 3 -0.707 0 0 0.707 ) slerp_rot ( 4 0 0 0 1 ) ) ) )
Finally, move the clock shape and its textures into the corresponding folders SHAPES and TEXTURES of your route, such as ROUTES\<route_name>\SHAPES\clocks.s
Add a reference to the shape file into the reference file ROUTES\<route_name>\<route_name>.ref Make sure that this reference begins with the “Static” keyword.:
Static ( Filename ( "ChurchClock.s" ) Class ( "Clocks" ) Align ( None ) Description ( "ChurchClock" ) )
Use a route editor to locate the clocks in the world file.
Note: Do not insert the shapes as animated ones. Otherwise, if MSTS is used to view the route then the hands of the clock will rotate wildly. In Open Rails they will match the simulation time anyway.