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

[Serana]

The bug is no longer present. Thanks.

But, there is another modification to do, otherwise the target distance doesn't update regularly.

In TrainControlSystem.cs, at line 227, please delete :

if (forsight >= list.Count) 

and keep the SearchTrainInfo function.

I nearly finished the KVB system. I had to use Maple in order to find the formula of the alert and emergency speed curve. That's because the formula written by the engineers of SNCF is a formula of braking distance. You'll see, the formula of the speed curve is quite complex. But it works really well ! :good2:
I still have to modify the vigilance monitor.

[gpz]

Serana, on 13 February 2014 - 12:21 PM, said:

But, there is another modification to do, otherwise the target distance doesn't update regularly.
In TrainControlSystem.cs, at line 227, please delete :

if (forsight >= list.Count) 

and keep the SearchTrainInfo function.

Are you sure about this? Because if you check it, Update() function looks like this:

        public void Update()
        {
            if (Script == null)
                return;

            SignalSpeedLimits.Clear();
            SignalAspects.Clear();
            SignalDistances.Clear();
            PostSpeedLimits.Clear();
            PostDistances.Clear();

            // Auto-clear alerter when not in cabview
            if (Locomotive.AlerterSnd && Simulator.Confirmer.Viewer.Camera.Style != ORTS.Viewer3D.Camera.Styles.Cab)
                Script.AlerterPressed();

            Script.Update(); 
        }

So all the lists are cleared at the beginning of the Update(). My idea was that the lists would not be updated at every query, just once at a particular Update(). Although they are fully updated at the next Update(). I think that interval should be enough.


It is great if you can create such a formula for the speed curve!! I think eventually we should include it into the API into some kind of a GenerateSpeedCurve class or method! :good2:

[Serana]

Sorry, it seems that the Local variables window of Visual C# doesn't always update itself. Adding the lists to the Watch variable list showed me that the lists are updated.

I managed to reproduce the discontinuous transmission of the KVB using a previous distance variable. If the next signal distance variable is bigger than the previous distance, it means we have just passed a signal.

Could it be possible to have a function that returns the slope of the track ? I need that because braking distances are shorter when the train is climbing and the KVB cares about that. Thanks.

For the speed curve, the one I coded is specific to the KVB. Other systems may not use the same thing.

A more generic formula is : distance = (speed^2 - targetSpeed^2) / 2 * deceleration.
The speed curve formula is : speed = sqrt(2 * deceleration * distance + targetSpeed^2).
The deceleration is a parameter of the train.
In order not to have a EB when passing a signal, you have to use : speed = max(speed, 30 km/h) for example if you want to approach the signal at 30 km/h.
The KVB formula is different because it adds several things :
The braking establishement delay : 2 seconds for trains that have electropneumatic brakes, another formula for those who don't, and another for heavy freight trains. This braking delay multiplied by the speed of the train is added to the distance formula. We get the emergency curve.
For the alert curve, we add an anticipation time of 5 seconds.
For current speed control, we add 5 km/h to the speed limit in order to have the alert speed. We add 10 km/h to the speed limit in order to have the emergency braking speed.
For double red aspect (on protection signals), these speeds are reduced to 2,5 km/h and 5 km/h respectively. The approach speed is reduced to 10 km/h.

[steamer_ctn]

Hi Peter,

I cannot build (compile) any changes once I update to #2026. #2025 worked fine for me.

When I attempt to build, I get the following message:

Error	22	The command "if not Debug == Release echo $Revision: 000 {:content:}gt;Revision.txt
if not Debug == Release date /t>>Revision.txt
if not Debug == Release time /t>>Revision.txt
call "G:\Open Rails Source Code\Open Rails Repository\openrails\Source\3rdPartyLibs\GNU.Gettext\BuildMenuLocales.bat"" exited with code -2146232576.	Menu

Is this an issue my end?

Thanks

Peter

[Serana]

Hi,

There is maybe a bug in the localization build script that has been modified in revision 2026.
http://www.elvastowe...view=getnewpost