[roeter]

gpz, on 31 January 2014 - 06:46 AM, said:

Looks like Unity scripts do contain the "using"-s and the namespace, probably because of the same issue. Maybe the script should be pre-parsed in some way before compiling, to remove the tricky references?

If you're heading that way, you might as well head to a full parser rather than a script.
A parser based on similar logic as sigscr.dat could be build onto the existing sigscr.cs code. That code is 'parameterized' to quite a high level, and adding specific functions for TCS would not be too much work.
It would also have the added advantage that it is more familiar to many users, more so than C# language.
Also, any errors in the script would be caught by the parser and not lead to crashes. I think there are many users and engine-builders out there who would not know how to debug C# code.

By the way - did you check on the PM I send you for the code to collect required information?

Regards,
Rob Roeterdink

[gpz]

Yes, I received your PM, and thank you for the code, that makes it absolutely clear. (Just I was at work, and didn't have time to incorporate it yet.) Looks very promising!

About a parser: I didn't mean to parse the main code itself, rather just looking for some keywords, which would prevent the compilation. But I would be happy if nothing such would be needed.

C# has many advantages over the sigscr.dat language: It is absolutely easy to learn; it is a full object-oriented language, which can be fully used in the script; runs without any runtime interpretation, it is the same as if was written directly into the main program; intellisense support, etc. I just feel it more professional in long term.

[roeter]

Object-oriented is not easy to learn for those who do not know the concept. Not everybody out there is a software expert.
The question here is : is the general user interested in a high-level full singing and dancing objec-oriented professial language, or in something basic he (or she) allready knows?

Regards,
Rob Roeterdink

[gpz]

The first such scripts will might be coded by me (or us), and the others later probably will be copies with some modifications. And neither I know the sigscr.dat-language, nor am interested in learning it. :wheelchair: If it is such basic, then even less. I'm doing it for fun, and programming in a simple language isn't fun at all. (It's enough for me to s...ck with Aveva PDMS pml macro language at work.)

Don't misunderstand me, I really appreciate the work you have done with the parser for sigscr.dat, it might have been a really hard task, and it is an essential part of the success of OpenRails. I would like to say thank you for this, and of course the continuous work with the signalling you are doing!!

[James Ross]

I'm all for a fully-defined, integrated language like C#. With a little tweaking of how we load scripts, we can have it such that you can actually breakpoint your TCS code in VS and debug your way through it, and with Edit and Continue. It makes sigscr look like assembly programming. :wheelchair:

It's worth remembering that, even within the set of people who make content, those that will want or have the knowledge to make a TCS is small. Most people will just be using pre-made TCSes.

Anyway, I'd consider this a interesting experimental feature which we may remove or completely change at any time.

[Csantucci]

James Ross, on 31 January 2014 - 12:51 PM, said:

... look like assembly programming. :)

That's been the most relevant software activity I did in my professional life :ph34r: Therefore I like the signal scripting language...

[gpz]

Serana, on 09 February 2014 - 03:30 PM, said:

In the TGV, there are multiple CCS systems (control command and signalling): Crocodile (train protection), KVB (train protection with speed control), TVM (signalling, train protection with speed control). You also have to add the CCS of other countries for the TGVs 3xxx (Eurostar) and 4xxx (international TGVs).

The problem is that there are interactions between some of the systems and the rules are not the same.
For example, with KVB, an EB for speed control must stop the train whereas the TVM COVIT brakes until the speed is correct.
There are also technical differences because the systems use either continuous transmission (KVBP, TVM, LZB, ETCS L1 with Radio Infill, ETCS L2) or discontinuous transmission (KVB, PZB, Signum, ETCS L1).

In order to choose the correct rule, the TCS file must know what type of signalling system is used. That will be possible only when the signalling interface for Open Rails will be available.
I think an interesting way to do it is to create plugins (for example : Crocodile and KVB plugin, TVM plugin, ETCS plugin, etc.).
Then, you define in the TDB the zones that use TVM, the ones that use LZB, etc.

For the KVB file, I guess I will consider that all trains equipped with the KVB are supervised by it.

The script, as described in first post of this topic, is supposed to work exactly like you described the plugin system. But currently only one is supported at a time. We could define multiple of them for a single locomotive, in case we could specify the method to switch between them.

I think currently only the continuous transmission can be simulated, assuming that all the systems also use continuous transmission. This is because there is no way currently to add transponders to MSTS routes. There was a recent discussion about it in an other topic, and this was the conclusion.

Could you please take a look on the example script attached to the first post? I would be glad if we could move this feature forward.

[Csantucci]

Hi Peter,
is this feature at the stage that it can be already usable to write scripts? If yes, could you provide some basic documentation on how to use it? (E.g. variables that can be read/written?)

[gpz]

Hi Carlo,

You may start out from the script I attached to the first post. That can be used as a plug-in to the .eng file in a way I described there.

If one creates a new C# project, and adds a reference to RunActivity.csproj, he gets intellisense support as well. Unfortunately adding a reference just to RunActivity.exe is not enough, because although the functions will be available, but without the parameter descriptions and XML summary. I have yet to find out the reason of this.

The API is defined in ORTS.Scripting.Api namespace. If needed, that can be extended with more functions.

[Serana]

gpz, on 09 February 2014 - 11:17 PM, said:

The script, as described in first post of this topic, is supposed to work exactly like you described the plugin system. But currently only one is supported at a time. We could define multiple of them for a single locomotive, in case we could specify the method to switch between them.

I think currently only the continuous transmission can be simulated, assuming that all the systems also use continuous transmission. This is because there is no way currently to add transponders to MSTS routes. There was a recent discussion about it in an other topic, and this was the conclusion.

Could you please take a look on the example script attached to the first post? I would be glad if we could move this feature forward.

A way to represent a continuous transmission for the script is to simply look at the state of the signal in front of the train.
For the discontinuous transmission, you may have to save the state of the signal in front of the train. This saved state can then be used in the next zone to do the speed control.
For example, when a train is running towards a signal, it will save the state of this signal (the aspect and a speed limitation if necessary) when it is about to pass it. Then, it will use this information for the train protection.

For the plug-in system, you've talked about the TCS, but we also have to do something for more complex systems (for example, for those who use more than 8 aspects). I think we should add ground TCS plug-in that will send specific information to the rolling stock plug-in.
It is also needed because systems such as TVM, LZB and ETCS don't work the same way.

How to switch between the CCS systems ? There are different methods used on the rolling stock.
In the TGV : ETCS (if existing) has priority. Then, the TVM and KVB have to decide which one must be active. On classic lines, the TVM is in stand-by mode and the KVB is active. An EPI or a BSP beacon wakes up the TVM. Then, a KVB beacon tells the KVB to check if the TVM is active. If it is the case, the KVB goes in stand-by mode while the speed is above 160 km/h (because below this speed, the KVB is used for Temporary Speed Restriction).
In the simulator, we can just define an order of preference. Using the zones I talked about in my previous message, the train can determine with this order which system is active.

I will use the demo script in order to represent the KVB. I won't be able to adapt it for the TVM while the signalling system is not extended because the rules aren't the same.

[gpz]

Serana, on 10 February 2014 - 05:49 AM, said:

I think we should add ground TCS plug-in that will send specific information to the rolling stock plug-in.

And here comes the problem. Please read an other topic starting from here.

[roeter]

gpz, on 10 February 2014 - 07:34 AM, said:

Quote

Serana, on 10 February 2014 - 02:49 PM, said:
I think we should add ground TCS plug-in that will send specific information to the rolling stock plug-in.

And here comes the problem. Please read an other topic starting from here.

Yes, I can confirm that - ground-based transponders is a step too far at the moment.
At best, this can be considered when OR-specific sigcfg.dat and sigscr.dat structures are developed, at worst it will have to wait for OR's own Route Editor.
For the moment, any TCS will have to work with info available from signal and speedpost objects.

Regards,
Rob Roeterdink

[Serana]

Houston, we have a problem !

Sorry... :D

I have managed to represent the behaviour of the KVB. I still have some adjustments to the speed control.

I have two problems :
1) If there is a second locomotive in the consist, when SetPantographsDown() is called, the second locomotive doesn't receive the event sent by this function. This order should be applied to the whole consist.
2) In the French automatic block, a warning aspect can be announced by a blinking yellow light if the distance between the stop signal and the warning signal is too short. For the speed control, I need to know the whole slow down sequence at the first restrictive signal. Instead of a single triplet (aspect, speed limit, distance), the abstract class should give a table that contains the triplets of at least 3 signals ahead (can also be used for the TVM system).

I have also solved a problem in ScriptedTrainControlSystem.
Line 245 : when the program is searching for the first signal or the first speed post in front of the train, it always find the last one of the list (if the break instruction isn't reached, then it is the one that was selected before the break).
Why ? Because anonymous functions seem to do a reference to the list item... that evolves during the loop.
Solution : create a new variable each time that will be referenced by the anonymous function.

            foreach (var _foundItem in Locomotive.Train.MUDirection == Direction.Reverse ? TrainInfo.ObjectInfoBackward : TrainInfo.ObjectInfoForward)
            {
                var foundItem = _foundItem;

Best regards.

[gpz]

I will make the necessary changes. I am really glad you spot on the problems, and especially on the API issues, in this early stage. It would be a lot harder to make such modifications if many scripts already existed out there.

Then I will modify the NexSignal... functions to return and array of 3 elements. Is such an array needed for speedposts too?

[James Ross]

gpz, on 12 February 2014 - 01:40 AM, said:

Then I will modify the NexSignal... functions to return and array of 3 elements. Is such an array needed for speedposts too?

My suggestion would be that all the methods that return "next" information accept a numeric parameter indicating how many items they want. Perhaps also with an overload that doesn't take a parameter and just returns a single item for convenience in simpler TCSes.