[steamer_ctn]

Thanks for the feedback and comments

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.

Whilst I appreciate that this comment was probably "tongue in cheek", it is a real problem, as potentially indicated by this thread.

As suggested above I see this situation is frustrating for the user (and potentially turns them off using OR) and for the content creator (me in this case) as they have to spend time trying to work out why the activity is not working on the users PC.
I believe, that if we want to encourage new users, we need to make their use of OR as trouble free as possible. Ensuring the consistency of operation of an activity will significantly reduce some of these types of issues.

To my thinking it appears that we now have two slightly different requirements being discussed in this thread as follows:
i) Route options - the ability to set specific options on a route by route basis. I assume that this would include any features specific to the route and its performance. This might include options such as viewing distance, overhead wires, etc.

ii) Activity options - the ability to set specific options on an activity by activity basis. I assume that this would include any features specific to the operation of the train and would include signal and physics performance.
This thread was to gauge a level of interest and to identify any potential issues. Currently I am not certain whether either of these options are easy or hard to implement (to code in OR), and I am only prepared to investigate item ii) at this time.

I believe that there has already been some discussion in regard to Route options (item i) above). So in order to keep the discussion relevant to the subject , is it possible to use this thread to provide comment about Activity options, and use the other thread for Route options?

Thanks

[Genma Saotome]

steamer_ctn, on 02 April 2019 - 03:16 PM, said:

Thanks for the feedback and comments

I believe, that if we want to encourage new users, we need to make their use of OR as trouble free as possible.

IMO the single task that would help the most is a glossary of OR Parameters, their definitions, and as applicable range of valid values.

WRT the task you are actually investigating (which I endorse), I would encourage you to reconcile yourself to the poor odds of knowing in advance which options are more or less likely to be route only vs. activity level and simply put the full suite of choices in one file allowing for it's location to determine the span of its application. It would not need to be an .inc file -- how about a new .opt file type where the file names are one of Open Rails, {route name}, and {act. file name}? Being able to do something like "make a copy of my machine level options, let me change two values and save it in this route folder" offers both 100% flexibility and 100% security against rotten data. It might also be easier to implement. Many, perhaps most of the values would be the same from Open Rails to {act. file name} but if the structure of the .opt file is a constant then it doesn't matter if only two or three options are different... the program needs to know what all of them are.

[perpetualKid]

I could clearly see the benefit of route- or activity-based presets for certain options.

But - as a developer reading this thread, and with only limited understanding of different railroad systems, engine types etc and the expected behavior, I would not know what to implement here.

It would be really helpful if people discussing such great features and ideas at that level of detail, could come up with a user story summarizing the ask. This could include prerequisites, constraints, different scenarios etc, and eventually serve as input for documentation/guidance purposes as well. In collaborative community efforts like OR, this will also help to appreciate everyones area of expertise, and ensuring high quality and broader basis for support.

Just my $0.02

[steamer_ctn]

Genma Saotome, on 02 April 2019 - 09:49 PM, said:

IMO the single task that would help the most is a glossary of OR Parameters, their definitions, and as applicable range of valid values.

I agree, perhaps a volunteer will offer their services to compile this.

Genma Saotome, on 02 April 2019 - 09:49 PM, said:

WRT the task you are actually investigating (which I endorse), I would encourage you to reconcile yourself to the poor odds ...........

Thanks for the suggestion, and whilst this solution has merit, it will require a lot more effort and skill then I possess at this time.

I have done some preliminary investigation and I am reasonably confident that I can use the exist Activity INCLUDE file to specify activity related options to be set for the duration of the activity (some more investigation underway).

In anticipation of finialising the investigations I have raised a blueprint to cover the proposed work.

Thanks

[James Ross]

steamer_ctn, on 02 April 2019 - 02:53 AM, said:

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.

Do you know exactly which settings are causing problems? The vast majority of user settings should be fine, and we should always try to avoid introducing new user settings that can significantly affect the way existing content plays.

steamer_ctn, on 02 April 2019 - 02:53 AM, said:

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.

If we do this, it must be the absolutely minimum of settings - preferably just one or two. We must not allow the content creator to override any more settings that strictly necessary.

Also, we must provide the user with an option to ignore the content creator's overrides. The user must always have the final say - but we can put a suitable warning next to this option to indicate that it may break content.

steamer_ctn, on 02 April 2019 - 02:53 AM, said:

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.

There isn't such a thing as an "include type file" so I am not certain what you are proposing here. We have SIMIS files and JSON files; we are not creating new SIMIS files but can add new options to existing ones.

steamer_ctn, on 02 April 2019 - 02:53 AM, said:

Is there general support for an approach as outlined?

In principal, but as above I would need to see the list of settings and it would need to be tiny.

Genma Saotome, on 02 April 2019 - 01:11 PM, said:

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.

This sounds like the proposal to provide the user with the ability to set route or activity-level options, which is different from what's needed here.

There is another option available, depending on which user settings are problematic here: remove those user settings and make them entirely content creator settings (in route and/or activity files).

[copperpen]

James Ross, on 07 April 2019 - 06:59 AM, said:

There isn't such a thing as an "include type file"

We have Include files that use the .inc extension that can be used to add OR specific instructions to eng files etc. That is what Peter is suggesting to use to modify an act file to use specific activity switches of which in my mind there is only one that should be on which will not affect any activity that does not use it, Extended AI train shunting.

Forced red at station stops may have an adverse effect on the occasional passenger activity, but I have not found one yet that fails to work with this switched on.

There are no other switches under the activity options list that would affect the running of an activity, autopilot is the lazy mans train driver, and opening doors at station stops is eyecandy.

[James Ross]

copperpen, on 07 April 2019 - 07:40 AM, said:

We have Include files that use the .inc extension that can be used to add OR specific instructions to eng files etc.

That's not what they do though - .inc files extract a subsection from another file format (like .eng, .wag, .act) but they do not work on their own nor do they have their own format into which we can define options.

If we want to override user settings for an activity, the option goes into .act files. It's up to the content creator if they want to break that down into an .act and one or more .inc files (like with .wag, .eng), but that does not change how the option is defined for .act files and does not have anything to do with .inc files.

copperpen, on 07 April 2019 - 07:40 AM, said:

Forced red at station stops may have an adverse effect on the occasional passenger activity, but I have not found one yet that fails to work with this switched on.

This is the main one I am expecting to be an issue, but we'll see. :)

[Csantucci]

Location-linked passing path processing might be another one: it may lead to different train meet locations.
There are all settings that cause specific forces as well the adhesion linked to weather conditions to be taken into account; they might affect player train timing more or less.

[steamer_ctn]

James Ross, on 07 April 2019 - 06:59 AM, said:

Do you know exactly which settings are causing problems? The vast majority of user settings should be fine, and we should always try to avoid introducing new user settings that can significantly affect the way existing content plays.

If we do this, it must be the absolutely minimum of settings - preferably just one or two. We must not allow the content creator to override any more settings that strictly necessary.

Also, we must provide the user with an option to ignore the content creator's overrides. The user must always have the final say - but we can put a suitable warning next to this option to indicate that it may break content.

It is the proliferation of option settings that has created the issue. There seem to be a lot less in MSTS (but then perhaps it has lesser functionality).

Let me demonstrate the issue as I see it.

A series of tutorial / demonstration activities has been created in the demonstration routes referred to on the Open Rails site. These routes are designed as an "all in one" package so that the user can start running OR quickly and with the minimal amount of install effort or problems. The activities are designed to teach the user the basics and some more advanced techniques of operation and driving trains in OR.


So the user downloads the package and installs OR and the routes/activities. So far this has been a relatively easy process. The problems then commence when they start running the activities and signals do not clear, brakes do not work, etc. So instead of a positive experience we now have a user questioning whether OR is worth the effort. This happens because when OR is installed it sets default values for all the option settings. These activities have been design to provide the user with a certain experience, and this means that some of the option settings need to be set to certain settings.


For an example of the types of settings required for these activities to successfully run, refer to the attached briefing document. The briefing document provides a list of the type of option setting that need to be set for this activity, unfortunately most users don't read the documentation that comes with OR (the manual) or the activity briefing documents, they just want to run the train. The list is not presented as an exhaustive list of options that will be made available under this proposal.

Based upon some initial work, the INCLUDE file would have the following format:

SIMISA@@@@@@@@@@JINX0a0t______

Tr_Activity (
	Tr_Activity_File (

 		ORTSAIHornAtCrossings ( 5 )

 		ORTSForcedRedAtStationStops ( 1 )
    	ORTSAutopilot ( 1 )
    	ORTSExtendedAITrainShunting ( 1 )
    	

	)
  )

If an option is present in this file then the default is over written for the duration of the activity only. If the option is set at zero or not present then the option will remain as per the normal user settings. The settings are not permanent.

Advanced users can opt to edit or remove this file to prevent over writing of the options but it would need to be done on the basis that the activity may no longer work in the fashion that it was intended.

James Ross, on 07 April 2019 - 06:59 AM, said:

In principal, but as above I would need to see the list of settings and it would need to be tiny.

It needs to be all the option settings associated with train operation. So for example, one of the activities demonstrates loss of adhesion by the locomotive, so the adhesion settings need to be enabled.

copperpen, on 07 April 2019 - 07:40 AM, said:

There are no other switches under the activity options list that would affect the running of an activity, autopilot is the lazy mans train driver, and opening doors at station stops is eyecandy.

Autopilot is required to allow swapping between trains. There is an activity on resolving path deadlocks which requires this capability.

Whether something is considered to be eyecandy or not, the activity creator should have the ability to set their activity up the way that they wish. The user can then elect to either run the activity or not run it,.

Just like rolling stock content providers who configure ENG/WAG files to suit their stock, activity creators should have the same ability.

Attached File(s)

•  Tutorial Activity(#8 - Dispatch)v1.3.pdf (154.36K)
  Number of downloads: 339

[steamer_ctn]

An initial patch has been included in Rel. 17 of OR NewYear MG to allow activity creators to override user settings for their activity only.

Currently the patch provides ability to set up an override on the parameters described in the Briefing document example included in the above post.

An example working activity is available from here which demonstrates the setup and format required.

In short the following override parameters can be added to a activity by setting up an OpenRails folder under the ACTIVITY folder, and inserting an INCLUDE file named the same as the relevant activity.

The INCLUDE file will be formatted as follows:

SIMISA@@@@@@@@@@JINX0a0t______

Tr_Activity (
	Tr_Activity_File (

 
	Comment (=== General TAB ===)
    	ORTSGraduatedBrakeRelease ( 1 )
    	ORTSViewDispatchWindow ( 1 )

	Comment (=== Video TAB ===)  
    	ORTSFastFullScreenAltTab ( 1 )
    	
	Comment (=== Simulation TAB ===)	
    	ORTSForcedRedAtStationStops ( 1 )
    	ORTSAutopilot ( 1 )
    	ORTSExtendedAITrainShunting ( 1 )
    	ORTSUseAdvancedAdhesion ( 1 )
    	ORTSBreakCouplers ( 1 )
    	ORTSCurveResistanceDependent ( 1 )
    	ORTSCurveSpeedDependent ( 1 )
    	ORTSTunnelResistanceDependent ( 1 )
    	ORTSWindResistanceDependent ( 1 )
    	ORTSHotStart ( 1 )
    	
	Comment (=== Experimental TAB ===)
    	ORTSLocationLinkedPassingPaths ( 1 )
    	ORTSAdhesionFactorCorrection ( 100 )
    	ORTSAdhesionFactorChange ( 10 )

	)
   )

The above parameters relate to option choices in the OPTIONS menu, and can either be inserted in the file or left out.

All the parameters with the exception of the last two are True/False type values, where 0 = false and 1 = true. The override parameter will only apply if it is included in the INCLUDE file and it has a 0 or 1 value assigned to it.