Automatic merge of T1.4-660-g5342950a2 and 16 pull requests

- Pull request #537 at e88581e: C# signal script extensions
- Pull request #570 at 824f96f: Experimental glTF 2.0 support with PBR lighting
- Pull request #630 at 704731a: Sky Color Fix (Addresses Trello Roadmap Card #367 for More accurate sunrise and sunset)
- Pull request #650 at 3f8380c: Renewed Russian translation up to testing T1.4-598 version
- Pull request #652 at 918fdb1: Add button functions to Raildriver
- Pull request #675 at 9664141: Bug fix for https://bugs.launchpad.net/or/+bug/1983511 When an AI train disappears at end of run, containers remain visible
- Pull request #677 at a1dc40b: Correct double heading bug
- Pull request #678 at c19e718: Refactor TrainCar part 1
- Pull request #679 at 223aae6: Provide travelled distance to TCS scripts taking into account the running direction
- Pull request #681 at c5cc067: test: Fix tests when StfReader tests run before JsonReader tests
- Pull request #683 at 031b297: fix: Clean up Simulator Tester help output to match dotnet-style
- Pull request #684 at 3f4cc62: fix: Clean up Data Validator help output to match dotnet-style
- Pull request #685 at 203bbd2: fix: Clean up Data Converter help output to match dotnet-style
- Pull request #686 at dab3e59: fix: Clean up Data Collector help output to match dotnet-style
- Pull request #687 at 2cbce1f: fix: Clean up Content Checker help output to match dotnet-style
- Pull request #688 at e44897d: adds Help Icons to Video tab

Source/ContentChecker/SignalScriptLoader.cs

@@ -69,7 +69,7 @@ public override void TryLoading(string file)
                 // we want to load the signal scripts one by one, not as a group
                 var scriptFiles = new List<string>() { Path.GetFileName(file) };
                 var scrfile = new SIGSCRfile(new SignalScripts(_sigcfg.ScriptPath, scriptFiles,
-                    _sigcfg.SignalTypes, _sigcfg.ORTSFunctionTypes, _sigcfg.ORTSNormalSubtypes));
+                    _sigcfg.SignalTypes, _sigcfg.SignalFunctions, _sigcfg.ORTSNormalSubtypes));
             }
         }
     }

Source/Contrib/TrackViewer/Drawing/DrawableTrackItem.cs

@@ -147,14 +147,14 @@ public void FindAngle(TrackSectionsFile tsectionDat, TrackDB trackDB, TrackNode
         /// <param name="sigcfgFile">The signal configuration file</param>
         public void DetermineIfNormal(SignalConfigurationFile sigcfgFile)
         {
-            this.isNormal = true; //default
+            isNormal = true; //default
             if (sigcfgFile == null)
             {   // if no sigcfgFile is available, just keep default
                 return;
             }
-            if (sigcfgFile.SignalTypes.ContainsKey(this.signalType))
+            if (sigcfgFile.SignalTypes.ContainsKey(signalType))
             {
-                this.isNormal = (sigcfgFile.SignalTypes[this.signalType].FnType == MstsSignalFunction.NORMAL);
+                isNormal = sigcfgFile.SignalTypes[signalType].Function == SignalFunction.NORMAL;
             }
         }
 

Source/Documentation/Manual/appendices.rst

@@ -490,28 +490,45 @@ immediately following the lighttextures and lightstab definitions.
 
 ORTSSignalFunctions
 -------------------
+
+.. index::
+  single: ORTSSignalFunctions
+  single: ORTSSignalFunctionType
+
 Additional signal types can be defined in OR, over and above the standard MSTS signal types.
 The additional types must be predefined in the sigcfg.dat file using the ORTSSignalFunctions definition.
 
 The defined ORTS signal types can be set in the signal type definition and used in signal script functions
 in the same way as the default MSTS types.
 
+By default, a custom signal function will have the same behaviour as an INFO signal function: it will have no impact on the
+block sections and will not be able to set a speed limit. You can tell the simulator to consider a custom function to have the
+same behaviour as one of the MSTS signal functions. You can add a MSTS function as a second parameter to the ORTSSignalFunctionType
+parameter. The use of the NORMAL signal function is currently forbidden. To define several types of NORMAL signals, please use
+the ORTSNormalSubtypes parameter.
+
 Note that SPEED is a fixed signal type which is available in OR without explicit definition (see below for
-details on SPEED type signals). Also note that any type definition starting with "OR\_" is not valid, these
+details on SPEED type signals). Also note that any type definition starting with "OR\_" or "ORTS" is not valid, these
 names are reserved for future default types in OR.
 
-Syntax:
+Syntax::
 
-| ORTSSignalFunctions ( n
-|   ORTSSignalFunctionType ( “signaltype” )
-|   . . . 
-| )
-| 
-| The value **n** indicates the total number of definitions.
-| The value **signaltype** is the name of the additional type.
+  ORTSSignalFunctions ( n
+    ORTSSignalFunctionType ( "CUSTOM_SIGNAL_FUNCTION" )
+    ORTSSignalFunctionType ( "CUSTOM_SPEED_SIGNAL_FUNCTION" "SPEED" )
+    . . . 
+  )
+  
+The value **n** indicates the total number of definitions.
+The value **CUSTOM_SIGNAL_FUNCTION** is the name of the additional type.
 
 ORTSNormalSubtypes
 ------------------
+
+.. index::
+  single: ORTSNormalSubtypes
+  single: ORTSNormalSubtype
+
 As detailed above, subtypes can be defined for NORMAL type signals which allows to distinguish
 different use of NORMAL type signals.
 
@@ -522,22 +539,28 @@ statement, see below.
 
 The subtype can be used in specific signal script functions as detailed above.
 
-Syntax:
+Syntax::
+
+  ORTSNormalSubtypes ( n
+    ORTSNormalSubtype ( "subtype" )
+     . . . 
+  )
 
-| ORTSNormalSubtypes ( n
-|   ORTSNormalSubtype ( " subtype " )
-|    . . . 
-| )
-| 
-| The value **n** indicates the total number of definitions.
-| The value **subtype** is the name of the subtype.
+The value **n** indicates the total number of definitions.
+The value **subtype** is the name of the subtype.
 
 Signal Type definitions
 -----------------------
 The following section details OR specific additions to the signal type definition.
 
 Glow settings
 '''''''''''''
+
+.. index::
+  single: ORTSDayGlow
+  single: ORTSNightGlow
+  single: ORTSDayLight
+
 Signal Glow is a feature in OR to improve the visibility of signals at larger distances.
 The required glow setting can de set per signal type in the signal definition.
 The value is a real number, and sets the intensity of the glow. Value 0.0 defines that there is no glow
@@ -553,10 +576,10 @@ Notes :
 - For signal types which have “Semaphore” flag set, the Day value = 0.0.
 - For signals of type INFO and SHUNTING, both Day and Night value are set to 0.0 (no glow).
 
-Syntax:
+Syntax::
 
-| ORTSDayGlow ( d )
-| ORTSNightGlow ( n )
+  ORTSDayGlow ( d )
+  ORTSNightGlow ( n )
 
 The values d and n are the day and night glow values, as real numbers.
 
@@ -565,14 +588,18 @@ Light switch
 There were many signalling systems where semaphore signals did not show lights during daytime. This
 effect can be simulated using the ORTSDayLight setting.
 
-Syntax:
+Syntax::
 
-| ORTSDayLight( l )
+  ORTSDayLight( l )
 
 The value l is a logical value, if set to false, the signal will not show lights during daytime.
 
 Script Function
 ---------------
+
+.. index::
+  single: ORTSScript
+
 Normally, each signal type must have a linked signal script, with the same name as defined for the signal
 type. However, often there are a series of signal types which may differ in definition, e.g. due to
 differences in the position of the lights, but which have the same logic scripts.
@@ -582,36 +609,43 @@ use. Different signal types which have the same logic can therefore all use the
 This script may be defined using the name of one of these signal types, or it may have a generic name
 not linked to any existing signal type.
 
-Syntax:
+Syntax::
 
-
-| ORTSScript( name )
+  ORTSScript( name )
 
 The value **name** is the name of the signal script as defined in the sigscr.dat file.
 
 Normal Subtype
 --------------
+
+.. index::
+  single: ORTSNormalSubtype
+
 As detailed above, a signal type of type NORMAL may have an additional subtype definition.
 
-Syntax:
+Syntax::
 
-| ORTSNormalSubtype( subtype )
+  ORTSNormalSubtype( subtype )
 
 The value **subtype** is the subtype name and must match one of the names defined in
 ORTSNormalSubtypes.
 
 Approach Control Settings
 -------------------------
+
+.. index::
+  single: ApproachControlSettings
+
 The required values for approach control functions for a particular signal type can be defined in the
 signal type definition. These values can be referenced in the signal script as defined for the approach
 control functions.
 
-Syntax:
+Syntax::
 
-| ApproachControlSettings (
-|   PositionDefinition ( position )
-|   SpeedDefinition ( speed )
-| )
+  ApproachControlSettings (
+    PositionDefinition ( position )
+    SpeedDefinition ( speed )
+  )
 
 Possible position definitions
 '''''''''''''''''''''''''''''