Elvas Tower: Predictable behaviour for tutorial activities - Elvas Tower

Jump to content

  • 2 Pages +
  • 1
  • 2
  • You cannot start a new topic
  • You cannot reply to this topic

Predictable behaviour for tutorial activities setting user options

#1 User is offline   cjakeman 

  • Superintendant
  • PipPipPipPipPipPipPip
  • Group: ET Admin
  • Posts: 1,931
  • Joined: 03-May 11
  • Gender:Male
  • Location:Peterborough, UK
  • Simulator:Open Rails
  • Country:

Posted 30 April 2020 - 05:14 AM

I want to refer back to Activity Consistency of Operation, a thread that ended nearly a year ago with no consensus being reached.

Steamer_ctn has provided us with the Starter Kit promoted on the Open Rails home page. It's a fine set of tutorials based on steam traction and, being the contact person for the website, I get positive feedback on it from newcomers.

We badly need more tutorials (diesel traction anyone?), especially with more complex operations like TCS coming along.

The aim of the earlier thread was to discuss ways to ensure that a tutorial activity would behave in a predictable way for all users. User Options which are critical to the tutorial can be specified in the Briefing (or a separate document) but, as Woodfyr and Gerry both noted, these are easy to overlook. That leads to a poor experience and wastes our time in investigating spurious problems.

Carlo identified 3 user options which might be given early retirement and others made valuable contributions too.

We ended up with opposing viewpoints which I try to summarise as:

  • The proposal extracts all critical options from the activity file and applies them to override any conflicting options selected by the user
  • The proposal goes against the Open Rails practice of giving the user full control and complicates an aspect of OR that is already difficult for users.

After a long time we are no further forward on this important issue, so I am trying here to reconcile these views with an alternative approach.

My suggestion is:

  • The user is instructed in the Briefing to set any User Options which are critical for the activity (as currently).
  • that we make use of the code proposed to extract critical options from the activity file.
  • that RunActivity.exe checks that these critical User Options are correctly set.
  • a simple dialog informs the user if he has omitted to set any.
  • if the user chooses "No" to press on regardless, this is recorded in the log file.

Attached Image: 2020-04-30 13_52_42-Open Rails.jpg

Is this an acceptable way through?

#2 User is offline   Genma Saotome 

  • Owner and Admin
  • PipPipPipPipPipPipPipPipPipPipPip
  • Group: ET Owner
  • Posts: 13,710
  • Joined: 11-January 04
  • Gender:Male
  • Location:United States
  • Simulator:Open Rails
  • Country:

Posted 30 April 2020 - 12:42 PM

It might help to understand the issues w/ a couple of examples.

Absent that, filling in some blanks leads me to ask why not move more (most?) options out of the options tabs and into a "modern" activity-options file (same name as the activity per KUJU standards, but a new file suffix so it's purpose and use are unambiguously understood).

The advantage of this is whatever it is you require for a tutorial activity is predefined and provided when someone downloads the tutorial.

It also opens the doors for activity designers to do the same, much in the same way an activity might specify the season.

A two phase development approach spreads the task out -- first the file and the means to get it's information into the right places of the OR code and a second, optional phase of providing a UI to create and edit the new file. I say optional because we have no equivalent UI for .wags and .engs and so the old, well proven technology of a text edit is familiar to everyone.

If, with further analysis it makes sense to add the sophistication of making this new file an activity level over-ride to the global options, well, so be it. It certainly would minimize the amount of work to convert over tot he new process.

Once released it would also serve as the means to make any number of things activity options, pretty much whatever appeals. Not doing this leaves the activity software bound up by the limitations of the KUJU design... what is that now... 19 years old?

#3 User is offline   steamer_ctn 

  • Open Rails Developer
  • Group: Status: Elite Member
  • Posts: 1,268
  • Joined: 24-June 11
  • Gender:Male
  • Country:

Posted 30 April 2020 - 02:31 PM

Hi Chris,

View Postcjakeman, on 30 April 2020 - 05:14 AM, said:

My suggestion is:

  • The user is instructed in the Briefing to set any User Options which are critical for the activity (as currently).
  • that we make use of the code proposed to extract critical options from the activity file.
  • that RunActivity.exe checks that these critical User Options are correctly set.
  • a simple dialog informs the user if he has omitted to set any.
  • if the user chooses "No" to press on regardless, this is recorded in the log file.
Is this an acceptable way through?

Thanks for trying to move this feature approval forward.

If I have understood the proposed alternative approach correctly then it appears that the following steps will be required to run the activity:

i) The user has to read an activity briefing, and as known, most people want to skip this step.

ii) Before commencing the activity the user then needs to find the settings required in the option menu and enable/disable them as appropriate. They would need to maintain a list of their current settings for the following step.

ii) As the settings have been "permanently" set, at the completion of the activity, the user must then restore all the changed settings back to their preferred settings

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.

#4 User is offline   Csantucci 

  • Member, Board of Directors
  • Group: Status: Elite Member
  • Posts: 5,149
  • Joined: 31-December 11
  • Gender:Male
  • Country:

Posted 30 April 2020 - 11:20 PM

I agree with Peter about the fact that things must be KISS. I agree with Chris that the last word is that of the player.
I make a proposal which has parts of that of Chris and parts of that of Peter, and takes into consideration some of Dave's thoughts.

First of all the solution should be able to take into account also timetables, even if not immediately.
Second, it can be supposed that the same activity creator will usually require the same set of settings.
Third, manually inserting settings is annoying.

Here the proposal:
1) To allow the final decision to the player, there are two possibilities:
a- a menu option where the player can tick if he wants to use his own settings or the ones recommended for the activity/timetable
b- when the activity/timetable Start button is pressed, a pop-up dialog box appears requesting the player whether he wants to use his own settings or the recommended ones
2) in both alternatives, if the recommended settings are selected, they are automatically loaded by OR
3) the recommended settings don't reside within the activity file, but within an external file (e.g. an .ini file); in the activity/timetable file only the path to such file is present; this way the file can be common to more activities/timetables and is independent from the actual activity structure
4) at runtime the recommended settings data aren't loaded within and by the activity (or timetable) class, but within a class at a higher level, e.g. within Simulator, and also the method reading the .ini file and loading the settings resides within e.g. Simulator. So the independence from the activity/timetable structure is both before the game has started as well as during the game.

#5 User is offline   cjakeman 

  • Superintendant
  • PipPipPipPipPipPipPip
  • Group: ET Admin
  • Posts: 1,931
  • Joined: 03-May 11
  • Gender:Male
  • Location:Peterborough, UK
  • Simulator:Open Rails
  • Country:

Posted 30 April 2020 - 11:34 PM

View Poststeamer_ctn, on 30 April 2020 - 02:31 PM, said:

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.

Yes, you have understood correctly and this alternative proposal has exactly the drawbacks you have identified.

It does, however, leave the user always in control which (by my reading of the original thread) has been the obstacle to getting predictable activities adopted.

#6 User is online   James Ross 

  • Open Rails Developer
  • Group: Status: Elite Member
  • Posts: 5,186
  • Joined: 30-June 10
  • Gender:Not Telling
  • Simulator:Open Rails
  • Country:

Posted 01 May 2020 - 02:29 PM

View Postcjakeman, on 30 April 2020 - 05:14 AM, said:

Carlo identified 3 user options which might be given early retirement and others made valuable contributions too.

Did we make any progress in removing these options? That would be a very worthwhile contribution.

View Postcjakeman, on 30 April 2020 - 05:14 AM, said:

  • The proposal extracts all critical options from the activity file and applies them to override any conflicting options selected by the user
  • The proposal goes against the Open Rails practice of giving the user full control and complicates an aspect of OR that is already difficult for users.



View Postcjakeman, on 30 April 2020 - 05:14 AM, said:

  • The user is instructed in the Briefing to set any User Options which are critical for the activity (as currently).
  • that we make use of the code proposed to extract critical options from the activity file.
  • that RunActivity.exe checks that these critical User Options are correctly set.
  • a simple dialog informs the user if he has omitted to set any.
  • if the user chooses "No" to press on regardless, this is recorded in the log file.

Attachment 2020-04-30 13_52_42-Open Rails.jpg

This would certainly be better than silently overriding a wide range of user preferences.

I also like Carlo's option 1b, which lets you choose between the activity's choices and yours (although that's not going to help if you only disagree with one of many overrides).

View Poststeamer_ctn, on 30 April 2020 - 02:31 PM, said:

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.

If we can successfully combine it with something similar to Chris and Carlo's 1b ideas, we may be able to move forward.

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).

I do not actually care too much whether we give the user the choice (use activity overrides or don't), but I do believe the user needs to know what's going on.

And I would like the implementation to make it very clear which entries are activity configuration and which entries are overriding user options. Ideally by using the word "override" in there somewhere. This should always be a final resort and discouraged.

#7 User is offline   steamer_ctn 

  • Open Rails Developer
  • Group: Status: Elite Member
  • Posts: 1,268
  • Joined: 24-June 11
  • Gender:Male
  • Country:

Posted 01 May 2020 - 10:56 PM

View PostCsantucci, on 30 April 2020 - 11:20 PM, said:

Second, it can be supposed that the same activity creator will usually require the same set of settings.
Whilst I agree that this may be the case most of the time, it may however be necessary for the same activity creator to use different settings. For example, different tutorial activities may require different settings.


#8 User is offline   Csantucci 

  • Member, Board of Directors
  • Group: Status: Elite Member
  • Posts: 5,149
  • Joined: 31-December 11
  • Gender:Male
  • Country:

Posted 02 May 2020 - 12:13 AM

View Poststeamer_ctn, on 01 May 2020 - 10:56 PM, said:

Whilst I agree that this may be the case most of the time, it may however be necessary for the same activity creator to use different settings. For example, different tutorial activities may require different settings.

True, but my suggested approach does not prevent this. Only, all activities requiring the same settings will refer to the same settings override file.

cjakeman said:

Carlo identified 3 user options which might be given early retirement and others made valuable contributions too.

I believe they were only two indeed, that is Autopilot and AI shunting

James Ross said:

Did we make any progress in removing these options? That would be a very worthwhile contribution.


I have just opened a Trello box for this https://trello.com/c...ould-be-default , and when I get it approved I'll try to find the time to proceed.

#9 User is offline   markus_GE 

  • Executive Vice President
  • PipPipPipPipPipPipPipPipPip
  • Group: ET Admin
  • Posts: 4,627
  • Joined: 07-February 13
  • Gender:Male
  • Location:Leoben, Styria, Austria, Europe
  • Simulator:ORTS / MSTS
  • Country:

Posted 02 May 2020 - 03:09 AM

Hi guys,

after quickly skimming through the old thread Chris linked and thoroughly considering this one, I need to share some thoughts as well.


View Poststeamer_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.


View PostJames 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

#10 User is offline   roeter 

  • Vice President
  • Group: Status: Elite Member
  • Posts: 2,046
  • Joined: 25-October 11
  • Gender:Male
  • Country:

Posted 02 May 2020 - 04:24 AM

Cleaning out the user options menu, collecting the options more properly to the items they affect (route, activity etc.) would be a very welcome step.
Many options are still set on the 'experimental' tab even though these have now been around for years.

As for timetables: there are no user options which directly affect the timetable processing. There are, ofcourse, certain options like physics and adhesion which might affect the running of the (player) train, but those are indirect consequences, and not options which somehow change the working of the timetable as such.
The main reason for not using general user options for timetables is that, unlike for activities, commands can be set for locations and/or trains within the timetable definition. So any options which one might wish to use can be defined as timetable commands which allows for a much more controlled use than by defining these as overall user options.

Regards,
Rob Roeterdink

  • 2 Pages +
  • 1
  • 2
  • You cannot start a new topic
  • You cannot reply to this topic

1 User(s) are reading this topic
0 members, 1 guests, 0 anonymous users