roeter, on 16 January 2021 - 03:18 AM, said:
What saddens me is that arguments are used to promote this which simply are not true.
For instance, the remark that certain US signals cannot be properly set up because it's not possible to capture these in 8 states makes no sense as signals are no longer restricted to 8 states. I have set up signals according to the french signalling rules, the main signal in this set handles 26 states.
Also, the remark that TCS scripts cannot access these local variables is not true. To get the state of a signal, the TCS script must have access to the signal object. But it is precisely that object which holds these variables, so if you can access the state you can access these variables.
The TCS does not have access to the SignalObject, only to a restricted set of variables collected from it. Certainly, the local variable dictionary could be added to the TCS interface (it should have to be serialized in order to work in multiplayer operation though). However, I have the impression that using
if(NextSignalTextAspect() == "SomeAspect")
is much more intuitive than
if(NextSignalLocalVariable(some_arbitrary_key_number) == custom_aspect_index)
roeter, on 16 January 2021 - 03:18 AM, said:
Furthermore, certain restrictions, as the max. 8 external states, and the max. 8 states for display definitions, are not lifted using scripting because these restrictions are the result of other definitions or code, e.g. the external state is used in track monitor, cabview, dispatcher window and AI control. The max. of display states used for a signal type is defined in the sigcfg.dat. These restrictions will therefor apply just a much to C# scripted signalling as to the present scripting.
You are right. That's why we have kept the MstsSignalAspect variable as a fallback. In the signalling system we are building for Spain, non NORMAL signals use the SIGSCR script, so they don't have access to the text aspect and use the fallback aspect instead. It is also used for TrackMonitor and AI trains, as you say.
roeter, on 16 January 2021 - 03:18 AM, said:
The greatest danger of C# scripting is that it takes related code out of the program. If that code uses certain variables or calls of a specific class, it cannot be verified if changes to that class will affect these scripts. That either means that such classes must be fully frozen, which could seriously hamper future development, or there is a risks of script becoming incompatble due to program changes. One cannot expect that a developer will first check all scripts before making changes, so in practice it would come down to a full freeze. That does really worry me. If it were really true that the required functionality cannot be provided through the existing scripting, than it might be a valid choice. But most if not all of the arguments which have been given so far are just not true.
So before going down these uncharted and possibly dangerous waters, I would like to suggest to make one more dedicated attempt to capture the functionality within the existing structure. I am quite willing to help in this, and without boasting I dare say I know a thing or two about OR signalling.
The C# scripts won't have access to OR internal structures and classes. They only have access to a well defined set of functions, which are equivalent to the SIGSCR ones. The risk of incompatibility is the same as for SIGSCR scripts: for example, if the route_cleared_to_signal is modified, both SIGSCR and C# scripts will be affected.
roeter, on 16 January 2021 - 03:18 AM, said:
I am not ruling out C# scripting as alternative for ever, but it should be part of a more general renewal of signal definitions, not only looking at scripting but also at signal definition through the sigcfg file, for only then will it be possible to really lift the most troublesome restrictions.
Even if the sigcfg structure, or the whole signalling environment is modified, we have to keep SIGSCR functionality for compatibility. Since the C# scripting only uses functions already existing for SIGSCR, I don't see why we would need to wait for this.
You are right that using C# scripting is not really necessary, as we could build our signal system using 30 different heads for each signal, but I think it allows configuring signals in an easier way. The SIGSCR syntax is really simple, and I think extending it to allow using some features like function definitions, that C# offers out of the box, is to reinvent the wheel.