F5 HUD scrolling.
#21
Posted 17 October 2019 - 06:02 PM
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 !
#22
Posted 18 October 2019 - 08:38 AM
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.
#23
Posted 18 October 2019 - 09:08 AM
steamer_ctn, on 17 October 2019 - 12:36 PM, said:
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:
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:
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
#24
Posted 18 October 2019 - 11:20 AM
scottb613, on 18 October 2019 - 09:08 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?
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.
#25
Posted 19 October 2019 - 01:30 AM
Quote
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:
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
#26
Posted 19 October 2019 - 06:58 AM
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
#27
Posted 19 October 2019 - 07:58 AM
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
#28
Posted 19 October 2019 - 12:57 PM
scottb613, on 19 October 2019 - 06:58 AM, 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.
Also would it be possible to size the window based upon the information needing to be displayed?
#29
Posted 21 October 2019 - 06:46 AM
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
#30
Posted 21 October 2019 - 08:13 AM
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