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

[Csantucci]

Hi César,
thanks for your flexibility.
I have a counterproposal, that is adding a new optional parameter in the Speedometer Digital to select whether the UoM must be displayed or not.
If it is not complex for you, this does not exclude the existence of your new ORTS_ETCS Control.

[Csantucci]

Hi César,
I tried using your new ORTS_ETCS control, and was able to adapt it, except for a point: I'd need that also the menu may be optionally disabled (in particular the display of it, including the right-hand vertical menu, but possibly also the commands). I hope this can be implemented.

I also ask you some questions about how to use menu and text messages, in case I (or someone else) will want to use them:
1) is it possible to internationalize the menu strings?
2) how does the TCS script get back the data entered?
3) re text messages, what is the command to let a text message disappear?

[cesarbl]

For menus and data entry windows, I'm still thinking about the best way to create an interface. For example, some locomotives use the ETCS DMI to control other train components, so the menu bar has to be flexible. This includes of course displaying it or not, and enabling and disabling all the buttons.
I'm thinking in this: the TCS sends a list of menu items to be shown, and whether they are enabled. After that, if the driver selects one of the options, the TCS will be informed (I have to decide how). Regarding data entry windows, when the driver validates all data, a list of strings will be sent back to the TCS with the entered values. The most problematic thing I've found is how to merge DMI internal menu entries together with TCS controlled ones.

About localization, I think I'll let it to the TCS, because there are several variations of the texts displayed, even in the same language. For example, the Override menu is called Suppress in some DMIs.

You can add a message to the DMI display queue by adding it to the ETCSStatus.TextMessages list. It will stop being displayed as soon as it is removed from that list. For messages that need to be acknowledged, the Acknowledged variable will be set to true for the acknowledged message, in the ETCSStatus.TextMessagesList.

Re the Units in the Digital() circular speed gauge, is it OK for you if Units (NONE) uses metrical units but doesn't display them?

[Csantucci]

Hi Cesar,
I start from the end: re Units(NONE) your proposal is OK.
About localization, your proposal is OK to me.
About displaying or not menu data I let you think :) At the moment I only need to disable and let the menus being invisible to publish our HST.

[cesarbl]

I've reverted the Digital() control to the previous state, so the full DMI is rendered with this control again. Units(NONE) will hide the speed units. The ORTS_ETCS control is still usable, and is the preferred way to render the DMI, as will eventually allow more configuration.

I have almost finished the interface for menus and data entry windows, but I want to think a little more about it. I removed the menu bar until I'm sure that this interface is good.