[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

[scottb613]

ebnertra000, on 22 October 2019 - 06:09 AM, said:

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

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

[rickloader]

Hi Scott, i very much welcome the steam production / usage.
I always drive in manual firing mode, and at the moment in F5/ctrl F we only have Steam Usage. There is no steam production info. This lack of info makes it nearly impossible to run a train just below max boiler pressure. Once the safety valves open, boiler pressure plummets, and then recovers to start the whole
cycle again. I realise this delay is inherrent in the steam loco, having a huge store of heat energy. A real life fireman can gauge steam production from the state of the fire, but in game you need steam production info.
A bit off topic, but I think the dampers, and injectors don`t have much effect on steam production in game. It should be possible to avoid blowing off steam by putting an injector on. I`ve tried looking at the figures on the full HUD, but it is very hard to monitor the vital figures. A steam production/ usage dispay would be a great step forward
thanks, rick

[scottb613]

rickloader, on 23 October 2019 - 04:12 AM, said:

Hi Scott, i very much welcome the steam production / usage.
I always drive in manual firing mode, and at the moment in F5/ctrl F we only have Steam Usage. There is no steam production info. This lack of info makes it nearly impossible to run a train just below max boiler pressure. Once the safety valves open, boiler pressure plummets, and then recovers to start the whole
cycle again. I realise this delay is inherrent in the steam loco, having a huge store of heat energy. A real life fireman can gauge steam production from the state of the fire, but in game you need steam production info.
A bit off topic, but I think the dampers, and injectors don`t have much effect on steam production in game. It should be possible to avoid blowing off steam by putting an injector on. I`ve tried looking at the figures on the full HUD, but it is very hard to monitor the vital figures. A steam production/ usage dispay would be a great step forward
thanks, rick

Hi Rick,

Yeah - I used to handfire quite a bit in MSTS - for me - it doesn't seem to work as well in ORTS therefore I haven't used it...

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 ? Whether it is or isn't - the text color is what I use to manage the boiler with the automatic fireman - as boiler pressure doesn't seem as "usable" as it was in MSTS...

I'll need to add an example with the hand firing parameters when I get a chance...

<OFF TOPIC>

Quote

I believe the design goals of the existing ORTS steam model - was to simplify it a bit for the masses and to only incorporate documentable facts - so modelers didn't need 500 parameters and to sacrifice some chickens under the light of a full moon - to properly define the steam physics of a locomotive... While ORTS seems to have accomplished this goal - it also means that we've lost a great deal of ability to customize an individual locomotive to our specific needs and manage the myriad of configurations MSTS seemed to address better... Personally - I'm not sure I fully agree with this philosophy... On my latest project I spent countless hours trying to replicate what I had in MSTS - with an ORTS physics file - and to me it still feels a bit simplified or dumbed down... There are very few parameters at our disposal to modify - as much of the physics work is hard coded in the sim therefore unavailable for modification...

We REALLY need the ability to modify the injectors - railroads spent a great deal of money on feedwater heaters - they were there for a reason - they were needed...

When attempting to hand fire my ORTS project - the boiler pressure seems to always be maxed - like you - blowing the relief valves - or - in an uncontrollable death spiral that can't be recovered from - there is no middle ground... I can't - for instance - run at a reduced pressure if you know a stop is coming up or you're getting ready to crest a hill and you won't need all that steam... Trying to manage the boiler from "Boiler Pressure" - as done in the real world or MSTS - seems impossible... In MSTS - we could vary the quality of the fire - none of our controls (dampers, blower, firebox door, fuel feed rate) seem to have any effect in ORTS... In MSTS - you could set how much of an impact each injector had on steam production (simulating feedwater heaters or lack thereof) in ORTS the values are hardcoded and have very little effect on steam production (no water strategy necessary)... In MSTS - it took real skill and effort to keep steam production where it needed to be - managing the fire - controlling how and when you added water - working with the engineer on how hard he could drive the locomotive in order to conserve precious steam - those days seem to have passed... In MSTS - starting a long hill grind without having high water levels in the boiler - demanding maximum effort of the locomotive - exceeding your feedwater heaters capacity to maintain water levels in the boiler - then having to resort to "cold" water from the second injector to avoid melting plugs - was a surefire recipe to stall out on the hill from lack of steam... LOL - I've melted plenty of plugs when I couldn't keep enough water in the boiler because I wasn't driving/firing intelligently and efficiently... Tunnels used to be deadly if you opened the firebox door in one - LOL - not sure if we need to resuscitate this feature...

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 ?

I don't know - perhaps the hand firing crowd is such a small percentage of us (a niche within a niche within a niche) we've reached a point of diminishing returns on the effort it would take to code this properly ? The above is why I stopped hand firing - relegating it to Mr. Auto...

<END OFF TOPIC>

Regards,
Scott

[Kazareh]

I like this, honestly!!! Think it's definitely far since time to update the old ASCII F5 hud from MSTS and all. Would love to see this implemented for sure as the ORTS Standard!!!

[scottb613]

Kazareh, on 23 October 2019 - 05:46 AM, said:

I like this, honestly!!! Think it's definitely far since time to update the old ASCII F5 hud from MSTS and all. Would love to see this implemented for sure as the ORTS Standard!!!

Hi...

Thanks for the feedback - nice to know we're on the right track...
:)

Regards,
Scott

[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