[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.