[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

[cjakeman]

Serana, on 13 February 2014 - 02:02 PM, said:

Could it be possible to have a function that returns the slope of the track ?

Lots of reasons for wanting that and displaying it to the driver.

Also, on steam locos, it will affect the water gauge reading as the water moves to one end or the other.

Just a thought,

[gpz]

I'm not sure how to get this information. A trivial way would be to read it from the locomotive's XNAmatrix.

[roeter]

The current track elevation (as percentage) is available in :

Cars[LeadLocomotiveIndex].CurrentElevationPercent

However, I would advise against using this for speed or brake distance calculation.
It only gives the value of the elevation of the present (MSTS) track section, and as such gives no indication on the overall gradient between the present train position and the signal. Also, this value can differ quite a bit from one track section to the next, which would lead to considerable jumps in the calculation.
What really would be required is the overall ruling gradient, but this is not available as the traveller only calculates the X and Z values of the train position, and not the Y value (height).

Regards,
Rob Roeterdink

[Matej Pacha]

I'm afraid this is not good information in ORTS - the elevation value changes with the Vibration - the higer vibration the higher elevation "distortion". It's caused by the Vibration feature moving with the car, so the XNAMatrix position vector changes all the time. Anyway, I've never seen such device on the locomotive. Other thing is to have it as a database in the automatic train control system. Anyway, this should be needed for target braking only. The speed control doesn't need it at all (or shouldn't).

Best regards,

Matej

[Serana]

For me, target braking is a part of speed control.

In the distance formula I gave before, something is added.

distance = (speed^2 - targetSpeed^2) / (2 * (deceleration - g * slope * 10^-3))
with slope in mm/m.
The KVB and ETCS beacons give this information to the on board control unit.