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