[James Ross]

mbm_OR, on 11 October 2019 - 01:38 PM, said:

The current HUD window data is displayed using a layered window.
Your suggestion is to display the basic HUD data using a window such as the Track Monitor or Next Station.
This idea seems to be reasonable and useful.

Yes, this seems like a good improvement, although I am not sure how the extended HUD pages should fit in.

wacampbell, on 11 October 2019 - 04:12 PM, said:

I know my opinion won't be popular, but I think the supplemental F5 pages should all be removed. They were added to help program debugging of the brakes and other physics systems and should have been disabled in the distributed versions.

I would like to ensure that people driving trains do not need to use any of the extended HUD pages, but I think removing them for everyone is too much.

Possibly removing them from the Stable Version, but keeping them in the Testing and Unstable Versions would work, but that probably still forces many content creators into using a less stable version unnecessarily.

wacampbell, on 11 October 2019 - 04:12 PM, said:

My main reason for removal is to improve realism. The information on these supplemental screens are not available to real train drivers and should not be available to train drivers in the sim either. As for using the F5 screens for operations like uncoupling, or setting hand brakes, again, a real train driver cannot do this remotely from a screen. In the real world, someone has to be sent out to the car to uncouple it or do the other operations. A more realistic way to simulate this maybe using the free camera to travel to that car and then click on the coupler, or the handbrake wheel. Its just a better user interface.

I would like to redesign all the in-game screens to make it possible to have a real world-like experience, with very limited information, and would also support adding walking around to couple/uncouple cars.

I also believe there's a lot we can do between that "real world" operation and playing it as a game.

Genma Saotome, on 18 October 2019 - 11:20 AM, said:

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?

Yes, I believe the existing prototype for this was already running in its own thread. We might need to work on the way it pulls data out of the simulation into that thread, but in principal it's possible.

mbm_OR, on 19 October 2019 - 01:30 AM, said:

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.

I would like to strongly recommend that we:

• Do not introduce any new abbreviations or acronyms that are not common knowledge (even to not-very train people)
  
• Do not introduce any new options, except during testing of the feature

steamer_ctn, on 19 October 2019 - 12:57 PM, said:

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.

It would make sense to have a review of all the in-game windows soon, as I fear they're in significant need of reorganisation. For the purposes of this particular change, unless there is an obvious place to shove the multiplayer messages, I am okay to keep them in their current place.

steamer_ctn, on 19 October 2019 - 12:57 PM, said:

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

The window can call "SizeTo(width, height)" on itself and it'll change size, but it'd need to be careful not to change frequently. Variable number of lines but fixed width would probably work.

scottb613, on 21 October 2019 - 06:46 AM, said:

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

I am very happy to see everyone working together on this change, but I'd rather not have the abbreviated version. To me, it adds nothing (there's no issue with space or alignment), and means we have another option for users.

scottb613, on 21 October 2019 - 06:46 AM, said:

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

I really like this idea of highlighting things!

eolesen, on 21 October 2019 - 11:00 PM, said:

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?

It's probably not as easy as you think. :)

I would always recommend attempting to get the balance right to start with, otherwise it becomes too easy to think "the user can just change this if it's not right" and not get the defaults right.

[James Ross]

scottb613, on 22 October 2019 - 05:29 AM, said:

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

I dislike the fixed width font, it's less readable, and if the text wasn't all abbreviations (see above) it wouldn't be useful at all.

Please reconsider using a non-default font and the abbreviations.

But a huge :sign_thanks: to everyone involved so far and any that come later, this is a really productive thread.

[ebnertra000]

scottb613, on 23 October 2019 - 03:33 AM, said:

Hi...

So you're interested in more granularity or simply aesthetics ?

I could certainly make a mockup to let everyone evaluate an option but this just being a basic HUD I'm not sure more information is really needed ?

Peter also reminded me we need to consider "Geared" and "Compound" locomotives as well - I'll have to find some examples of the existing HUD for these types... If someone could post a screenshot example if they use these types regularly - it would be helpful and save me a bit of time...

FYI: I updated the above graphics with some minor changes just to make it look a little better...

Regards,
Scott

I like my granularity. I mostly drive clunky old diesels, so I obviously don't care much about asthetics

[scottb613]

James Ross, on 23 October 2019 - 11:18 AM, said:

I dislike the fixed width font, it's less readable, and if the text wasn't all abbreviations (see above) it wouldn't be useful at all.

Please reconsider using a non-default font and the abbreviations.

But a huge :sign_thanks: to everyone involved so far and any that come later, this is a really productive thread.

Hi James,

Thanks for your insights and detailed response to the topic on hand - the more input we get the better - whether it's in support of my view or opposed...

Obviously we differ a bit on opinions of what a HUD should be - I've already stated my case for getting things aligned in an orderly manner - so I'll let that lie... What I truly have a hard time understanding is unnecessarily opting to triple or quadruple the amount of screen real estate the HUD will obscure... I think many would like an option - at some point - to move the HUD's elsewhere so we have a complete and unobstructed view of the scene on hand - so in that vein - the less our existing HUD's obscure - now - the better...

That said - you guys are in the trenches every day - I'll certainly defer to the will of the ORTS Development Team and the ORTS User Community at large... Could we possibly run a survey to see which is preferred - LOL - although getting significant amounts of user input seems to be a bit difficult around here....

Thanks for all you do...

Regards,
Scott

[scottb613]

ebnertra000, on 23 October 2019 - 11:49 AM, said:

I like my granularity. I mostly drive clunky old diesels, so I obviously don't care much about asthetics

Hi "Travis" ?

OK - last night - I started working on a 10 bar segment indicator for the "Accelerometer" graphic - as an optional proof of concept - but I haven't finished it yet...

Reading James post - I don't think he supports the Accelerometer at all - so I'll hold off on spending anymore time on this until we have some type of consensus on the direction we will take...

Regards,
Scott

[scottb613]

Hi Folks,

Looking back through this thread - I think Mauricio already accomplished what James is looking for - as displayed in Carlo's post...





Regards,
Scott

[Hobo]

Could there not be options added to the " simulation " section ? Then the Simmer could add or subtract some of the specific options that he does or doesn' t use . They would be available for use at any time for those that prefer them . The basic Hud could be a simpler display but could be adjusted to fit the needs of the Simmer . The Hud would need a resizeable window for the contents .


Just a Suggestion !

[steamer_ctn]

scottb613, on 23 October 2019 - 05:05 AM, said:

I may have misunderstood "Steam Production" value - as my interpretation - is that the color coding on the "Steam Usage" represented a steam surplus or deficit ?

In a previous review of the HUD steam generation was dropped, and as a consequence the Steam Usage has no reference point and therefore is not a very useful value in the HUD.

In order to improve its usefulness, the colour coding was introduced, and indicates whether steam usage has exceeded steam production value or not.

It should be remembered that the steam locomotive is a heat engine, ie it burns coal (oil, wood, etc) to produce heat that then is ultimately converted to mechanical energy via the production of steam and the operation of the steam cylinders. Unlike a diesel this process is not instantaneous, but has delays in it. The heating of the boiler takes a finite amount of time.

The use of a steam gauge to display the operating performance of a steam locomotive is based upon older technology, and given the above explanation about heating, it will always be a "delayed action" measure.

Therefore when operating the steam locomotive I personally like to use the boiler heat as a measure to determine the performance of the locomotive. Falling heat levels take time to build back up again, and therefore under normal circumstances the locomotive can't be run flat out from scratch without the fire burning at a good rate. In a real locomotive the fireman compensates for this by "looking" ahead and building the fire up as necessary. Sadly the AI fireman can't do ESP, and therefore this doesn't happen with him. To see info about a "crude" look ahead feature provided for the AI Fireman, see this post. Using the Manual fireman should also overcome this issue.

So given the fact that our goal is to reduce the information in the Train HUD to types of controls and gauges that the driver would have available to him, I suggest that Steam Usage be removed from the HUD, and that only Boiler Pressure be used, with the proviso that the text color change based upon a "mode" effect that is linked to heat balance. Thus if the heat balance in the boiler is at the correct point then the text would be say white, if dropping below normal then another color, if rising above normal then a different color. To see the effect of driving by the heat balance look at the Extended HUD figures under Steam Production.

Quote

That said - Peter had stated he requested help from the community for testing - to address hand firing - but no help was offered so the subject was dropped - and rightly so... We can't thank these ORTS developers enough for the herculean efforts they donate to our cause - so who could fault them when their requests for help go unanswered ?

The offer is still open to somebody who wishes to put the necessary effort in.

[scottb613]

Hi Peter,

Once again - thank you for your valuable insights and all you've done with our steam model...

I think we're on the same page - the "color" of Steam Usage is important but the actual number value is not...

I'm assuming the values Mauricio would need would be available if/when he gets some time to look at this portion of the HUD...


If it's an open ended offer to work - Hand Firing - I'll ping you when I get some free time and maybe we could work out a mutually agreed upon time to take another peek... As always - my actual time in front of the sim is severely limited and only on weekends... I get plenty of time to talk about it though - LOL...

Rick - here's your chance as well !!!

:sign_thanks:


Regards,
Scott

[rickloader]

I don`t like to disagree with a respected developer, but I think the goal of a HUD is not " to reduce the information in the train HUD to types of controls and gauges the driver would have available to him". Rather it should be to provide essential information that the sim otherwise fails to provide. As the Ai fireman cheats, a simplified steam balance display maybe ok for the majority of users in AI firing mode.
Manual firing is a different matter, and at a minimum the present CTRL F HUD needs to be retained ; even supplemented.. Perhaps steam production + consumption would help. But even driving in the full HUD and monitoring Boiler heat can`t avoid the soaring and plunging boiler pressure cycle
Manual firing cannot easily be adapted to changing steam demand on the road. This is because of lack of information, and some dubious loco physics. 2 examples
1) Park a loco, having run down the fire in anticipation to about 60% With dampers and blower closed, injectors off . it will take many minutes for steam production to reduce, and it will never balance. The blowing off will cycle even stationary because there is always a surplus
2) Anticipating a 3 min station stop, you close the dampers and blower, and run down the fire and water level. At the stop you put on the injector. Despite this, the safety valves lift just before departure, boiler pressure plummets, and you struggle to restart the train..
At a guess the blast needs to have greater effect so that with regulator shut, the fire heat dies down more quickly.
Apologies for diverting this thread, but then again , coders need to know users requirements.
Regarding Peter and Scotts comments about lack of community help. It is very difficult for non- programmers to contribute, because much of steam physics is hard coded, and we have no access or idea what the sim is even intended to do. The original programmer is long gone, and probably intended to develop the steam model further. I don`t mean to be negative, but am just promoting an admittedly minority view
rick
Edit. Crossed post with Scott. Yes I would like to help if I can. I`m not a physics expert, nor a real loco expert, and certainly not a coder. But I would like to contribute, because I know that manual firing can be very rewarding.