[Hobo]

I like the idea of a smaller window as Carlo suggested but moving it to a different monitor etc. should definitely be optional . We don't all use double or triple viewing options so please go easy on the mods . Just don't over simplify or over complicate .

You'll discourage a lot of the Simmers if you turn the HUD into an engineering exercise . They are here to run trains , make minor adjustments of operation and enjoy the experience . They're not here to re-engineer the whole process .

Just My thoughts on the subject !

[Csantucci]

I've tried the two versions prepared by Mauricio, and I like them much more: thanks to Mauricio. I prefer the version without notifications, because it is smaller (see attached picture), and would go even further by dividing the braking data into three lines instead of two, in order to further reduce width if possible. I wonder if some line could also spared, as there are some empty lines at the bottom.

The attached picture is taken in a Multiplayer case, with two players, to evidence a problem: every time a new player enters the MP session, a line is added with the name of such player and the distance from the player viewing the HUD. This means that the MP HUD as it is now has not a fixed number of lines, and can easily grow beyond the bottom of the new HUD window. Therefore I'd suggest to skip the info about the player names and distances in this "compressed" HUD. I'm also in favour of deleting the OR version line in this windowed HUD. Also the blank line after "MultiplayerStatus:Client" can be deleted.

Speaking about the extended HUD pages, while I back the HUD scroll feature that Mauricio has implemented (because it allows to see data that else would disappear beyond the borders of the main window), I don't see the need to rework further such extended HUD pages; here I agree with James that such pages have mainly a debug or check purpose, and therefore it's enough that they are capable to display all needed data, and I think this is substantially the case now. Neither do I see the need to generate specific windows also for such pages, as they'd cover most part of the main window.

Having instead the possibility to move all windows available nowadays also outside of the OR main window, including displaying them on another screen, would be a welcome feature, but would require a major reworking of this part of software. I don't know if that could lead to visible reductions of FPS.

[scottb613]

steamer_ctn, on 17 October 2019 - 12:36 PM, said:

Another point.

As we are contemplating some reasonably significant changes, it maybe worthwhile to highlight this thread in TrainSim, and UKTrainSim so that the widest possible audience can be engaged in the discussion.

Hi Peter,

Good idea - once I create some suggested examples - I'll post on TS - as for UKTS I thought I read most folks there kind of abandoned ORTS in favor of DTG ?

Hobo, on 17 October 2019 - 06:02 PM, said:

I like the idea of a smaller window as Carlo suggested but moving it to a different monitor etc. should definitely be optional . We don't all use double or triple viewing options so please go easy on the mods . Just don't over simplify or over complicate .

You'll discourage a lot of the Simmers if you turn the HUD into an engineering exercise . They are here to run trains , make minor adjustments of operation and enjoy the experience . They're not here to re-engineer the whole process .

Just My thoughts on the subject !

Sounds good - I don't think anyone wants to eliminate things we have and it should always default to single monitor capability...

Csantucci, on 18 October 2019 - 08:38 AM, said:

I've tried the two versions prepared by Mauricio, and I like them much more: thanks to Mauricio. I prefer the version without notifications, because it is smaller (see attached picture), and would go even further by dividing the braking data into three lines instead of two, in order to further reduce width if possible. I wonder if some line could also spared, as there are some empty lines at the bottom.
Open Rails 2019-10-18 06-17-44.jpg
The attached picture is taken in a Multiplayer case, with two players, to evidence a problem: every time a new player enters the MP session, a line is added with the name of such player and the distance from the player viewing the HUD. This means that the MP HUD as it is now has not a fixed number of lines, and can easily grow beyond the bottom of the new HUD window. Therefore I'd suggest to skip the info about the player names and distances in this "compressed" HUD. I'm also in favour of deleting the OR version line in this windowed HUD. Also the blank line after "MultiplayerStatus:Client" can be deleted.

Speaking about the extended HUD pages, while I back the HUD scroll feature that Mauricio has implemented (because it allows to see data that else would disappear beyond the borders of the main window), I don't see the need to rework further such extended HUD pages; here I agree with James that such pages have mainly a debug or check purpose, and therefore it's enough that they are capable to display all needed data, and I think this is substantially the case now. Neither do I see the need to generate specific windows also for such pages, as they'd cover most part of the main window.

Having instead the possibility to move all windows available nowadays also outside of the OR main window, including displaying them on another screen, would be a welcome feature, but would require a major reworking of this part of software. I don't know if that could lead to visible reductions of FPS.

Hi Carlo,

Yep - if windowed HUDS would cause a substantial decrease in framerate - I don't think that's a road anyone would want to head down...

14 FPS on a default route - ouch - that's painful...
:shock6:

Regards,
Scott

[Genma Saotome]

scottb613, on 18 October 2019 - 09:08 AM, said:

... if windowed HUDS would cause a substantial decrease in framerate - I don't think that's a road anyone would want to head down...

Could text in a windows window, ideally send via a html portal, be done in its own thread? IOW, can one thread do a read-only on the memory of another?

My recollection of the unix environment is "messages" in memory were exchanged between processes via daemons. I would think anything to do with the retention of game data could be handled this well, assigning the formatting and disk interaction to the receiving thread.

[mbm_OR]

Quote

@Scottb613: if windowed HUDS would cause a substantial decrease in framerate - I don't think that's a road anyone would want to head down...

The decrease in FPS is related to the emulation of a Multiplayer session on the same machine, using a non-gaming machine.
The "Basic HUD window" doesn't drop the FPS, at least on my laptop.

Hobo, on 17 October 2019 - 06:02 PM, said:

Just don't over simplify or over complicate

The improvements should always be welcome, but without forgetting those users who prefer easy things.
That is why, it has been added a checkbox option "[] Standard basic HUD window" (Option/Video) to allow the user choices between "Standard" or "Abbreviated" for the "Basic HUD window" version.

This code detects if a Multiplayer session is activated and it modifies the window height.

To open the "Basic HUD window" use <Ctrl + F5> keys.

Attached is the new code aligned with the OR x131-98 Testing version.
05/11/2019. New update here.

Regards,
Mauricio

[scottb613]

Hi Mauricio,

Thanks - I'm home now and anxious to take a gander...

Please disregard my comments on multiplayer - I just realized the multiplayer information is not present - if not in multiplayer mode (the way it should be)…

I'm working on the abbreviated examples we spoke of...

:sign_thanks:

Regards,
Scott

[scottb613]

Hi Folks,

Just so everyone can see what Mauricio has done - here's a screenshot of the latest:

BASIC



ABBREVIATED



Hah - apparently ORTS doesn't use a constant width font - therefore my idea to keep everything in perfect alignment probably won't work...

Would it be hard to highlight the label - if the control is being operated/moved - for a couple seconds ? I would probably add a line separator to differentiate between displayed values - and control position indicators...

Just suggestions...


Regards,
Scott

[steamer_ctn]

scottb613, on 19 October 2019 - 06:58 AM, said:

Please disregard my comments on multiplayer - I just realized the multiplayer information is not present - if not in multiplayer mode (the way it should be)…

In order to maintain the concept of having minimal information displayed on the screen, I believe that, as I proposed in the HUD purposes above, only information relating to the driving of the train should appear in the "Train Driving HUD". Multiple Player information is more related to game operation and therefore should be located elsewhere.

Also would it be possible to size the window based upon the information needing to be displayed?

[scottb613]

Hi Folks,

First off - we can't thank Mauricio enough for working with us... I really like his decision to add a setting to select the "Full Text HUD" or the "Abbreviated HUD" in the settings - should keep everyone happy...

As per the test code - hopefully we can eliminate all the blank unused space at the bottom of the HUD and condense it a bit more - we need the smallest footprint practical to obscure the least amount of screen real estate possible - while still efficiently conveying the necessary information...

I think Dave agreed we could eliminate the redundant "Gradient" value from the Train HUD as it's more appropriate on the Track Monitor - with the caveat - that the gradient per car value is available in the Debug HUD ? I think the blue label in the test code also could confuse things - on the value it's fine if that's how you want to indicate up or down gradient...

I'm with Peter - the Train HUD should be restricted to only the information necessary and available for driving a train... All values that don't fit this limitation should be removed... I also agree - that if possible - the HUD is sized to be just big enough to support the values displayed - as they vary between locomotives...


My vision of what the HUD should look like (Labels in left hand column - Values in right):



Steam HUD



The highlighted label (magenta) - indicates the control has just been moved by the operator and should stay magenta for a similar time period that Control Confirmations remain visible - with the end goal of removing Control Confirmations entirely... This should work on all displayed control labels (REVR, REGL, CCOK, SAND, BTRN, BENG) in example...

The (cyan) brake text - differentiates between the actual control position and the values you are using to gauge how much breaking effort you need to apply... Just to help you see what you need - quickly...

The "STEM" value on Steam Locomotives dynamically changes color already - to indicate if you're using more steam than you're producing - granted - another cheat...


Regards,
Scott

[scottb613]

Hi Folks,

Proposed list of abbreviations to use...

===ELECTRIC===
TIME = Time 
SPED = Speed
DIRC = Direction
THRO = Throttle 
BTRN = Brake Train
BLOC = Brake Locomotive
BDYN = Brake Dynamic
PANT = Pantographs
CIRC = Circuit Breakers
POWR = Power
SAND = Sander

===STEAM===
TIME = Time 
SPED = Speed
REVR = Reverser
Fwd  = Reverser Forward
Rev  = Reverser Reverse
REGL = Regulator
BTRN = Brake Train
BLOC = Brake Locomotive
STEM = Steam Usage
BOLS = Boiler Steam Pressure
BOLW = Boiler Water Level
FUEL = Fuel (F=Fuel) (W=Water)
CCOK = Cylinder Cocks
SAND = Sander

===DIESEL===
TIME = Time 
SPED = Speed
DIRC = Direction
THRO = Throttle 
BTRN = Brake Train
BLOC = Brake Locomotive
BDYN = Brake Dynamic
SAND = Sander
ENGN = Engine
FUEL = Fuel

===BRAKE VALUES===
Rels = Release
RelQ = Release Quick
Appl = Apply
AppQ = Apply Quick
AppS = Apply Slow
Serv = Service
LapS = Lap Self
Lapp = Lap
Runn = Running
Emer = Emergency
FOT  = Front of Train
EOT  = End of Train
BP   = Brake Pipe
BC   = Brake Cylinder
EQ   = Equalized

Regards,
Scott