[Csantucci]

Rob,
I'm not happy about your decision, and hope you will change your mind.
I have nothing against useful improvements in signalling and track circuit structure (although I fear a bit major reworkings), provided compatibility with existing MSTS and OR content is maintained, as well as access to data of all types of signals and to data of speedposts.

[Serana]

Hello,

I am coming back to OR development. If you need any help for these changes, don't hesitate to contact me.

[Csantucci]

Hi Serana,
that's great news!
In my opinion there are two fields where script extensions would be welcome:
- trackside features, like beacons, indications of start/stop of TCS coverage and so on; I however would prefer not to tackle this now, because it requires changes to critical data structures that now are domain of the .tdb file. First for sure an analysis should be made and approved to define the best approach: probably an extension of the .tdb file is critical, while a parallel file could be a better solution. Such additional file could also include info about electrified/non electrified sections, and also about changes in electrification standard (e.g.25 KVAC to DC and vice-versa). But these are only first thoughts.
- MMI: while I don't see big problems in dedicating to the TCS a list of additional generic commands (especially pusbuttons), I have no ideas about how to cope with displays. Modern TCSs have more or less complex displays on board, with many icons that can be on or off, or that can assume also more than 2 states (starting with two would be a good start). How could these displays be managed in a scripting environment? How could these displays viewed in 2D or 3D Cabs? Should a specific, new window be generated that shows such displays? I believe some trains simulators have that.

[Csantucci]

I have generated a first release of the TCS extensions that, besides having the hooks for the DISTANCE signals needed for the AWS script, now has 32 new generic cabview controls, which can also be associated to generic commands, devoted to TCS scripts. At the moment they are all two-state controls, which are the most used. The code can be viewed in my branch expand-potential-of-TCS-scripts. Comments and suggestions welcome. I haven't yet tested the feature. I have the intention to do it while trying to develop the Italian TCS, called SCMT.

[Serana]

For the MMI (or DMI as we call it in ETCS), we can use the Flight Simulator way : we define an area on the cabview and assign it to a gauge (which is basically a program/script that draws on this area).

For me, one of the other problems is that we can't define custom aspects. For example : "FR_BAL_C" for a double red, or "FR_BAL_RR" for double yellow or "FR_TVM430_170E" for a TVM430 170 kph speed restriction.
The French systems are so complex that the MSTS aspects are not enough.
That's why I wanted to have the possibility to code signals in C#, in order to create more complex signal scripts... and in order not to have a single file for all signal scripts...
That will make it also possible to improve a lot the TCS scripts because, currently, I have to modify in an INI file the systems that must be active for a specific route (due to the restricted number of MSTS aspects) : for the same rolling stock (TGV), I have three variants (TVM300 - TVM430 300 kph - TVM430 320 kph).

[Csantucci]

Serana, on 10 February 2020 - 03:40 PM, said:

For the MMI (or DMI as we call it in ETCS), we can use the Flight Simulator way : we define an area on the cabview and assign it to a gauge (which is basically a program/script that draws on this area).

Yes, it's something that came into mind also to me. However it's beyond my programming knowledge, so I discarded it. If you would like to implement such a feature (maybe for 2D and 3D cabs...), I'd be happy. Linking of the specific program/script with OR should of course not require a rebuild of OR (same as with TCS scripts now).

Serana, on 10 February 2020 - 03:40 PM, said:

For me, one of the other problems is that we can't define custom aspects. For example : "FR_BAL_C" for a double red, or "FR_BAL_RR" for double yellow or "FR_TVM430_170E" for a TVM430 170 kph speed restriction.
The French systems are so complex that the MSTS aspects are not enough.
That's why I wanted to have the possibility to code signals in C#, in order to create more complex signal scripts... and in order not to have a single file for all signal scripts...
That will make it also possible to improve a lot the TCS scripts because, currently, I have to modify in an INI file the systems that must be active for a specific route (due to the restricted number of MSTS aspects) : for the same rolling stock (TGV), I have three variants (TVM300 - TVM430 300 kph - TVM430 320 kph).

True also for Italian signalling, which is so abstruse if compared with the German one. And moreover we have two or three different families of Italian signal scrips, and they manage completely differently the way the displayed aspect is selected. I thought to (partially) bypass it by partly checking the max signal speeds and not the signal aspect to define the in-cab displays. Rewriting signalling seems to me too a big task, and the result could be that no-one then adapts the existing routes. So to me this is not a so viable solution IMHO.
In Italy we don't have the problem of too many TCS. What is of interest is only SCMT for traditional lines and ETCS for high-speed lines.
Maybe a reduction of your problem of different TCS for different lines is to foresee a route's .ini file which is read by the script and defines which TCS are there on such line.

[Serana]

It's also difficult for me since I don't know a lot about rendering.

For the C# signals, for me, it's easy to adapt existing routes. You would just have to name the script the same name as in the SIGSCR file.
For example, if the simulator can find a C# script, it will use it. If it doesn't find it, it will use the SIGSCR script.

Your proposal is not possible for the French routes : we can have a route where we have to go from one system variant to another variant. Currently, we have resolved the issue by using one of the variant where it shouldn't be.

[Csantucci]

Having the possibility of defining within a route the starting and ending points for a specific TCS is indeed a quite importante feature, that could be used also in our country.
To avoid generating a full new signalling structure and code only for this, maybe this could be inserted into the actual one. This again could be done either creating a new ORTSFnType of signal or by using an existing SignalFnType (I'm thinking at INFO) with some parameter (existing or new) to define the precise function of the signal.
It has to be studied whether both solutions can be used with TSRE5 and which one generates less additional signalling data and is more straightforward to implement.

[Csantucci]

This is a progress report on my activities on this field.
32 generic cab display controls, named from ORTS_TCS1 to ORTS_TCS32, are availabe and work. They may be TwoState or MultiStateDisplay types.
They are set by this line of Orts.Simulation\Simulation\RollingStocks\SubSystems\TrainControlSystem.cs

Script.SetCabDisplayControl = (arg1, arg2) => CabDisplayControls[arg1] = arg2;

where arg1 (from 0, corresponding to ORTS_TCS1 to 31, corresponding to ORTS_TCS32) indicates which cab display control is changed and arg2 is its value. arg1 is int and arg2 is float.
The first 16 controls may be also two state commands, which are read by the script with the existing method

public override void HandleEvent(TCSEvent evt, string message)

,
where evt has the values GenericTCSButtonPressed or GenericTCSButtonReleased, and message is the ordinal number (from from 0, corresponding to ORTS_TCS1 to 15, corresponding to ORTS_TCS16) of the involved command, converted to string.
A new method hasn't been added for compatibility with the existing scripts.
The commands are activated only through the mouse.
When the mouse browses over the cab and encounters one of these additional controls, and the Control Confirmations general option is set, a confirmation line is displayed on the screen as for the standard cab controls. This confirmation line is e.g. ORTS_TCS7. To allow better understandability these generic lines can be replaced by script-specific lines. For this purpose within Orts.Simulation\Simulation\RollingStocks\SubSystems\TrainControlSystem.cs there is a list of script-specific control description lines

        public List<string> CustomizedTCSControlStrings = new List<string>();

This list is filled by the script using following interchange function

            Script.SetCustomizedTCSControlString = (value) => CustomizedTCSControlStrings.Add(value);

starting from first to last control used.
The additional controls are added in the .cvf file like standard ones.
Here an excerpt of a .cvf file showing some specific TCS controls:

		TwoState (
			Type ( ORTS_TCS1 TWO_STATE )
			Position ( 453.8 276 8.1 7.5 )
			Graphic ( ../../Common.Cab/Cruscotto_SCMT/Pulsante_Pre.ace )
			NumFrames ( 2 2 1 )
			Style ( PRESSED )
			MouseControl ( 1 )
		)
		TwoState (
			Type ( ORTS_TCS2 TWO_STATE )
			Position ( 453.8 287.2 8.1 7.5 )
			Graphic ( ../../Common.Cab/Cruscotto_SCMT/Pulsante_Ric.ace )
			NumFrames ( 2 2 1 )
			Style ( PRESSED )
			MouseControl ( 1 )
		)
		TwoState (
			Type ( ORTS_TCS3 TWO_STATE )
			Position ( 453.8 298 8.1 7.5 )
			Graphic ( ../../Common.Cab/Cruscotto_SCMT/Comando_RF_trasp.ace )
			NumFrames ( 2 2 1 )
			Style ( PRESSED )
			MouseControl ( 1 )
		)
		MultiStateDisplay (
			Type ( ORTS_TCS8 MULTI_STATE_DISPLAY )
			Position ( 453.8 298 8.1 7.5 )
			Graphic ( ../../Common.Cab/Cruscotto_SCMT/Pulsante_RF.ace )
			States ( 3 3 1
				State (
					Style ( 0 )
					SwitchVal ( 0 )
				)
				State (
					Style ( 0 )
					SwitchVal ( 1 )
				)
				State (
					Style ( 1 )
					SwitchVal ( 2 )
				)
			)
		)
		TwoState (
			Type ( ORTS_TCS4 TWO_STATE )
			Position ( 377 265.5 9 7.8 )
			Graphic ( ../../Common.Cab/Cruscotto_SCMT/Pulsante_SCMT.ace )
			NumFrames ( 2 2 1 )
			Style ( ONOFF )
			MouseControl ( 1 )
		)
		TwoState (
			Type ( ORTS_TCS5 TWO_STATE )
			Position ( 377 276 9 7.8 )
			Graphic ( ../../Common.Cab/Cruscotto_SCMT/Pulsante_Man.ace )
			NumFrames ( 2 2 1 )
			Style ( ONOFF )
			MouseControl ( 1 )
		)
		TwoState (
			Type ( ORTS_TCS6 TWO_STATE )
			Position ( 377 287.2 9 7.8 )
			Graphic ( ../../Common.Cab/Cruscotto_SCMT/Pulsante_RSC.ace )
			NumFrames ( 2 2 1 )
			Style ( ONOFF )
			MouseControl ( 1 )
		)
		TwoState (
			Type ( ORTS_TCS7 TWO_STATE )
			Position ( 377 298 9 7.8 )
			Graphic ( ../../Common.Cab/Cruscotto_SCMT/Pulsante_SR.ace )
			NumFrames ( 2 2 1 )
			Style ( ONOFF )
			MouseControl ( 1 )
		)
	)

Further interchange functions added are:

            Script.NextNormalSignalDistanceHeadsAspect = () => NextNormalSignalDistanceHeadsAspect();
            Script.DoesNextNormalSignalHaveTwoAspects = () => DoesNextNormalSignalHaveTwoAspects();
            Script.NextDistanceSignalAspect = () => NextDistanceSignalItem<Aspect>(ref SignalAspect, Train.TrainObjectItem.TRAINOBJECTTYPE.SIGNAL);
            Script.NextDistanceSignalDistanceM = () => NextDistanceSignalItem<float>(ref SignalDistance, Train.TrainObjectItem.TRAINOBJECTTYPE.SIGNAL);
            Script.LineSpeedMpS = () => (float)Simulator.TRK.Tr_RouteFile.SpeedLimit;
            Script.DoesStartFromTerminalStation = () => DoesStartFromTerminalStation();

Here an example of a standard cabview by Màyo where I replaced the central control panel and surrounding buttons with others with higher resolution (enlarge the picture to see details). 7 of the 8 surrounding buttons have been animated with the above .cvf file blocks. A confirmation line can be seen. Unfortunately on the captured screenshot the mouse icon is not shown.


Continuing the work for the implementation of the Italian SCMT TCS further display controls will be added within the panel screen, and probably also some further interchange functions will be needed.
In my opinion these extension should allow to implement TCSs of other countries (like e.g. the German countries) in a more complete way.

The OR code is available in my public OR repository within branch expand-potential-of-OR-scripts, and will be in short time within OR NewYear MG. To include the features within the official OR versions I need the still missing approval of the blueprint https://blueprints.l...-of-tcs-scripts by James.

[Csantucci]

My work on this matter is getting the first results.
Here https://www.youtube....vOgVYK_30&t=43s you can watch a video where the basic functionalities of the Italian SCMT and RSC Train control systems are demostrated.