[steamer_ctn]

OR has many option settings that users can select. Whilst this can be good to allow the user to tune the operation of OR to their desire, I have noticed lately that a number of users have had problems getting activities to run trouble free. Upon researching this issue, it appears that most problems arise when the activity creator uses different option settings to the user. Some good examples appear to be with signals that will not clear unless some of the " Activity Options" switches on the Simulation TAB are set the same.

This leads to frustration on the part of the user who often cannot achieve the designed activity outcome. It also causes the creator frustration as they try and work out why the activity does not run as originally designed.

I believe that the best way to fix this issue is to allow the activity creator to set the option settings for their activity, and when OR runs the activity, it uses these settings in preference to whatever the user has set.

I am thinking that an INCLUDE type file should be used, as per the current practice in other areas, to facilitate the identification of options to be set. These options would only apply for the duration of the activity and would not change the users option settings when they run other content besides the activity.

Is there general support for an approach as outlined?

Thanks

[dforrest]

I certainly support this.

[mrmosky]

Sounds like a sensible way to go.

Geoff

[RR1]

As long as the include file clearly indicates the options that are being over-ridden, then I think this is a great idea. Perhaps also there could/should be a way to clearly flag the fact that a particular activity has set option over-rides?

[Woodfyr]

AFAIAC, the author should include 'Options Set' as part of the published activity in the "Read Me" file.

Oh! --- I Forgot. Most people don't read the "Read Me" file before starting the activity. :ermm: :sign_oops:

[R H Steele]

Woodfyr, on 02 April 2019 - 06:45 AM, said:

AFAIAC, the author should include 'Options Set' as part of the published activity in the "Read Me" file.

Oh! --- I Forgot. Most people don't read the "Read Me" file before starting the activity. :ermm: :sign_oops:

Re: steamer's proposal and also woodfyr - both good ideas, don't worry about the people who don't want to read...apologies if that sounds discriminating....people should understand the advantages of being informed...even about something as simple as running an activity. ( if they would only read the manual!!)

Also adding something I've been suggesting for ages...route/activity specific options could be added to this include idea. For instance my options/settings for the PRR East route are quite different from the ones I use for Paul Charlands FG&J.

[copperpen]

I use one setting for all routes so for another person to have control over my route settings is a no go area for me. I have no quarrel with an include for the two Activity settings for AI switching and red sig at station stop because I always have them on. As for the other two options, I never use autopilot and AI train doors is eyecandy.

[dforrest]

I assume that the current system settings would be automatically saved before starting the activity makes the charges, and that these will be automatically replaced when the activity session completes. Am I correct?

[longiron]

Can someone put together a list of the parameters that would be subject to INCLUDE modification, and which ones would not?

[Genma Saotome]

R H Steele, on 02 April 2019 - 08:29 AM, said:

Also adding something I've been suggesting for ages...route/activity specific options could be added to this include idea. For instance my options/settings for the PRR East route are quite different from the ones I use for Paul Charlands FG&J.

Indeed. Many of the options are not about your hardware of specific installation of OR... instead they are all about what you want for specific routes... and in some cases what you want for specific activities.

The primary reason they are where they are is by coding them you can completely control the range of values each option will produce. That minimizes the probability some user will mistype a value that won't work and report it as a (hard to track down) bug in the software. Given everybody who codes for OR is a volunteer the idea of minimizing wild-goose chases to the greatest degree possible IS a legitimate goal.

Which leaves us with conflicting objectives.

I think the conflict can be resolved as follows: Modify the code for the various options so they produce a flat file, perhaps as a binary object, that will be read and used exactly as it is today. Then design the means whereby the same file structure can be placed in individual routes, only this time the user specifies which route. All the choices remain as before, the output file remains as before. The difference is (1) the file is now in any route instead of only the OR installation and (2) the work process includes some means for the user to say which route and there is a function to put it there. At some future date the idea can be extended to activities.

Last, the software needs to check the routes home folder for the options file, use it if found, or if missing, use the one in the OR folder.

By this means the OR team still has complete control over the values going into Run_Activity.exe -- and nothing of how the actual values are used by the OR code needs to be changed -- while end users gain the ability to set options on a route by route basis and in due time, in activities as well.