Planning area of the ETCS DMI
#1
Posted 17 November 2020 - 08:37 AM
However there is at least one display section of the DMI that can't be implemented satisfactorily with what is available today, and this is the Planning area (a sort of TrackMonitor).
Some years ago Peter (gpz) did a very good job, that I'm using, by generating a DriverMachineInterface.cs C# file, that is part of the OR solution, and that includes the management of the ETCS tachograph present in the ETCS DMI. Already seeing the name of the file, I expect that Peter was considering a possible extension of the file to further features of the ETCS DMI.
So the questions are:
1) is it correct to add to such file also the management of the Planning area of the DMI?
2) César has written here in the forum that he has done - as I interpret it - considerable work in implementing ETCS for OR. Could it be possible for him to pass to DriverMachineInterface.cs the part of code that implements the Planning area (and maybe parts of code that implement other parts of ETCS)?
3) if not, is someone (e.g. Peter) willing to work on such functionality? (I found a very old discussion about that here in the forum)
4) if not, as a pure hypothesis I might consider to try to develop something to be added to DriverMachineInterface.cs, but that's not the solution I prefer, as I'm sure the two people above would do the job much better than me.
#2
Posted 17 November 2020 - 08:58 AM
#4
Posted 17 November 2020 - 11:25 AM
DMI under national system, just before switch to ETCS L2, radio link already established

Under ETCS L2, braking needed

The trainset is the four-current ETR400, which, if Covid allows that, should circulate in next years also in France and Spain and accepts also the 15kV used in the German-speaking countries.
#5
Posted 17 November 2020 - 12:51 PM
Something similar will be achieved by drawing the DMI in the cabview, but in a much cleaner and user-friendly way. I'll start learning the basics of Monogame and I hope I can show some results soon.
#6
Posted 17 November 2020 - 01:43 PM
What is missing in what I have done is also the braking distance square, which would be possible with conventional MSTS-like design only using many frames with squares of different measures. Here too a coded solution can simply provide a better result.
#7
Posted 18 November 2020 - 12:03 AM
#8
Posted 18 November 2020 - 01:17 AM
#9
Posted 18 November 2020 - 06:42 AM
In my 1366x768 laptop the digits are hardly seen, as Carlo said. I'm not an expert in graphics, but it would be awesome to have some kind of zooming function to see the DMI console.
#10
Posted 18 November 2020 - 07:49 AM
Edit: I'm using SharedTextureManager.Get() like for TrackMonitor, but I have to copy the symbols to the Content folder by hand.
#11
Posted 20 November 2020 - 01:16 AM
It is rendered using the same cabview control that was used for the CircularSpeedGauge, just for testing.
A quick way to test it is using the default MSTS script, which I have modified to show the new DMI features.
Regarding the API, I have created a dedicated ETCSStatus class accessible from the TCS, but this can be changed if there's a more convenient way to do it.
public class ETCSStatus { // General status public bool DMIActive = true; ... // Speed and distance monitoring ... // Planning information public bool PlanningAreaShown = true; public List<PlanningTarget> SpeedTargets = new List<PlanningTarget>(); public PlanningTarget? IndicationMarkerTarget; public float? IndicationMarkerDistanceM; public List<GradientProfileElement> GradientProfile = new List<GradientProfileElement>(); public ETCSStatus Clone() { // Clone all elements and lists so they can be accessed safely by RenderProcess } } public struct PlanningTarget { public float DistanceToTrainM; public readonly float TargetSpeedMpS; public PlanningTarget(float distanceToTrainM, float targetSpeedMpS) { DistanceToTrainM = distanceToTrainM; TargetSpeedMpS = targetSpeedMpS; } } public struct GradientProfileElement { public float DistanceToTrainM; public int GradientPerMille; }
I have found some issues due to floating point to integer round errors when downscaling the components, so bad-looking areas will appear with low resolution screens or small DMI area in cab.
#12
Posted 20 November 2020 - 08:39 AM
thank you very much! I'll try now to apply to the ETR400 what you have kindly created, by inserting your code first as a branch into OR NewYear MG, and then merging it (if you agree of course).
I'll report about the results.
#13
Posted 21 November 2020 - 02:09 AM
you've done a fast and great job! I've appreciated also very much the possibility of disabling the display of the planning area, which I need when the train is running on a part of route equipped with the national TCS.
Here a picture

I only notice that the external maxspeed ring of the tacho touches the distance numbers of the planning area; there is also a strange small black area on the right of the tacho between the tacho itself and the maxspeed ring, but they are really minor things. Maybe I have to respect some rule in defining the ratio between width and height of the control?
I wonder what your intentions are now: will you add other info to such area, or will you leave it so?
What do you suggest to find out next elevation profile segments? I'm thinking at another list to be conditionally (only with Planning area shown) generated within the UpdatePlayerTrainData() method.
Thank you again!
#14
Posted 21 November 2020 - 03:15 AM
There seems to be a problem with the shader, because the gauge is doing something weird after 200km/h. I'll look at it. Did this happen in previous versions?
I used a wrong font size for distance scale numbers, they are bigger than they should. Thanks for pointing it.