In the *.tdb, the locations of Trackitem (Signals, Speedpost, Milepost, Levelcrossing, etc.) are defined as follows, example entry in the TDB:
SignalItem (
TrItemId ( 3 )
TrItemSData ( 18.1304 00000002 )
TrItemRData ( 137.325 49.9499 -226.043 -5578 14978 )
TrSignalType ( 00000000 1 4.23109 Sig25VHp01_fH_jm )
there exist two Parameter to locate a TrackItem, which define the same point
TrItemSData ( ) is the distance in meters from the starting point of a track part
TrItemRData ( ) is a three-dimensional coordinate in space, for the same object
OR and MSTS process these coordinates differently to determine locations and function of TrackItems:
The MSTS consistently uses the same parameters for location of TrackItems:
MSTS-Simulator TrItemSData( )
MSTS-RE TrItemSData( )
OpenRails uses, in CONTRAST to MSTS, the space-parameter in its tools.
OR-Simulator TrItemRData( )
TrackViewer TrItemRData( )
BUT the TSRE5, the only route-editor for OR, uses the same parameter as MSTS
TSRE5 TrItemSData( )
In order to ensure the compatibility of the OpenRail with MSTS, TrItemSData( ) should also be used in OpenRails and Trackviewer for the location of TrackItem
The MSTS-RE has left many routes where the two coordinates do not indicate exactly the same position of a Signal. This is even so in the six MSTS original routes!!
Calculated with TrItemSData (MSTS simulator), signal A precedes signal B. Calculated according to TrItemRData (OR simulator), signal B precedes signal A. In the OR simulator, the signal sequence then appears as reversed, signal B is in front of A, which leads to disturbances of the signals.
This problem is probably also the cause of similar problems with other trackitems.
Surprising finding:
If I set the first 3 coordinates of TrItemRData ( 137.325 49.9499 -226.043 -5578 14978 )
to zero in .tdb and .tit
as this: TrItemRData ( 0 0 0 -5578 14978 )
then the problem in OR disappears and the signal A precedes signal B
and OR is handling the Signals correctly!
So it seems, that OR can handle also TrItemSData( ) for TrackItems, if the space-coordinates are not present.
Imported from https://bugs.launchpad.net/bugs/1961400
In the *.tdb, the locations of Trackitem (Signals, Speedpost, Milepost, Levelcrossing, etc.) are defined as follows, example entry in the TDB: SignalItem ( TrItemId ( 3 ) TrItemSData ( 18.1304 00000002 ) TrItemRData ( 137.325 49.9499 -226.043 -5578 14978 ) TrSignalType ( 00000000 1 4.23109 Sig25VHp01_fH_jm )
there exist two Parameter to locate a TrackItem, which define the same point TrItemSData ( ) is the distance in meters from the starting point of a track part TrItemRData ( ) is a three-dimensional coordinate in space, for the same object
OR and MSTS process these coordinates differently to determine locations and function of TrackItems:
The MSTS consistently uses the same parameters for location of TrackItems: MSTS-Simulator TrItemSData( ) MSTS-RE TrItemSData( )
OpenRails uses, in CONTRAST to MSTS, the space-parameter in its tools. OR-Simulator TrItemRData( ) TrackViewer TrItemRData( ) BUT the TSRE5, the only route-editor for OR, uses the same parameter as MSTS TSRE5 TrItemSData( )
In order to ensure the compatibility of the OpenRail with MSTS, TrItemSData( ) should also be used in OpenRails and Trackviewer for the location of TrackItem
The MSTS-RE has left many routes where the two coordinates do not indicate exactly the same position of a Signal. This is even so in the six MSTS original routes!!
Calculated with TrItemSData (MSTS simulator), signal A precedes signal B. Calculated according to TrItemRData (OR simulator), signal B precedes signal A. In the OR simulator, the signal sequence then appears as reversed, signal B is in front of A, which leads to disturbances of the signals.
This problem is probably also the cause of similar problems with other trackitems.
Surprising finding: If I set the first 3 coordinates of TrItemRData ( 137.325 49.9499 -226.043 -5578 14978 ) to zero in .tdb and .tit as this: TrItemRData ( 0 0 0 -5578 14978 ) then the problem in OR disappears and the signal A precedes signal B and OR is handling the Signals correctly! So it seems, that OR can handle also TrItemSData( ) for TrackItems, if the space-coordinates are not present.
see here: http://www.elvastower.com/forums/index.php?/topic/35990-signals-too-close/ in Post:1,5,8,11