[Csantucci]

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

[Aldarion]

Kapitaen13, on 14 July 2021 - 11:11 PM, said:

The entries in the .ref are completely meaningless. The German payware routes have no .ref file at all - and nothing changes in the shadows!

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

[steamer_ctn]

YoRyan, on 14 July 2021 - 09:15 AM, said:

He means allowing activity creators to specify their own settings in their .act files. We've talked about this idea before, and Peter Newell wrote code for it that was accepted into the NewYear fork, but James Ross was not very sympathetic, so it was never merged into OR. I agree with him that it would be better to simplify our existing options so that such a mechanism is not necessary, rather than take control away from the player.

Weter, on 14 July 2021 - 11:08 AM, said:

Also, I disagree as well with an idea, the activity creator is able to change user's PC settings. I think he has a right only to recommend. Furthermore, what can he know about other people's machines specification?

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:

The options in the OR Menu have been discussed before.

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.

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.

[Weter]

Kapitaen13, you are right: actually *.ref-file is needed only for route editor to arrange shapes in list, so...
And Rui tells right thing too, so far, maybe initial info from *.ref about shadows is applied to the generated *.w file entries?

[Kapitaen13]

I just wanted to prevent OR from reading data from non-existent .ref files. For me personally, there are only two shadow settings: Dynamic or None.
I also have no problem with changing all StaticFlags entries in a route to Dynamic... I did that before this switch existed.

[Genma Saotome]

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.

[cjakeman]

Csantucci, on 15 July 2021 - 12:47 AM, said:

I think that declaring a percent reduction in frame rate, even if as an example, might have limited reference to reality.

Good point, Carlo. I will drop the "e.g. by 20%" parts.

Kapitaen13, on 14 July 2021 - 11:11 PM, said:

The entries in the .ref are completely meaningless. Decisive is only the StaticFlags in the WorldFile and this can be changed at any time without .ref.

Thanks, Kapitaen13. I will change the text I planned for the manual from:

defined in the .ref file

to:

defined in the World files

steamer_ctn, on 15 July 2021 - 01:36 AM, said:

I think that we can simplify the physics selection by having a Simple and Advanced mode.

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:

To provide an example, the mentioned option "Forced red at station stops" reflects two different ways real signalling systems work, so it should not be eliminated. In my country red is not forced at station stops.

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?

[Csantucci]

I never understood well the use of "Fast full-screen alt-tab". What I can say is that I have it always on, because if you set it off, the mouse looses the vertical alignment when switching from windowed mode to full screen mode. True for Testing, Unstable and ORNYMG versions. So for me this option box may disappear and the option can be always set to true, but maybe some insider knows better about the usefulness of the option.

[Weter]

I know only, that it affects the usage of dispatcher/timetable window, in some cases that usage is impossible without it, in some (or since some version, when you have introduced timetable window officially in testing versions), the focus of input was changed. The keys press stopped to affect the gameplay, (what in some cases is good, but bad In other) when this auxiliary window is active, but it became impossible to turn window off, with Ctrl-9 now, when the main (simulation) window is not active.

[jonas]

Sorry Chris, for jumping a little back again in this thread. I hope it will not disturb the systematic discussion of the individual options that is going on here right now.

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:

I only partially agree with Ryan's and Rob's proposal. To provide an example, the mentioned option "Forced red at station stops" reflects two different ways real signalling systems work, so it should not be eliminated. In my country red is not forced at station stops. ...
... 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:

...Yes, it seems to me that this feature should have been introduced as a signal or route file option. But that ship has sailed. I wonder how many people actively use this option, and under what circumstances they turn it on or off?

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

[roeter]

jonas, on 15 July 2021 - 03:57 PM, said:

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.

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

[roeter]

So far, this thread has only been about specific variables and their merit (or otherwise) to the simulation and/or to the users.
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
  
  
• 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

[Weter]

Excuse me: I nearly don't ride activities under ORTS, so would ask for clear explanation of this phenomenon.
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)

[Weter]

Yes, Robert. Unfair software vendors use such messy menus to hide settings, important for users, but unwanted for vendors to be changed. We would maintain an opposite approach, wouldn't we?
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.

[YoRyan]

steamer_ctn, on 15 July 2021 - 01:36 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.

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:

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.

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 I would like to suggest the following options tabs :

...

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:

I never understood well the use of "Fast full-screen alt-tab". What I can say is that I have it always on, because if you set it off, the mouse looses the vertical alignment when switching from windowed mode to full screen mode. True for Testing, Unstable and ORNYMG versions. So for me this option box may disappear and the option can be always set to true, but maybe some insider knows better about the usefulness of the option.

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.