[Serana]

I agree with James. The size of the array of signals depends on the CCS system itself. I think your solution (create an overload function) is the one we should code.

FYI, I made a mistake in my calculation.
For the French automatic block, we need an array of 2 signals for the worst stop sequence : VL (green) => (VL) (green blinking) => (A) (yellow blinking) => A (yellow) => S (red) or C (double red).
The first change, (VL), provokes a speed limit of 160 km/h at the next signal. So, we only have to consider the sequence (A) => A => S or C. We need to know AFTER the (A) aspect the distance to the signal that has the S or C aspect. So we need the information of 2 signals.

For the TVM system, it is the same because the system needs : the current speed limit, the speed limit in the next block section and the speed limit in the block section after this one. When the second block section gives a more restrictive speed limit that the first, the indication on the cab-signal blinks.

The worst case we'll have is the ETCS... because in Level 2, we'll have to look at the aspects of the signals that are 4 or 5 block sections ahead on high speed lines.

PS : I have access to the SNCF technical documentation because I work as an engineer in a CCS company in France.

[roeter]

The information offered to the TCS from the train is a list of signals and speedposts (sorted by distance), upto the first signal with state STOP - or end of path or route as applicable.
Note that if the user requests more than one signal, this might not always be available - no information is provided beyond the first signal at state STOP.
If TCS systems need information on multiple signals and speedpost, the best option would be to pass on the original list - or at least the info out of this original list.
With regards to the variable nature of the information, a list seems more appropriate than an array.

Regards,
Rob Roeterdink

[Csantucci]

I like the possibility to get the state of more than one signal ahead of the train. Our continuous TCS, called "Ripetizione Continua Segnali" (RSC) (which is now integrated in the newer beacon-based SCMT TCS) in its version for higher speed lines has e.g. the so-called "Superverde" (super-green) state, which means that there are at least three green signals ahead. And even in its version for normal lines it has a state that depends from the state of the next two signals ahead.

[gpz]

I have committed r2022 with modifications to querying the next signals. Now you can query e.g. NextSignalSpeedLimitMpS(3) for the fourth signal's limit, and the syntax NextSignalSpeedLimitMpS() still works, which is the same as NextSignalSpeedLimitMpS(0). Other Nex...() functions work the same way. I hope this is what you meant. :whistling: (I felt dangerous to pass a list to the script writers, since that can lead to various exceptions caused by invalid indexes. This way the function is absolutely safe.)

[James Ross]

Common\Scripting.cs(165,58): error CS0241: Default parameter specifiers are not permitted

Did you use something from C# 4 by accident?

[gpz]

Oops, this must be the line:

public delegate T NextSignalFunc<T>(int forsight = 0);

I wasn't even aware of it. On internet now I read, that this is supported from the beginning (C# 1), just the compiler needs to be of higher version... (wtf?) This was the reason I haven't noticed it. I remove it.

Edit: Removed. Then 0 needs to be explicitly defined in NextSignalSpeedLimitMpS(0). Sorry.

[Serana]

There is another bug. Sometimes, the speed post list is empty.
When NextSignalItem is called for NextPostSpeedLimitMpS, an exception is thrown at line 222 because there is no element in the list.

[James Ross]

gpz, on 12 February 2014 - 01:38 PM, said:

On internet now I read, that this is supported from the beginning (C# 1), just the compiler needs to be of higher version... (wtf?) This was the reason I haven't noticed it. I remove it.

I suspect there's a mixup there; it is not supported in C# before version 4, but it is supported by .NET (and the CLR) in version 1. It was supported by the runtime from the start because optional and named parameters existed in VB. They were added to C# later. (Feature support in the runtime being different from the languages that run on it can be confusing.)

[gpz]

Serana, on 13 February 2014 - 12:19 AM, said:

There is another bug. Sometimes, the speed post list is empty.
When NextSignalItem is called for NextPostSpeedLimitMpS, an exception is thrown at line 222 because there is no element in the list.

I think I know where the problem is, will make the changes. Sorry for inconvenience. :)

[gpz]

Serana, could you please make a new test with r2025?