[YoRyan]

Genma Saotome, on 14 July 2021 - 10:18 AM, said:

Put a GUI in front of the data file and try again.

I shall decline this, uhm, very respectfully worded request, because I'm busy with 1.4 stuff and because you've neglected to explain why this is actually a good idea.

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.

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?

[Weter]

You see, there are some different kinds of users: if one want simplicity, and that would attract them to ORTS, THE OTHER, appreciate full control, third need custom settings for some reasons, either hardware or testing/content developing, being far from programming at VB...
But how to follow the expectation of them all?
And yes: as Carlo noted, in different countries there are different standards for brakes, signaling, Safety devices...superelevation sizes
What about poll?

[cjakeman]

YoRyan, on 13 July 2021 - 06:57 PM, said:

We should take an inventory of all of the physics switches and determine whether or not they can be simplified.

Indeed, that is my aim.

Genma Saotome, on 13 July 2021 - 08:55 PM, said:

one for every existing .ACT file plus one for explore route.

Yes, I agree. But first, let's sort out the options we currently have.


So we have a consensus now for Options > Audio > MSTS Bin compatible sound

Thanks for your thoughts.


I think that's all for the Audio tab, so let's move on to the Video tab. I may need some help here as I don't know much about graphics and model building.

If we look at the first 2 controls:




The text in the Manual assumes a lot of knowledge and I wonder if it can be improved:

For Dynamic Shadows, the Manual has:

With this option it is possible to enable or disable the display of dynamic shadows. Disabling can be helpful if low frame rates are experienced

How about this instead:

The default setting is unchecked.

Check this option to cast shadows from movable objects such as trains.
Note: This may drop the frame rate, e.g. by 20%.

For Shadow for all shapes, the Manual has:

When this option is selected and also the Dynamic shadows option is selected, OR displays a shadow
also for the objects that don’t have a shadow defined in the .ref file, and also for forest trees. This may reduce game performance.

How about this instead:

The default setting is unchecked.

Check this option to cast shadows from static objects.
Note: This may drop the frame rate, e.g. by 15%.
Note: Static objects provided with shadows (in the file <route>.ref) will cast shadows anyway. This option adds shadows for other static objects.

I notice, from the manual, that the second control is not effective if the first control is unchecked. I think it would be better if the second control was indented and disabled like this pair.




What are your thoughts on this one?

[Weter]

I understand "dynamic shadows" as shadows, that follow he Sun during daytime.

How about "this affects/impacts frame rate"? How can we predict an exact percentage of frame rate drop for all kind of machines simultaneously?
As for MSTS RE, to save computing resources, there were offered to define for every shape(object), whether it will cast no shadow, a simple-formed rectangle shadow, or complex and following the Sun(which would demand continuous orientation and length computing) dynamic shadow, so route builders could set shadows of every single object manually for keeping their quantity as few as possible. As far, now we have more powerful and efficient graphical devices...
But I think, if there weak machine is present, it would better to have choise, to see static shadows from every object, or dynamic from that, which was defined to have them by the *.ref setting.

[Kapitaen13]

Weter, on 14 July 2021 - 02:32 PM, said:

.... which was defined to have them by the *.ref setting.

The entries in the .ref are completely meaningless. The German payware routes have no .ref file at all - and nothing changes in the shadows!
Decisive is only the StaticFlags in the WorldFile and this can be changed at any time without .ref.

static
none:           StaticFlags ( 00000180 )
round:          StaticFlags ( 00002180 )
rectangular:    StaticFlags ( 00004180 )
treeline:       StaticFlags ( 00008180 )
dynamic:        StaticFlags ( 00010180 )

No shadow, dyntrack + transfer + forrest  StaticFlags ( 00100000 )
rectangular StaticFlags ( 00004000 )
round       StaticFlags ( 00002000 )
dynamic     StaticFlags ( 00010000 )

Terrain No shadow StaticFlags ( 00040000 )
Terrain + dynamic StaticFlags ( 00050000 )

[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