Train Driving UI window

[mbm-OR]

Blueprint https://blueprints.launchpad.net/or/+spec/train-driving-ui-window

[YoRyan]

Is there a reason the multiplayer window has to be separate, but tied to the new train driving window? Why not bake its information into the existing train list window?

[mbm-OR]

The new train driving info window inherits the same principle as the HUD window. Like the original, the multiplayer information was displayed within the HUD window.
Now the proposal is to show the multiplayer information in a dedicated window.
Maybe we could create a web-multiplayer window, if possible.

[YoRyan]

Well, the HUD is a debugging tool not meant for use by ordinary players, so it makes sense to communicate the state of the multiplayer subsystem there.

But dedicating an entire window for the multiplayer state? One that can't be closed, shows just two lines, and contains information that seemingly would fit very well within the existing Train List (Alt+F9) window?

I'm just having trouble seeing the justification here.

[Csantucci]

Well, the HUD is a debugging tool not meant for use by ordinary players, so it makes sense to communicate the state of the multiplayer subsystem there.

But dedicating an entire window for the multiplayer state? One that can't be closed, shows just two lines, and contains information that seemingly would fit very well within the existing Train List (Alt+F9) window?

I'm just having trouble seeing the justification here.

The Multiplayer info is used also by ordinary players, both by the dispatcher and by the clients (I have experienced that in a good amount of multiplayer sessions), so IMHO it makes sense to have that info together the Train Driving Info window. The info might however be included in the Train Driving Info window, instead of being in a separate, small window, although also the actual layout, with a separate add-on window, provides the same functionality from the point of view of the user.

[mbm-OR]

This is a multiplayer session, Dispatcher-player side:

Similar info is replicated Client-player side.

[YoRyan]

This would be the first window that is divided into multiple, interlinked windows, so the impetus is on you to explain why this would be desirable for players.

[mbm-OR]

Initially, the MP information was located on the lower part of the Train Driving Info (TDI) window.
But the information of each new player who joined the MP session increased the width and height of the TDI window.
Taking into account that the purpose of the abbreviated mode is to display a window as narrow as possible, keeping the MP session information in the same window, makes it infeasible to obtain a narrow TDI window.
This was the reason to implement a dedicated Multiplayer window.

[YoRyan]

Not keen on Ctrl+F5 as the shortcut. For our existing bindings, the general rule of thumb is that Ctrl represents some kind of mode toggle (Ctrl+F4 track monitor mode, Ctrl+F7 label display mode) while Alt opens extra windows (Alt+F9 train list window). How about Alt+F8 for the default key?

[Csantucci]

F5 is used for the main HUD, so it seems mnemonically useful to use Ctrl-F5 for the Train Driving Info, that displays more or less the same information. Moreover Ctrl-F5 is being used in ORNYMG since long time...

[mbm-OR]

The Train Driving Info is a small HUD, with just the information required for the driver.

[YoRyan]

Okay, so I get the F5 mnemonic now. But it's unfortunate that this would be the only window that toggles with the Ctrl mod key. So far, for window popups, we've always used Alt:

On a second look, I would actually suggest assigning the new window to Alt+F5, while moving "Basic HUD Toggle" to Shift+F5.

I should say that, in my thought process, I'm thinking about brand-new players who are downloading OR for the very first time. "Because it's the way we've always done things" isn't a convincing argument to me because, if you already have a NewYear or mainline config with Ctrl+F5 already assigned, OR will preserve, not overwrite, that assignment. Meanwhile, any new players will be left wondering about this seeming inconsistency.

Definitely a controversial decision; maybe we need the management team's opinion here? @cjakeman

[mbm-OR]

From the Manual:
7.4.1 Basic Head Up Display (HUD)
By pressing F5 you get some important data displayed at the top left of the display in the so-called
Head Up Display (HUD). If you want the HUD to disappear, press F5 again.
The HUD has 6 different pages. The basic page is shown at game start. To sequentially switch to the other
pages press Shift+F5. After having cycled through all of the extended HUD pages, the basic page is
displayed again.
To hide or redisplay the current extended HUD data while continuing to show the basic HUD, press
Alt+F5.

After many years using a familiar key sequence for the HUD and extended windows. I have the feeling that it won't be welcome by current users.

[cjakeman]

Definitely a controversial decision; maybe we need the management team's opinion here? @cjakeman

Sorry to hold you up. This mention had passed me by. Will confer and get back to you all shortly.

[YoRyan]

I'm also having trouble rendering the bottom text. It's black on black and impossible to read:

[mbm-OR]

It's black on black and impossible to read:

It's a trick to prevent the window height from changing every time that an item is displayed.
We could replace the black text by empty items, while keeping the required spaces, to let unmodified the window height.

[Csantucci]

It's black on black and impossible to read:

It's a trick to prevent the window height from changing every time that an item is displayed.
We could replace the black text by empty items, while keeping the required spaces, to let unmodified the window height.
This is used only for steam locomotives. So for electrics and diesels these lines will always remain black; IMHO for such locomotives it would be better if these lines weren't displayed. As long as the player doesn't switch player locomotvie, the window height would remain the same and would be smaller, with no unused lines.

[mbm-OR]

This is used only for steam locomotives. So for electrics and diesels these lines will always remain black; IMHO for such locomotives it would be better if these lines weren't displayed.

Now a new code display items based on the engine type.

[mbm-OR]

It has been detected that the feature to toggle the WindowGlass (transparency) at runtime, works well only, when the ToggleFullScreen() function (Alt + Return) is not called, otherwise, after switching from windowed to full-screen mode, sometimes a transparent window, like a layered window, is visible. That is why this feature is removed.

[cjakeman]

Mauricio,

In the OR_NewYear_MG version, clicking on the yellow dot switches the window between wide and narrow format.

I was hoping that clicking on the yellow triangles would do the same (and duplicate the Shift+F5 keystroke), but I find that nothing at all happens which is a shame.

Chris

[cjakeman]

Mauricio,

I've suggested changes to the Manual text in 3 places so that it reads as better English. Hope that's OK.

Chris

[mbm-OR]

I was hoping that clicking on the yellow triangles would do the same (and duplicate the Shift+F5 keystroke), but I find that nothing at all happens which is a shame.

Chris

Fixed. It was a misunderstanding by my part.

[mbm-OR]

I've suggested changes to the Manual text in 3 places so that it reads as better English. Hope that's OK.

Chris

Thank you for your help.
I understand, that I must apply all yours suggested changes to the current driving.rst file. Is it right?

[cjakeman]

Hi Mauricio,

I understand, that I must apply all yours suggested changes to the current driving.rst file. Is it right?

Not "must" but "may" - these changes are not a condition for approval. I think the Manual would be better if you made these changes to driving.rst. If you wish, you can do this from right here within GitHub, by pressing the Commit Suggestion buttons.

P.S. I am very thankful that you have worked on this PR and quickly enough so that it will become part of the v1.4 Release (expect a code freeze very soon).

Chris

[cjakeman]

Hi Mauricio,

Thanks for those changes.

Approved.

[Sharpe49]

During initialization in timetable mode, this line is executed and triggers an exception because MPManager.Catalog is null.

[mbm-OR]

Thank you very much for detecting it so quickly.
A possible solution would be the following:

protected internal override void Initialize()
{
base.Initialize();
// Reset window size
if( !Owner.Viewer.Simulator.TimetableMode )
UpdateWindowSize();
}

I will generate a bug report and a PR.
PR: Bug fix for https://bugs.launchpad.net/or/+bug/1942652. Timetable crash. #466