[Csantucci]

Yes, you can have multiple cab signal controls following different logics and of different lenght, which may be also bigger than 8.

Re the other problem I'd like to keep compatibility with existing script(s). If you find a solution that keeps such compatibility, that could be inserted in the code.

[Serana]

Ok, I tried to write something in my scripts, such as

if (Locomotive() is MSTSElectricLocomotive electricLocomotive)

and... it didn't work.

The CSharpCodeProvider in the framework is only compatible with C# v5 and not the latest versions (and seems like we are not using it properly according to Microsoft : we shouldn't use the CSharpCodeProvider with CreateCompiler but the CodeDomProvider.directly).

In order to support C# v7, the modifications are simple (and I tested it and it works perfectly), but the package provided by Microsoft on NuGet adds the Roslyn compiler in the final directory.(18,7 MB).

[Serana]

Something weird is happening when I use one of the ORTS_TCS cabview controls with a style ONOFF (on the cabview, it is a switch with a lever).

When I click on it the first time, I receive GenericTCSButtonPressed. No problem.
When I click on it the second time, I receive GenericTCSButtonReleased... and GenericTCSButtonPressed after that.
Do you have any idea what could provoke this ?

[Csantucci]

This is the way it works now, because else the generic code lines that manage the TCS commands should be different for ONOFF and PRESSED commands.
As of now TCS commands may be only of PRESSED type. If you have to manage a switch, you must have a PRESSED TCS control for the command, with transparent .ace, and an ONOFF TCS control (with no command) that you use for the display of the switch, and whose state is managed by the script.
Maybe a further generalization could be envisaged where, looking at the Style() of the control, different code lines are used for the command.

[Serana]

Alright, I already modified the customized cabview control name. You can review/test it on this branch : https://github.com/S...-TCS-extensions
And here's the branch for C# v7 script support (based on 64bit branch, but can be adapted easily for the official branch) : https://github.com/S.../script-csharp7

I am taking a look at the ONOFF command currently. Maybe I will be able to do something.

Edit : And... it's done. You can take a look on my repository. I did the same thing as in the CircuitBreaker commands.

[Csantucci]

I have briefly tested your TCS-extensions branch (first link you have provided in your post here above) for downward compatibility with my SCMT-RSC script (which was my main concern), and didn't find issues. So I have nothing against if you create a PR to the official OR repository for those changes. Having this in the Unstable release will provide for a broader testing before merging into the Testing release. I periodically merge the Unstable release into OR NewYear MG, so these features would be later present also in such release.

[Serana]

I talked about C# signal script previously. I make a proof of concept.
Here's the branch with my concept of C# signal scripts: https://github.com/S...p-signal-script
Scripts would be like that: https://github.com/S...nal_Scripts_POC

Example: https://github.com/S...ter/BAPR-AVL.cs
This is a distant signal.
As you can see, one of the new concepts is the text signal aspect. You can customise the name of the aspect to fit your needs which makes it less ambiguous.
And it also facilitates the creation of more complex signal aspects (such as the ones needed for TVM430, for example : "FR_TVM430_Ve270_Vc270V_Va220").


The interface with TCS scripts in in progress.

[gpz]

Csantucci, on 28 March 2020 - 10:21 AM, said:

I have added what I think is a useful hook for people writing TCS scripts: it is

            Script.Locomotive = () => Locomotive;

Locomotive is the actual player locomotive.
It looks like a trivial thing, but with this the TCS script may have access to the whole Simulation environment public classes and methods (trainset, player train, signals and so on).
Therefore it is no more needed to add further personalized hooks, and only general use hooks might be added.

Hi all, I am just reading through the posts in this thread, and the above mod hit my eyes. It is a bad idea exposing such an internal object to scripts, because it may change at any time, which renders the script incompatible. A small refactoring, a change in a variable's name, or a major change for accomplishing some important thing and oops... the script is off. That is why there is a scripting interface defined. That can be guaranteed to remain in place, and its functions are always connected to the internal structure of the bigger program properly. This kind of exposing cannot be allowed from the OpenRails development perspective, looking the big picture.

[Csantucci]

Peter, restricting possibilities to the script writer has a big disadvantage: in the few experience I had writing TCS scripts I noticed that every TCS has its specific, and often very particular, requirements, and continuing adding new and very specific interfaces to the OR code to satisfy the requirements of this and the other script isn't a practical neither elegant solution in my opinion. Allowing to the script writer the access to the Locomotive class solves this problem. There is already at least one script using this access. I think this advantage more than counters the disadvantage of the risk that internal OR simulator structures will be reshuffled therefore creating incompatibilities.

[gpz]

Carlo, I think you knew it from the beginning, that it's wrong. Serana has also drawn your attention to it. Why did we bother with the definition of the other functions of the interface in the first place? - one might ask. - Just give one class, and everyone can dig out his needed data, right? - No, it is not right. We, as the OpenRails developers, want to retain the freedom to change anything in the internal structure, without notice and without negotiations with the script writers. For this, we define an interface that doesn't change, and allow the script writers to interact solely via this interface. This a principal rule of scripting all over the world.

Csantucci, on 26 August 2020 - 11:12 AM, said:

continuing adding new and very specific interfaces to the OR code to satisfy the requirements of this and the other script isn't a practical neither elegant solution in my opinion.

But… This is exactly the scope of this work! You have to collect the needs, and think of a system that best fits! By keeping in mind not just one possible additional script, but a generalized system.

I must say, I could think of more system-like functions for the (sorry for the word) FAQ-style additions mentioned on the first page of this thread, numbered 1-5.

(1) is too specific, got ignored, that maybe someone else needs to check other aspect types, other numbers. Instead, this function should return an array of possible aspects, and let the script writer examine whether those are the ones that he is searching for.

(2) Is always only the first next distance signal (or head) important, or the subsequent ones as well? In the latter case the pattern of the other queries should be followed, with a Func<int, float> type definition.

(3) Why aren't the distant signals collected into a common array together with the distant heads of normal signals, and this function returns the aspect of the next closer one? This way (4) and (5) would not even be needed. And this function maybe should also follow the pattern.

Designing a scripting interface is not easy. What functions does the script you mentioned need from the internal Locomotive class? A real interface must be defined for those.