Menu Options Can we simplify them?
#16
Posted 15 July 2021 - 12:47 AM
I think that declaring a percent reduction in frame rate, even if as an example, might have limited reference to reality, as it depends from the type of computer (in my old computer reduction is probably quite higher than 20%), and it depends also from other parameters defined, as e.g. the "Automatically tune settings to keep performance level" option (which flattens the frame rate on performing computers) or the Viewing Distance option.
#17
Posted 15 July 2021 - 01:18 AM
Kapitaen13, on 14 July 2021 - 11:11 PM, said:
I do not agree with it at all.
Entries in ref file are meaningfull. You had to have a ref file in order to place objects in old RE, and that's were shadow information was defined. The ref file was taken, probably just before shiping out in order to prevent route editing in RE. I also used to do that. But ref shadow information must be meaningfull, otherwise how did RE, or even TSRE5 for that matter, know what static flag to aplly...
#18
Posted 15 July 2021 - 01:36 AM
YoRyan, on 14 July 2021 - 09:15 AM, said:
Weter, on 14 July 2021 - 11:08 AM, said:
The proposed concept was not about changing machine specifications, etc.
It was about allowing a activity creator to set up the best operational environment for their activity to work correctly. For example, if an activity required the "Forced red at station stops" option to be selected to work correctly, then the activity creator could (pre)set it whenever his activity is run. Otherwise at the moment we get people saying, "This activity" doesn't work". Typically then to assist them takes time and effort, and often it is finally identified that their system (options) are not the same as the activity creator used.
cjakeman, on 13 July 2021 - 10:32 AM, said:
I think that we need to set a "vision" for OR and then asses each of the options against this vision. Otherwise we will go down the same path that we have always seem to go down.
So as an example, looking at the physics, I think that we need to define two "standard" use cases (or options), and then merge the physics switches into each of these cases.
I think that we can simplify the physics selection by having a Simple and Advanced mode as follows.
Advanced Mode - enables all physics to apply to train operation. This mode is aimed at a serious user who wishes to run trains as realistically as possible. The majority of the advanced options would go into this mode.
Simple Mode - provides very basic physics. This mode is more aimed at the user who wants to see a train run, but doesn't care whether it operates in a realistic fashion. This mode can also be used to do some level of debugging. So few physics options would go into this mode.
So lets work out where we want to get to, and then what we need to do to get there.
We need to do a similar exercise with other areas within OR.
#19
Posted 15 July 2021 - 08:04 AM
And Rui tells right thing too, so far, maybe initial info from *.ref about shadows is applied to the generated *.w file entries?
#20
Posted 15 July 2021 - 09:25 AM
I also have no problem with changing all StaticFlags entries in a route to Dynamic... I did that before this switch existed.
#21
Posted 15 July 2021 - 10:34 AM
steamer_ctn, on 15 July 2021 - 01:36 AM, said:
Sadly we seem to always end up at the same point, ie somebody likes each one of the options, and therefore they say that they shouldn't be removed.
IMO this problem can be solved rather easily as follows:
Global Level -- Required.
Content folder (e.g., where /Routes is found) -- Optional
Route folder (e.g., where *.trk is found) -- Optional, file is named for the route
\Activity folder (e.g., where *.ACT is found) -- Optional, file is named for the Activity
The game software starts looking at the bottom of that hierarchy. If the options file is found, use it. If not, go up one level and repeat. If no options files are found, use the global settings. None of the extant options do not need to be depreciated in this approach and I think Chris' ideas about doing a better job explaining what there are -- in the GUI -- is a good idea.
In this way the global settings are the default and as such would be used in most cases. Having the other locations available allows for as-needed customization. It might turn out that only a few routes get options files, and a handful of activities. But right now each of those requires fiddling at the global level and remembering to reset them that to previous values when done. That;s a PITA.
My comment earlier about a GUI is not one I particularly favor but it would provide a firewall against typos, crazy values, and outright stupidity.
postscript added later: FWIW I recommend the same approach to whatever camfig solution is implemented, On one route I work on there are activities that almost require the monitor be in portrait mode. Sine that is not always possible the range of camera movements would need adjustment to being not very far from teh train but having a large range of vertical movement, a need that is rather unlikely in most routes.
#22
Posted 15 July 2021 - 10:51 AM
Csantucci, on 15 July 2021 - 12:47 AM, said:
Good point, Carlo. I will drop the "e.g. by 20%" parts.
Kapitaen13, on 14 July 2021 - 11:11 PM, said:
Thanks, Kapitaen13. I will change the text I planned for the manual from:
steamer_ctn, on 15 July 2021 - 01:36 AM, said:
I agree, Peter, but at this stage I need first to work through the options to identify what they actually do and why (and whether) we need them.
Csantucci, on 14 July 2021 - 10:32 AM, said:
Thanks for that comment, Carlo. We might need more detail when we return to it later on.
What about this next control in the Visual tab?

What does it do? Do we still need this? If so, can it be automatic?
#23
Posted 15 July 2021 - 12:28 PM
#24
Posted 15 July 2021 - 01:14 PM
#25
Posted 15 July 2021 - 03:57 PM
It's about the option "Forced red at station stops".
I see it similar to Carlo here:
Csantucci, on 14 July 2021 - 10:32 AM, said:
... And in any case the selection whether some features are included or not should not be automatic.
and Ryan asks:
YoRyan, on 14 July 2021 - 11:33 AM, said:
Thats why I would like to mention an example from my practice in creating activities.
I created an activity where the player train is followed by a short freight train at signal spacing. The player train enters a station and makes the passenger change. The following freight train also enters the station and stops on a track next to the player train in front of its red signal.
This is the activity as it works in MSTS.
In OR it works the same way, unless the option "Forced red at station stops" is selected. Then the activity behaves completely different!
The player train now has to wait in front of its red signal after completed the passenger change, because the freight train had already occupy the track ahead the player train and simply overtakes the player train. The player train now has to wait until the freight train has reached the next station (the next signal).
I give in the manual to this activity the hint to the player, that he must switch off the option "Forced red at station stops" in OR explicitly, because otherwise the activity does not work correctly.
What I mean to say is that I really appreciate the ability to turn the "Forced red at station stops" option on and off individually here! It probably would have taken me much longer to get to the "bug" if this option had been "hidden" in a general and/or automatic setting.
So, at least for the "Forced red at station stops" option, I'm in favor of it remaining separate.
Greetings
Jonas
#26
Posted 16 July 2021 - 01:12 AM
jonas, on 15 July 2021 - 03:57 PM, said:
This example shows exactly why this option should never have been a menu option, but should have been introduced as an activity option right from the start. It is confusing, and not very user friendly, that a user must always check the activity manual to find out how to set this option (and some others) for the activity to work correctly, even when still running the same route but just starting a different activity. And to make it more confusing, not all activities do spell this out in the manual, either. The many forum posts about failing activities due to the settings of these options, on this forum and on trainsim, are clear proof of this.
This whole poor situation has come about due to the paradox of, on the one hand, introducting new functionality whilst, on the other hand, requiring strict compatibility with MSTS for file contents and structure.
But the time of this strict compatibility is now behind us. Not only are there quite a number of examples where compatibility no longer is maintained (e.g. engine file settings for smoke, brakes and some physics - original MSTS settings work poorly or not at all), there are also several file definition options to allow additional definitions (e.g. include files).
So, in my view, if we are looking at improving the menu structure, than it is about time that these options were moved to where they belong - which is the activity definition.
Regards,
Rob Roeterdink
#27
Posted 16 July 2021 - 01:55 AM
However, I feel that the structure of the menu is just as important an issue. A proper menu structure will help to understand the scope of options, and will also help to understand the relation between these options.
The present menu structure is, at best, untidy and, at worst, just a mess.
Untidy : there do not seem to be proper definitions of the scope of the various tabs, and of the context of the options on these tabs.
There is a 'general' tab and there is a 'simulation' tab. But why, for instance, is the option 'Graduated release airbrakes' on the 'general' tab, but the option 'break couplers' is on the simulation tab? This is just one example, but this question is valid for many of the options on the 'general' tab.
But that's the best part of the menu. At the other end of the scale is the 'Experimental' tab. This is just a mess. If covers all sorts of functions, completely unrelated. Many options have been around for so long it is hard to remember ever running OR without them, yet they are still qualified as 'experimental'. This tab should be removed, and all options should be relocated to the proper tab related to the function of the option.
Clearing out the menu structure and placing the options on tabs with proper context will help to understand the context and scope of the options, and will also show more clearly the relation between various options.
So I would like to suggest the following options tabs :
- General
Real general options only, e.g. language selection. - Audio
Options related to audio settings, but technical options only. - Video
Options related to video settings, but technical options only (e.g. window size). NOT simulation display options. - Simulation
Options related to behaviour, control and output of the simulation, but only those options which apply to all modes (activity mode and timetable mode).
There are probably too many to place on a single tab, so, for instance, these sub-tabs would be defined:
- Display
- Physics
- Command&Control
- Display
- Activity
All options restricted to activity mode only. Perhaps sub-tabs are required if not all options can be set on a single tab. - Timetable
All options restricted to timetable mode only. There are none such options at present, but let's be prepared for what might come. - Keyboard
As is. - Data Logger
As is. - Evaluation
As is. - Content
As is. - Updater
As is.
So, there no longer is an 'experimental' tab. If it is deemed essential to identify an option as experimental, this can be done by placing a red box around this option, with the text 'experimental' displayed in the boundary of that box. But by placing that option on the proper tab it is immediately clear what the context of that option is. Also, promoting an option from experimental to standard is made much more easy - just remove the red box. Presently, such a promotion requires rewriting half the menu.
Regards,
Rob Roeterdink
#28
Posted 16 July 2021 - 02:03 AM
Do I understand it right: when this box is checked, the next signal after platform is forced to show red(most restricting) aspect, while the stop time of the train comes.
In Jonas's example, this causes lifting of next block-section reservation for this train, so it becomes free for occupation by the second train, which is at the non-platform siding at that time, so it departs to stratch, as the time of stop is not defined for sidings, and more, exit signals from sidings are not forced to close by that option.
And we see, that the second train overtakes the first one, instead of following it, as it was designed by an author of activity, because checked option of ORTS menu.
Is this right?
If so, I have a second question to ask: what the reason(s), this option was introduced for?
At timetable concept, similar option can be defined for particular train(s) only when and if it really needed.
And even more: it can be clearly defined for given train, that it MUST follow one, or all trains in given route section, regardless of signaling logic. (Then lower priority applying works instead of signal logic as primary measure to control this train behavior)
#29
Posted 16 July 2021 - 02:55 AM
Obvious, one new option don't worth to have a separate tab, so we see an "experimental" tab for them all, but as the development goes on, the tabs structure is subject to be adjusted. Opposite preference is wish to have as less tabs, as possible.
But I don't believe to agree with your offer to drop-off experimental tab, as its idea, as I understand it, is contain all options, that are not all-aspect tested yet, or that require to decide, is it better to include them to ORTS logic as permanently-on, as an option, or develop them further. For testing versions wide-auditory testing and discussion, after ensuring, that they are at least work as intended and not spoil the process in unstable releases.
But it's clear for me, that the menu's structure must be revised, say, to 1,4 version's release. Particularly, the experimental tab should be revised regularly.
As well, I welcome you idea to separate technical settings for video and audio (maybe place them both as sub-tabs of common hardware-related tab?)
Well, marking a new-introduced options as experimental in corresponding tab...and what if later, them will be declined, or removed as permanently-on or reworked?
I prefer the look of options tabs to be as stable, as it can be, for not to search for a long time the new features every new release published.
#30
Posted 16 July 2021 - 10:59 AM
steamer_ctn, on 15 July 2021 - 01:36 AM, said:
So as an example, looking at the physics, I think that we need to define two "standard" use cases (or options), and then merge the physics switches into each of these cases.
I think that we can simplify the physics selection by having a Simple and Advanced mode as follows.
Yes, this 100%. We need to reevaluate all of the cruft we've accumulated over the years.
roeter, on 16 July 2021 - 01:12 AM, said:
I caution that we have to be very careful when introducing options into the content formats, because doing so requires us to maintain support for them indefinitely. I can see the merits of moving "forced red at station stops" into the activity or route file, but I am not so sure about the rest of the physics options, and I would certainly not support enshrining anything that currently resides in the Experimental tab.
roeter, on 16 July 2021 - 01:55 AM, said:
...
So, there no longer is an 'experimental' tab. If it is deemed essential to identify an option as experimental, this can be done by placing a red box around this option, with the text 'experimental' displayed in the boundary of that box. But by placing that option on the proper tab it is immediately clear what the context of that option is. Also, promoting an option from experimental to standard is made much more easy - just remove the red box. Presently, such a promotion requires rewriting half the menu.
Yes, I'm fully on board with this proposal.
Csantucci, on 15 July 2021 - 12:28 PM, said:
During the Monogame migration, James explained its purpose to me: Unchecking this box instructions Monogame to run in exclusive fullscreen mode, which slightly increases performance at the cost of slower switching to and from the Windows desktop. The difference is barely perceptible on modern hardware, but it amounts to a supposedly useful gain on older machines.