[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

[mbm_OR]

Hi Scoot,

Your vision of what the Train Driving window should look like, it seems an interesting challenge.
Enough work for a long time, but I will try.

scottb613, on 21 October 2019 - 08:13 AM, said:

Proposed list of abbreviations to use...

The proposed list of abbreviations should be quite helpful. Thanks.

scottb613 said:

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

Or rather, ORTS did not use a constant width font. With the new code it is possible.
Now all abbreviations appears in perfect alignment.

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

Regards,
Mauricio

[scottb613]

mbm_OR, on 21 October 2019 - 01:35 PM, said:

Hi Scoot,

Your vision of what the Train Driving window should look like, it seems an interesting challenge.
Enough work for a long time, but I will try.


The proposed list of abbreviations should be quite helpful. Thanks.


Or rather, ORTS did not use a constant width font. With the new code it is possible.
Now all abbreviations appears in perfect alignment.

Attached is the new code aligned with the OR x131-98 Testing version.
F5TrainDrivingWindow-x131-98.zip

Regards,
Mauricio

Hi Mauricio,

My intent is not to overwhelm you or chain you to a massive development commitment - I so appreciate your open willingness to even talk about these mods and to even consider working on this at all... We don't have to do everything at once and everything is totally at your leisure... If you get bored and want to move on to something else - maybe someone else will pick up the ball after that - that's kind of how this Open Source thing works...

I'm an IT guy by trade but not a software developer... I'm a complete novice at C but I'm pretty decent with Unix shell scripting and all that entails - so I at least understand many of the concepts involved... If I can do anything to assist with your work I'll gladly pitch in where I can but my skill is truly limited... I think it would be a big step ahead if we could design clear and concise plan that will work best for the community and improve our sim as a whole... That way we at least have some common goal to work towards...

I started this same conversation over at Train Sim to see if we can get a bit more input from our intended audience... So these design goals can change and grow as we move forward... What I really want to minimize is wasting your time...

Hah - I upgraded my laptop - I can run ORTS as I travel - so I'll take a look at your latest...

Really - thank you...

Regards,
Scott

[eric from trainsim]

Just to throw a wrench in the wringer...

Why not make the HUD something with its own config file that you can turn on/off or re-order as you see fit?

You can already see dozens of opinions here on what's needed and what isn't, which means some degree of the user base will not be happy with any change.

The system variables are already there, so isn't it just a matter of what's being exposed?

[scottb613]

Hi Folks,

Nice - Mauricio - I like the constant width fonts - keeping everything lined up just makes it easier to find what you're looking for with the least amount of effort...

Once the HUD is built - it would seem pretty easy to blank values for user preference...

I have been giving this a great deal of thought - finished some more working models and a new feature subject to peer review...

Steam HUD


Diesel HUD


Electric HUD


Note: The Dynamic Brake row should probably be blanked if the locomotive doesn't have Dynamic Brakes...

Note: I forgot Brakes could be 100% - changed abbreviations for Brakes to three character labels to accommodate...



Now - the following is a result of the conversation on TS... We're not actually sitting in anything that moves - so we should have a few crutches to compensate for the lack of feelings... In my above examples - I included a new indicator on the "SPED" line of all three HUDs - an accelerometer - ideally - this should be a substitute for the feeling you get as the locomotive accelerates or decelerates... I believe this type of indicator (display a graphic) is used in the Track Monitor so theoretically it should be possible... I can do graphics for whatever is needed... The values are subject to change but the following is to give you the gist of how the indicator would work... Ultimately - for locomotives that can't calculate "Projected Speed" - - - this could be a substitute for that value - as this is information you shouldn't really know as an engineer...





The following is a similar gauge just for the Steam guys and is on the "BOLS" line of the Steam HUD example... I'd suggest we remove the current line "Steam Usage" that color codes a surplus or deficit in the existing F5 HUD - and replace it with this indicator... As someone who drives steam locomotives all the time - I really don't even notice the actual numbers for "Steam Usage" (which I shouldn't know) - as I rely strictly on the colors of the text to know if I am in a surplus or deficit condition... I've spoken with Peter before on this and I can see how this cheat makes it a bit easier to manage the boiler... Again - the values are subject to change but the following is to give you the gist of how the indicator would work... The values to drive this indicator are probably already contained in the existing F5 HUD "Steam Usage" value that changes the line color...






Yeah - I've been chew'n on this HUD thing for a while...
:)



UPDATED:

===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
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===
Rel = Release
ReQ = Release Quick
App = Apply
ApQ = Apply Quick
ApS = Apply Slow
Srv = Service
LaS = Lap Self
Lap = Lap
Run = Running
Emg = Emergency
FOT  = Front of Train
EOT  = End of Train
BP   = Brake Pipe
BC   = Brake Cylinder
EQ   = Equalized

Regards,
Scott

[ebnertra000]

Could the accererometer be a little more of a sliding scale, maybe just starting with a green square that grows into a rectangle with more acceleration? I do like the idea of the lunar...I mean light grey...color for more or less stable, and of course, red for slowing. I'm all for not making it too easy, but three circles seems a bit of a blunt instrument