[Klaus]

Hallo!

Removing the options (Remove Train lights setting and always enable it., Remove Precipitation setting, Enable MSTS Bin compatible sound and perhaps soon others) from the dialog is OK But the values should not be hardcoded. At least they should remain in the registry entry.


But I have another suggestion in connection with the "relaunch" of the options:

The options are saved in the registry (HKEY_CURRENT_USER\Software\OpenRails) and are therefor global for all routes.

I would find it quit fascinating (e.g. for route-builders) to override this options for single routes.

Two Examples:

(1)

I have here the problem, that distant mountains and forests are not exactly dispayed in a view routes. Reducing the value for "distantmountains.viewing distance (km)" is resolving the problem (http://www.elvastower.com/forums/index.php?/topic/23268-problems-with-distant-mountains/).

(2) Some routes as tramroutes require one wire overhead, others double overhead wires)

The solution could be a configfile (e.g. in XML format or in the old INI-format) in the route folder. In absence of this file the default values of the registry are used otherwise the routespecic values.


Is there a chance to implement this behaviour?




Cheers

Klaus

[James Ross]

Klaus, on 12 January 2014 - 04:51 AM, said:

I would find it quit fascinating (e.g. for route-builders) to override this options for single routes.

You really don't want that; you want OR to always support train lights, overhead wire, etc., but the route or section of track will control what it wants drawn within that. None of these affect performance either (that's been tested).

The removed options will not remain in the registry as there's simply no good reason for them.

[James Ross]

Done in X1980.

I also wonder if people would object to changing the 'Overhead wire' setting to 'on' by default. (Clearly people didn't want it removed.)

[Csantucci]

I'm in favour of that.

[Genma Saotome]

James Ross, on 01 February 2014 - 04:19 AM, said:

Done in X1980.

I also wonder if people would object to changing the 'Overhead wire' setting to 'on' by default. (Clearly people didn't want it removed.)

Whatever happens, please be sure to allow the use of electric locomotives to operate alongside diesel or steam locomotives w/o regard to whether overhead wires are or are not procedurally produced (this would occur in a mixed technology route). I have a couple short segments of overhead wire track in two otherwise steam/diesel routes -- with my own overhead wire shapes included -- and it's been a delight operating on those tracks in OR, something MSTS would not allow.

In the long run, wouldn't GenerateOverheadWire( Y|N) be a data attribute set in the world file on a "segment by segment" basis?

[rdamurphy]

I think anytime we can move anything off the Experimental Tab it's a good thing...

As far as the "show overhead wire" you may want to keep it. There are routes with manually added highly detailed modelled wire objects that replace the default, which is why the wire needs to "disappear". I believe there's even a set of track pieces with overhead wire as part of them.

Robert

[James Ross]

rdamurphy, on 04 February 2014 - 07:10 AM, said:

As far as the "show overhead wire" you may want to keep it. There are routes with manually added highly detailed modelled wire objects that replace the default, which is why the wire needs to "disappear". I believe there's even a set of track pieces with overhead wire as part of them.

They should be using the existing, well-known MSTS 'trick' of setting the height of the wire to a silly value, so don't count.

[James Ross]

Walter Conklin, on 04 February 2014 - 07:26 AM, said:

I wonder how removing the "show wire option" in the Experimental tab would impact, if any effect, routes built with Catenary Master and Hide Wire?

The overhead wire option being discussed is on the 'Video' tab. There is an experimental option that controls what type of wire is used. If you have an example that renders poorly with the former option selected, please say.

[markus_GE]

Actually, I think Superelevation and Distant Mountain control features could be moved from the experimental tab to the Simulation and Video tabs.

There haven´t been any problems with these features for a long time, at least of what I have seen (or better, not seen - as it seems as if nothing has been reported).

Just a suggestion, though.

Cheers, Markus

[James Ross]

markus_GE, on 04 February 2014 - 08:33 AM, said:

Actually, I think Superelevation and Distant Mountain control features could be moved from the experimental tab to the Simulation and Video tabs.

There haven´t been any problems with these features for a long time, at least of what I have seen (or better, not seen - as it seems as if nothing has been reported).

I'd agree with you on distant mountains, but personally would keep superelevation on experimental - not least because it infers/guesses a load of data that needs manual correction for some routes. We should certainly have a clean-out of all options before 1.0 though. :)