Elvas Tower: Activity Consistency of Operation - Elvas Tower

Jump to content

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

Activity Consistency of Operation Many options cause many problems Rate Topic: -----

#21 User is offline   James Ross 

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

Posted 22 April 2019 - 05:29 AM

 steamer_ctn, on 07 April 2019 - 05:34 PM, said:

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.

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

Are you going to actually give me a list, though? I am not approving this without vetting the list of settings you can override, I'm afraid, as this is too much of a user-facing area (settings generally).

 steamer_ctn, on 07 April 2019 - 05:34 PM, said:

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

That is not an acceptable position to take. Users must be in control of the options they are given, without unexpected consequences of activities overriding whatever they please.

 steamer_ctn, on 07 April 2019 - 05:34 PM, said:

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

Yup, completely agree, but the vast majority of ENG/WAG configuration is not available to the user (and the few options that are, probably shouldn't be).

 steamer_ctn, on 18 April 2019 - 06:28 PM, said:

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

Not sure on graduated brake release - that should probably be a WAG configuration. View dispatch window is definitely not okay.

 steamer_ctn, on 18 April 2019 - 06:28 PM, said:

Comment (=== Video TAB ===)
ORTSFastFullScreenAltTab ( 1 )

Definately not okay.

 steamer_ctn, on 18 April 2019 - 06:28 PM, said:

Comment (=== Simulation TAB ===)
ORTSForcedRedAtStationStops ( 1 )
ORTSAutopilot ( 1 )
ORTSExtendedAITrainShunting ( 1 )
ORTSUseAdvancedAdhesion ( 1 )
ORTSBreakCouplers ( 1 )
ORTSCurveResistanceDependent ( 1 )
ORTSCurveSpeedDependent ( 1 )
ORTSTunnelResistanceDependent ( 1 )
ORTSWindResistanceDependent ( 1 )
ORTSHotStart ( 1 )

I don't think most of these should be options, even to the user. Extended AI train shunting should just be a perminant feature. Not happy with advanced adhesion.

 steamer_ctn, on 18 April 2019 - 06:28 PM, said:

Comment (=== Experimental TAB ===)
ORTSLocationLinkedPassingPaths ( 1 )
ORTSAdhesionFactorCorrection ( 100 )
ORTSAdhesionFactorChange ( 10 )

Location linked passing paths might be okay (although perhaps it should be a route option?). I don't know what to do with adhesion. :(

Basically, I think this is going in the wrong direction and hacking a "fix" onto the current mess rather than actually making things better.

#22 User is offline   wacampbell 

  • Member since Nov. 2003
  • Group: Fan: Traction Nuts
  • Posts: 2,342
  • Joined: 22-November 03
  • Gender:Male
  • Location:British Columbia, Canada
  • Country:

Posted 22 April 2019 - 08:19 AM

re AI train physics, consistency for activity creators

I originally had the idea that AI trains would use a much simplified physics simulation. The performance of AI trains would be very deterministic. I didn't want wheel slip, or weather effects etc to randomly impact the timing of the AI train movements. It was meant that players could substitute rolling stock ( ie to replace missing items ) without those changes effecting the timing of the activity. The simpler physics for AI trains would use less CPU resources. Having a stable AI train physics early on would allow us to refine and improve the 'player train' physics over time without breaking existing activities. The foundation for this is still in the code, I wonder if it may be worth returning to this model.


Wayne

#23 User is offline   copperpen 

  • Executive Vice President
  • Group: Status: Elite Member
  • Posts: 3,139
  • Joined: 08-August 05
  • Gender:Male
  • Simulator:MSTS & OR
  • Country:

Posted 22 April 2019 - 08:34 AM

I like the advanced adhesion model and the fact that I can set it to my preference ( 100% and no factor change ). I would most definitely not like it if anything were done which affects that. What would be more interesting is a random factor that changes rail conditions in specific locations such as stations and tunnel entrances where rail conditions can be far from ideal. MSTS had that for tunnel entrances.

The problem I have with AI is the same as it was in MSTS. It allows the activity creator to make totally unrealistic consists that travel along as though there were no rules of gravity and resistance against HP.

#24 User is offline   R H Steele 

  • Executive Vice President
  • PipPipPipPipPipPipPipPipPip
  • Group: ET Admin
  • Posts: 3,403
  • Joined: 14-March 13
  • Gender:Male
  • Location:known universe
  • Simulator:Open Rails
  • Country:

Posted 22 April 2019 - 09:54 AM

Interesting development, but - reading through the thread I'm sensing the real possibility that the potential for "breakage" is very favorable if some of the ideas are implemented. Why not just have activity makers provide a list of settings to use for a specific activity and then let the end user do what they want...most do not even read instructions.

 copperpen, on 22 April 2019 - 08:34 AM, said:

I like the advanced adhesion model and the fact that I can set it to my preference ( 100% and no factor change ). I would most definitely not like it if anything were done which affects that. ...

alittle http://www.elvastower.com/forums/public/style_emoticons/default/offtopic.gif I agree, however, I believe advanced adhesion is not fully formed...AC traction not modeled correctly, "wet" weather conditions - rain, snow, fog - all treated the same, and there is a definite difference shown in the diesel locomotive hud ( load data ) that shows a decreasing value-- with the default MSTS eng file highest and decreasing values when using the OR Diesel eng block and still decreasing values when any of the OR curve sets are added.

#25 User is offline   Genma Saotome 

  • Owner Emeritus and Admin
  • PipPipPipPipPipPipPipPipPipPipPipPipPip
  • Group: ET Admin
  • Posts: 15,307
  • Joined: 11-January 04
  • Gender:Male
  • Location:United States
  • Simulator:Open Rails
  • Country:

Posted 22 April 2019 - 11:29 AM

As usual James and I have different POV regarding the role of the content developer. IMO teh content developer should, if he chooses to do so, be able to define for his route the default setting of all options, period. The important thing tho is the word default. The end user should alway be able to set up an environment he is most comfortable using.

That said, I'll return to an earlier point: put the options values into a .opt file and have the software read that. OpenRails.opt should be a required file and can live in the OR installation directory tree, wherever is correct. <RouteName>.opt lives in the home directory of a route and is entirely optional. <ActivityName>.opt can live in teh \Activity directory of a route. It to is optional. Making the .opt file binary would keep many prying fingers out of the values.

When OR starts it simply looks for the .opt file until it finds one, starting \Activity and working towards the OR installation.

By this means the code supporting the current options tabs can be enhanced as needed to be aware of which level the choices are being made, to copy a file one level up or down, and perhaps even check and prevent nonsensical combinations. Aside from addressing the matter of scope it ensures the OR team controls what options are on offer and any range of acceptable values.

As before, when some option choice is recognized as both safely implemented and universally accepted it can be removed from the above and handled in the program as another other accepted function is.

IMO by making the .opt an identical structure w/o regard to the level it is scoped for should ensure the developers are not confronted with all sorts of weirdness produced by uses running amok and mis-defining things.



I believe this solution would neatly solve the problem Peter has shown regarding the starter routes.


As for the specific problem "solved" by use of an .inc file... is the real problem the lack of an OR activity editor?

#26 User is offline   steamer_ctn 

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

Posted 22 April 2019 - 10:22 PM

 James Ross, on 22 April 2019 - 05:29 AM, said:

That is not an acceptable position to take. Users must be in control of the options they are given, without unexpected consequences of activities overriding whatever they please.
This proposal does not remove the ultimate control of the user to change or remove the options if desired.

This is also about honoring the output that the activity creator is trying to create in their activity. Or are we saying that an activity creator should not have any control over the output of their activity?

 James Ross, on 22 April 2019 - 05:29 AM, said:

Not sure on graduated brake release - that should probably be a WAG configuration. View dispatch window is definitely not okay.
I would tend to agree, however we will then create a legacy issue. How should this be handled?


 James Ross, on 22 April 2019 - 05:29 AM, said:

Extended AI train shunting should just be a perminant feature.
Ok, then let's bite the bullet, and remove this option and make this a permanent feature, as well as the other activity related ones, such as ForcedRedAtStationStops, LocationLinkedPassingPaths.


 James Ross, on 22 April 2019 - 05:29 AM, said:

Not happy with advanced adhesion.
One of the OR tutorial activities shows a user how to operate a locomotive with Advanced Adhesion, so as an activity creator, how do I ensure that the user is experiencing the same issues that I am describing in the activity briefing notes.

 wacampbell, on 22 April 2019 - 08:19 AM, said:

re AI train physics, consistency for activity creators
I am not sure what this means. As far as I am aware the operation of AI trains is independent of all the physics that are applied to the player train (or should be), so setting of these parameters should not impact upon AI trains.

 R H Steele, on 22 April 2019 - 09:54 AM, said:

Interesting development, but - reading through the thread I'm sensing the real possibility that the potential for "breakage" is very favorable if some of the ideas are implemented.
I don't quite understand how "breakage" will occur. Can you expand on what you mean by breakage?

 R H Steele, on 22 April 2019 - 09:54 AM, said:

Why not just have activity makers provide a list of settings to use for a specific activity and then let the end user do what they want...most do not even read instructions.
Exactly, there needs to be an alternative way of ensuring that the activity experience is faithfully reproduced for the user.


 James Ross, on 22 April 2019 - 05:29 AM, said:

Basically, I think this is going in the wrong direction and hacking a "fix" onto the current mess rather than actually making things better.
Given the fact that we have an issue now, and that it is acting as a potential barrier for new users who just want to have a positive experience and run the tutorial activities for OR with the minimum amount of effort and understanding, how do we fix the current mess in a timely fashion (the sooner the better so that the impact on new users is corrected)?


Thanks

#27 User is offline   roeter 

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

Posted 23 April 2019 - 12:47 AM

What I am really missing in this discussion is the background to many of these options. This background is quite clear and really says it all : many of these options were introduced to switch off new OR features so as to keep OR compatible with MSTS.
Location passing paths, red at station stops and quite a few more all derive from this issue.
They could all be put together into one single option : run the program as the latest OR, or just as an MSTS clone. If such an indication could be added to activities, it would sort most of the user problems.
One of the problems here is that many activity developers still create activities which are basic MSTS activities and not OR activities, so even new activities still need OR to run as MSTS clone.

Other options are features which should not influence what the user is experiencing. Switching to AI trains in an activity is such an option - whether or not the user wants to do this should not in any way affect how the activity is running. So there should be no need for this to be an option at all.

Taken this background, it is clear that many of these options can not and should not be route related. They are activity related.
For instance, if you want to run both MSTS-clone activities and timetables on one and the same route, you would need different options for the activity as for the timetable. You might even need different options for different activities.
Only few options are really route related - signal glow is the only example I can think of at the moment, as that is linked to signal defintion for a route.

Therefor, setting these options as route options would be a backward step.
If a route builder sets these options for a new route to function as MSTS-clone, it would block the use of timetables on this route unless the user alters the options. Or unless we set up the program such that timetable mode simply disregards these options. Does not sound like a good idea.

Before any further steps are taken, there should be a clear view of why the option is there, how it affects things and what the implications are. That view also requires that we should not only look at activities.

Regards,
Rob Roeterdink

#28 User is offline   cjakeman 

  • Vice President
  • PipPipPipPipPipPipPipPip
  • Group: ET Admin
  • Posts: 2,857
  • Joined: 03-May 11
  • Gender:Male
  • Location:Peterborough, UK
  • Simulator:Open Rails
  • Country:

Posted 23 April 2019 - 05:37 AM

Lots of good points are being made on the thread regarding route-specific settings, MSTS v ORTS behaviour, user-override and the actual mechanism that implements activity-specific settings.

It seems to me that the original aim is being overlooked – Peter is trying here to use activities as tutorials, which are needed increasingly as newcomers arrive and as OR gets more capable.

A tutorial says “This is how the simulation behaves and this is how you control your train” so anomalous behaviour cannot be tolerated in a tutorial. (Of course, non-tutorial activities might also benefit from activity-specific settings.)


 James Ross, on 22 April 2019 - 05:29 AM, said:

Basically, I think this is going in the wrong direction and hacking a "fix" onto the current mess rather than actually making things better.

Thanks, James, for your points about the way INC files work and the ability of users to disable activity-specific settings. Taking those on board, how would you deliver tutorial activities with a predictable behaviour?

#29 User is offline   roeter 

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

Posted 23 April 2019 - 06:41 AM

 cjakeman, on 23 April 2019 - 05:37 AM, said:

Thanks, James, for your points about the way INC files work and the ability of users to disable activity-specific settings. Taking those on board, how would you deliver tutorial activities with a predictable behaviour?

By setting these options in that activity. As you say, it is about certain activities behaving in a specific way. Then make sure that they do by setting those requirements in that activity. To introduce settings for a route which apply to all and everything you do on that route only for some activities to behave in a predictable way is not a good option. In that sense, I agree with James that setting up the options in this way would only create a bigger mess.
I'm not saying there should not be any route options, but options should be linked to what they are intended for, and not be heaped onto just one great pile.

Regards,
Rob Roeterdink

#30 User is offline   Csantucci 

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

Posted 23 April 2019 - 07:12 AM

It may be discussed whether one or the other setting is relevant or not to activity run, but here we are discussing about settings relevant to activity run, and those should be set at activity level and not at route level. Consider e.g. the case where two or more activity creators have created activities for the same route: someone could create them with his "favourite" settings and someone else with his, different "favourite" settings. (This does not mean that few cases can exist, like the one mentioned by Rob about signal light glow, where the setting would be better at route level. Another one, that was not mentioned I believe, is track gauge: if you set the wrong gauge you won't have superelevation, and I regularly forget to change gauge when I'm passing from the Bernina route to a standard gauge route and vice-versa).

The way Peter (steamer_ctn) has started (that is inserting the activity related settings straight into the .act file or a file calling it or called by it) seems to me the most straightforward solution.
Providing a readme with the suggested or required settings for a specific activity (or group of activities) is another way, but I don't like it, because it's quite annoying for the game player.

About removing some activity options, I speak here for the ones I know better, because I was involved as author or modifier:
- the Autopilot option may be set as default and therefore the related checkbox may be removed; if someone would find some differences in behaviour of the player train (I believe I read something about that here in the forum), they could be analysed and eventually cause some small code adjustments;
- the Extended AI Shunting option had been introduced because there are some cases where behaviour of the AI trains is different with or without option: in particular without the option an AI train would not couple to another train but would only near it, which obviously is not desirable in some cases; in my opinion the Extended AI Shunting option may be set as default and the related checkbox removed;
- instead the Forced Red At Station Stops must stay, as I have already written in the past, because it defines two different ways of managing station starting signals, that exist also in reality; my country can be a very good example of this, because up to 20 years ago the starting signals had to be red when the train approached the station, while now it is no more so, and trains stop at stations with the starting signal already at green, because the signal is only related to the permission of occupying the block after the signal;
- re Location Linked Passing Paths only Rob can say: I never completely understood all the differences...

  • 4 Pages +
  • 1
  • 2
  • 3
  • 4
  • 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