[Csantucci]

César,
thank you for your proposal.
I have now terminated the development of the DMI for the ETR400. It uses a very stripped-down DMI startup. However I'll be happy to integrate both the Data Entry and the Track Monitor-like independent DMI window code into OR NewYear MG, because I think also others will develop DMI cabs. I also hope that Monogame will sooner or later be integrated into the testing version of OR, so that you can also file a PR to the official OR version.
BTW, if the Data Entry code had been available when I started coding the ETR400 script, I for sure would have used it... ;)

[cesarbl]

I'll start with the menus and windows. I want them to be flexible to allow different variants of the DMI, depending on the TCS script needs, so it will take me some time to code everything. There are plenty of objects to create (buttons, keyboards, input text boxes...). Something that won't be possible is to have different UI designs depending on the manufacturer of the DMI, as it adds a considerable amount of work.

In fact, the only thing that could be incompatible with XNA is the shader change provided by Dennis for the circular speed gauge, but I haven't tested it on XNA. When I finish with the menus I'll try it (if Monogame hasn't been merged yet) and file a PR.

[cesarbl]

I have almost finished the UI design of the different menus. Here is an example:

My idea for data entry is that the TCS sends the DMI a list of fields to be entered. Each field can be of one of these types: numeric, alphanumeric, or any value from a fixed list. Additionally, a list of technical checks can be sent to ensure that the driver enters valid data. When all the fields have valid values, the entered data will be sent to the TCS.

I wonder if some of the menus and input windows should be managed internally by the DMI, or it's better to send everything to the TCS. I'm thinking for example in the brightness and volume configurations.

[Csantucci]

Hi César,
great job.
About your question: if brightness and volume are quite fixed items, I'd leave them internally in the DMI, like e.g. the scale icons for the planning area.

I have also a request to you: I'd need to avoid displaying the km/h string in the tacho. Masking it seems not to be a solution, because for some scaling problem in some configurations it hides part of the central circle of the pointer, and in other ones it doesn't completely hide the string.

I have seen that the code of CircularSpeedGauge.cs already foresees the option to display or not the string, however in DriverMachineInterface.cs the option is fixed to true (display unit of measure). Could you think at a code change to allow to set the option either within the .cvf block or within EuropeanTrainControlSystem.cs?

[cesarbl]

Hi Carlo,
There are a few things that are implementation dependent, so maybe the best option is using a specific ETCS cabview control instead of Digital(). Then the whole control block could be parsed by the DMI.

At least, this is what should be configurable:

• Units for the speedometer, and if they are to be shown
  
• Scale of the speedometer
  
• Selection of DMI layout, between soft key and touch screen technologies
  
• In the future, a reference to one or several .ace files with custom symbols to show (for replacement of default ones or to add NTC symbols)

[cesarbl]

I have uploaded a first version of the DMI menus. The graphical side is almost implemented, but I still have to create the interface to the TCS.
As usual, some hacks will be needed to adjust everything to small DMI sizes.

I added a feature for testing purposes: if a right click is performed, the DMI will toggle between full resolution and scaled resolution.

Carlo, I disabled the mip-mapping, so you can safely delete the full resolution icons for the merge.

[Csantucci]

Thanks César,
this will be merged into next release of OR NewYear MG.

[cesarbl]

I created a specific cab view control for the ETCS. The Digital() one only renders the circular speed gauge for compatibility. This is the syntax:

ScreenDisplay (
	Type ( ORTS_ETCS SCREEN_DISPLAY )
	Position ( 291 239 100 100 )
	Units ( KM_PER_HOUR )
	Parameters (
		MaxSpeed 260
		DisplayUnits 1
	)
)

Carlo, I'm sorry, but you'll have to reposition the DMI yet another time. At least now the position determines the top left corner of the DMI, so it can be adjusted with Gimp as usual for other controls.

[Csantucci]

César,
that's not good news for us. We were ready to publish our train together with the ETCS script. I'll have to stop things, to immediately generate a new OR NewYear MG release and to modify the .cvf file.
If this cnange is really necessary, I'll have to do that.

Does the new Control include also the management and the display of the circular gauge, or are two Controls needed (one for the circular gauge, and another for the rest of the ETCS DMI)?

[cesarbl]

I did that because of your request of hiding the units of the speedometer. If you prefer the previous approach then don't merge this last commit and I'll revert it in my branch. With this command, the Digital() command renders only the circular speed gauge, and this new control renders the full DMI (including speedometer). What do you suggest for the DMI configuration?

Note that I uploaded this last commit today, so the menu window commit introduced yesterday is not affected.