[cjakeman]

 Genma Saotome, on 15 August 2021 - 10:21 AM, said:

The data has always had two purposes -- adjusting what you will or will not see when you run the sim as well as sorting the entries in world files. For sorting purposes 10 values has always been too few and while most of the higher values are used for tools -- temporary push pins, signs, rulers, etc -- having more to work with allows us to spread out the sorting for real stuff such that real stuff is being assigned values >10 and that means as-is we can't see stuff that should be displayed.

For the sake of guidance in the Manual, is there any consensus on the value that separates real stuff from building tools?

[Genma Saotome]

 cjakeman, on 16 August 2021 - 07:22 AM, said:

For the sake of guidance in the Manual, is there any consensus on the value that separates real stuff from building tools?

Probably not. It's entirely a route builder feature and so each person that uses the feature will have their own ideas of what to do with it. Best thing for the manual would be to tell people to review the readme for the route to see what particular value, if any, to set when running the sim so as to block certain classes of objects.

[cjakeman]

OK.

Thanks, Dave.

[cjakeman]

Moving on once more, the next tab to consider is the Updater.




I don't have any argument with this control, but I do think the 4 radio buttons could be condensed into a single drop-down. The explanatory text would stay but become dynamic, changing with the selection.

The control could then fit into one of the other tabs.

My aim here is just to reduce the number of tabs, so that the Options are not so intimidating.

[cjakeman]

 Genma Saotome, on 16 August 2021 - 09:53 AM, said:

Probably not. It's entirely a route builder feature and so each person that uses the feature will have their own ideas of what to do with it. Best thing for the manual would be to tell people to review the readme for the route to see what particular value, if any, to set when running the sim so as to block certain classes of objects.

Can we discuss this control some more?

If I understand it correctly, legacy content uses categories 0 to 10 and a user with a high-spec PC will want it set to 10 to see all the detail and a user with a low-spec PC might drop it all the way down to 0 for higher frame rates.

For content builders who have made use of categories above 10, there will be a value in the route documentation advising the highest category which provides player content. Higher categories may be used for tools used in laying out content.

In this scenario, what should Open Rails provide as a default value to someone who has installed a new route? If 10, then some content will be missing unless they read the documentation. Also, a user may need different values for different routes.

Can we come up with a scheme that provides a suitable route-specific default and still allows the user of a low-spec PC to override that? (This is a discussion; not a commitment to implement such a scheme :-)

[Genma Saotome]

The burden to inform end users should be on the person who made/changed the route, not on the OR team.

In that view the correct default would be 99. For the manual one might toss in the observation that the traditional value was 10 and that few people found the need to lower it but new routes may use higher values. And repeating myself from earlier, end users installing a route should check the readme to ascertain if there is any need to lower the default value to suppress developer aids present in the route.

This is an issue that is relevant to releasing multiple, incomplete versions of a route. The Monon route had 18 versions released. AFAIK he didn't make use of temporary placements or tools but if he had pulling them all out with each release would have been a burden.

Similarly any testing volunteers may need to turn off the display of certain things, maybe many things, so as to see clearly what needs to be assessed. As I expressed earlier both Eric and will be using more than 10 values and it seems reasonable that the in game limiter be tweaked as a result.

[cjakeman]

There are lots of options on the Experimental tab. We have agreement earlier in this thread that the existing options on this tab should move elsewhere and a proposal has been made for managing experimental options in future.




Default values are unchecked, 50 ms and 1435 mms


The Manual has:





I note that the document is described as DOCM but is now distributed as PDF.

I'm hoping this option is not controversial.

In an ideal world, should these settings be route-specific?

[Laci1959]

Hello.

Yes. The overhang of a curve with a defined radius is different for tracks BUILT to 160km / h, BUILT to 80km / h, BUILT to 40km / h. For the latter, this can be zero. in a Route, all three can occur.
First picture, tired poor, and fell down to rest.

https://kephost.net/p/2021/33/5728_28ddb8eddf26.jpg

https://kephost.net/p/2021/33/4458_770cf9816f37.jpg

https://kephost.net/p/2021/33/5426_f9deecee609f.jpg

Some pictures from users. I think a minimum length of 100 to 130 meters would be the minimum value.

[copperpen]

Until we have proper OR specific routes that are able to show super-elevation without the current visual track problems this should remain user specific. I dont use it because of the ugly visual effects caused by it on MSTS routes.

[R H Steele]

I wish many of these options --- and super elevation is one --- could be saved for certain routes...made route specific if you will....it really comes down to a checklist of options to remember to set for certain routes, forget something, and restart the activity or timetable. Apologies, I know this is not on point...but thought I'd mention it again.