[cjakeman]

It's been a while since I posted here, but perhaps it's time to finish off this review and then we can discuss some ideas for improvements.

The next control from the Experimental Tab is:


and the Manual entry reads:



This seems straightforward, but perhaps there should be a Tab dedicated to developers as opposed to users.

[steved]

Maybe this should default to .dds textures and only show an .ace when a .dds isn't available.

Randy

[Genma Saotome]

steved, on 06 November 2021 - 11:52 AM, said:

Maybe this should default to .dds textures and only show an .ace when a .dds isn't available.

Randy

I have not checked in a long time but when I did .dds files degraded frame rates. I threw away all my .dds files as a result. Perhaps somebody w/ such files could test .ace vs. .dds to see if the facts are different today.

This does prompt the question: is there any visual difference between the two types in OR today?

[cjakeman]

Genma Saotome, on 06 November 2021 - 02:50 PM, said:

I have not checked in a long time but when I did .dds files degraded frame rates. I threw away all my .dds files as a result. Perhaps somebody w/ such files could test .ace vs. .dds to see if the facts are different today.

This does prompt the question: is there any visual difference between the two types in OR today?

Would be nice to get an answer to Dave's questions.


In the meantime, the next control on the Experimental Tab is:



and the Manual reads:



I don't know, but I guess that the purpose of this option is to allow a player to use Kosmos environments and, if Kosmos was fully implemented in Open Rails, then this option would be unnecessary. Is that right?

I note that there is a blueprint already proposed for this by rdamurphy, so it's a shame that he didn't manage to implement it.

[cjakeman]

Moving on, I saved the first tab until last - the General Tab. The first control is:



and the Manual reads:





This looks straightforward.

It seems to me that "General" is a rather unhelpful name for the tab. Along with some other controls, this particular control would be better in a tab called "Behavior" indicating how the simulation should behave.

[cjakeman]

cjakeman, on 08 November 2021 - 12:00 PM, said:

Moving on, I saved the first tab until last - the General Tab.

The next control is Control Confirmations:




and the Manual reads:




Thanks to Ryan's changes, this setting can be changed in-game and the change is retained once the game is over.

I think perhaps it is the wrong way round. Instead of being "Suppress . . ." with the default of OFF, it should be "Show . . ." with the default of ON. Double negatives like "suppress" and "disable" are not good practice.

[cjakeman]

The next control is Map Window:






and the Manual entry is:





I think there are several issues with this option.

(The window used to open hidden behind the graphics screen, but that's been fixed.) Is there any need for this option at all? Could it be permanently enabled? We should perhaps check that it is not consuming CPU before the user opens it with Ctrl+9.

If the option is removed, then the Manual entry above will disappear too. The Map Window itself is fully explained in Section 7.5.

[Laci1959]

Quote

A következő vezérlő a Map Window:

Hello.

In Timetable mode, it is very good for unloading traffic.

Sincerely, Laci1959

[Weter]

Yes. Chris.
I have suffered some issues with it:
Before, the enter focus didn't jump from game window to map/dispatcher window completely. So, when I did something with a map window, I could change some of controls/activate exit menu occasionally. Else, zooming map out with very large routes, as Wupper express could crash the game too.

Now (since end of this spring), another problem appeared: I can turn window on by Ctrl-9, then toggle it to appear in front of game/viewer window or go behind it by Alt-Tad, but can't turn it off, until it activated again.

WRT the said option: if it doesn't consume resources, until it is being activated by Ctrl-9 and stops consume it, since we turn it off by pressing Ctrl-9 again, the option is not needed, as we do that in game.

[cjakeman]

Weter, on 05 January 2022 - 02:41 AM, said:

WRT the said option: if it doesn't consume resources, until it is being activated by Ctrl-9 and stops consume it, since we turn it off by pressing Ctrl-9 again, the option is not needed, as we do that in game.

So we agree on this then.


The next control on the General Tab is:



and the Manual text is:



LargeAddressAware is currently useful on a 64-bit OS to provide up to 4GB of memory. Although it can also be used to increase the 2GB of memory available on a 32-bit OS to 3GB, I have not heard of anyone using it in that mode.


So I would expect this control to be redundant once we have a choice of 32-bit or 64-bit Open Rails (like OR_NewYear_MG).

[Weter]

I think, single control for switching between 32/64 would be enough.
Year back, Engmod advised to me never use LAA in my w7-32 with 2GB

[cjakeman]

Weter, on 05 January 2022 - 09:54 AM, said:

I think, single control for switching between 32/64 would be enough.
Year back, Engmod advised to me never use LAA in my w7-32 with 2GB

It would be nice to have this entirely automatic, with a single Any-CPU executable so a 32-bit OS runs the executable in 32-bit mode and a 64-bit OS runs it in 64-bit mode.

[cjakeman]

Weter, on 05 January 2022 - 11:03 AM, said:

This might mean "auto-detect"?

Yes.

However, it's not Open Rails but the 64-bit O/S that checks whether an executable can be run in a 64-bit mode. If not, then the O/S runs it in a 32-bit mode.

[cjakeman]

The next control on the General Tab is:





and the Manual entry is:




I don't think the General Tab is the best location for this control, which has to do with the behavior of the train.


Currently this behavior is always applied for cars which have the appropriate parameters in the WAG file and the control turns the behavior on using default values for the other cars.

What I find interesting about this control how it fits with James' recent post about compatibility.

James Ross, on 05 January 2022 - 04:05 PM, said:

So there are three possible states for a given feature when using default values in a piece of content:

• Operational: The default values are good enough and the feature runs well
• Degraded: The default values are deliberately unrealistic but the feature is still active (and can still affect gameplay)
• Disabled: The feature is turned off entirely because no useful default values exist

According to this guideline, the control should be always on and the code should be changed to implement the most appropriate choice from the 3 above - Operational, Degraded, Disabled.

[gpz]

I think the purpose of this oprion is to save people from adding the corresponding setting to all their wag files. The option is correctly off by default, because the missing setting from the wag normally means that the car is not equipped with a retainer valve.