Hi guys,
after quickly skimming through the old thread Chris linked and thoroughly considering this one, I need to share some thoughts as well.
steamer_ctn, on 30 April 2020 - 02:31 PM, said:
[snip]
Hence I suspect that the extra effort required by the user to manage the settings for different activities will act as a deterrent to either running the activity at all, or correctly.
The proposed coding already submitted overcame the above issues by applying the required settings for the duration of the activity only, and they would then revert back to the users settings the next time that OR was run. Hence the user is not expected to do anything but run the activity.
I agree with Peter that the proposal in the opening post is impractical due to the reasons mentioned and that any changes specific to an activity should never persist for anything else aside from the activity / activities they apply to. Also, things need to be as little of a hassle as possible for the user while still "somehow" allowing them to select at least which "set" of options to use - his own or the content-specific one.
James Ross, on 01 May 2020 - 02:29 PM, said:
[snip]
I do not think this should be done in isolation, though, as this whole debate has shown just how messy the current options are. There are things which should be consist, engine, or wagon set; things which should be route set; things which should be activity set; things which should be combinations of them all. And we may be missing the ability to set things for timetables entirely.
I would really like to see us do
all of the following:
- Completely remove any options we can (e.g. autopilot) - this benefits everyone
- Move any options we can into consist, wagon/engine, route, and activity files - removing the option from the user's control
- Separate all remaining options that can be overridden from those that can't in the Options dialog (either a separate tab, or a separate group on each tab, depending how many)
- Add an in-game prompt that lists all settings being overridden and their respective values
My big worry right now is that if we jump straight to implementing step 4, we'll never bother with steps 1-3 and things will continue to be a lot worse than they could be (e.g. activities would need to constantly override a user setting that should be in the route).
[snip]
I agree that the current options menu is a mess. As you all know, I have not been around for a while and coming back now, I have serious troubles finding the things I want in there (and I do a lot of that in my efforts to update the German translation).
I'm also supportive of moving options to option sets that are specific to certain types of content (routes, engines, stock, activities - as James mentioned - but also timetables, of course) in order to keep together what goes together and prevent the user from messing with things that tend to break stuff.
However, there must still be a set of default values for any of those options to fall back to in case a content item does not specify an option (which will be the case for a large bunch of older content for a while, unless someone create updates for such content). And I feel those defaults should also be user-definable, though a simple text file should suffice, which must not necessarily be editable from the menu - keep the user away from things that can break stuff, but still allow them to set it.
Also, if we keep to some sort of "plain text style" definitions that we MSTSers have become so used to. That should do for those who do not like one or two of the content-specific options.
Still, in conclusion, that will keep us having a default set of options (that are not in the menu but still could be user-defined) and that need to be overridden by content-specific options. Overriding of the defaults could well be the standard behavior, but the user will still need to be informed about this. The choice whether to override defaults or not should, IMHO, be a check-box in the options, in order to KISS WRT bugging the user upon start of an activity / timetable.
With all of that in mind, I think my ideas are close to Carlo's proposal, only turned by 180° - use of content-specific options should be the norm to the extent this makes sense, which can be curtailed by the content developer when writing the specific options file. The behavior could still be changed through a simple switch, though, which prevents the user from having to click through loads of pop-ups.
Opinions, anyone? ;)
Cheers, Markus