Page 2 of 4 FirstFirst 1234 LastLast
Results 11 to 20 of 34

Thread: One activity with Fall Harvest on CN Ruel Subdivision

  1. #11
    Join Date
    Sep 2006
    Location
    .
    Posts
    2,207

    Default

    Personally, I think the easier solution is to make AIs obey the laws of gravity, gradient, (over)tonnage, (under)horsepower and physics to better match what the player deals with when running raw, and base any autopilot feature similar to that. Then we can do both - speed up activities for testing and the player should be able to slip in and out of autopilot without it being such a physics-ignoring anomaly. But I know, MSTS AIs never did have to obey physics and we must maintain backwards compatibility with a boatload of obsolete 20 year old activities in the library. At least give the user a checkbox to select one way or the other, so the ones willing can shed the needs of obsolete MSTS activities if the user desires and instead prefers to build their own supply of modern acts the new way. We need a whole new generation of open rails activities anyway

    I can think of no benefit to be gained (outside of legacy support of horrendously silly ancient activities) by having tonnage AI's behave like nothing is on their drawbar.

  2. #12
    Join Date
    Feb 2013
    Location
    known universe
    Posts
    1,626

    Default

    Quote Originally Posted by geepster775 View Post
    Personally, I think the easier solution is to make AIs obey the laws of gravity, gradient, (over)tonnage, (under)horsepower and physics to better match what the player deals with when running raw, and base any autopilot feature similar to that. Then we can do both - speed up activities for testing and the player should be able to slip in and out of autopilot without it being such a physics-ignoring anomaly. But I know, MSTS AIs never did have to obey physics and we must maintain backwards compatibility with a boatload of obsolete 20 year old activities in the library. At least give the user a checkbox to select one way or the other, so the ones willing can shed the needs of obsolete MSTS activities if the user desires and instead prefers to build their own supply of modern acts the new way. We need a whole new generation of open rails activities anyway

    I can think of no benefit to be gained (outside of legacy support of horrendously silly ancient activities) by having tonnage AI's behave like nothing is on their drawbar.
    The debate on AI physics has been ongoing...with solid arguments on both sides of the question...personally I have not decided yet...but being interested in physics -- I'm leaning in the direction of having accurate physics for anything that's on a track. Some kind of check box option for the backward MSTS AI compatibility would appear to be the solution...but then the developers have shied away from adding too many check box options.
    Cheers, R. Steele [Gerry] It's my railroad and I'll do what I want! Historically accurate attitude of US Railroad Barons.


  3. #13
    Join Date
    Nov 1999
    Location
    Netherlands.
    Posts
    155

    Default

    Quote Originally Posted by geepster775 View Post
    Personally, I think the easier solution is to make AIs obey the laws of gravity, gradient, (over)tonnage, (under)horsepower and physics to better match what the player deals with when running raw, and base any autopilot feature similar to that. Then we can do both - speed up activities for testing and the player should be able to slip in and out of autopilot without it being such a physics-ignoring anomaly. But I know, MSTS AIs never did have to obey physics and we must maintain backwards compatibility with a boatload of obsolete 20 year old activities in the library. At least give the user a checkbox to select one way or the other, so the ones willing can shed the needs of obsolete MSTS activities if the user desires and instead prefers to build their own supply of modern acts the new way. We need a whole new generation of open rails activities anyway

    I can think of no benefit to be gained (outside of legacy support of horrendously silly ancient activities) by having tonnage AI's behave like nothing is on their drawbar.
    I'm afraid it's not as simple as that.
    There are a number of reasons why AI's don't use the same advanced physics as the player train. Compatibility is actually quite low on that list.
    One of the major problems is that control over AI trains is not as advanced as what is available to the player. Control has to be performed at train level, but not all information at unit level which is reported to the player is available for AI control at train level. For instance, wheelslip is not reported at train level. If the program starts an AI train and it's not moving, there's no knowing whether this is through wheelslip, or through lack of power. Particular for trains which do not have an engine at the head (push-pull trains, MU's), wheelslip is a serious problem. To drive a train you need a cab, and a cab can only be defined for an engine. So what happens is that the leading 'engine' in such consists is just a carriage with relative low weight, and so is very prone to slipping. I have run various tests over the years to see if AI trains could be controlled using proper physics, but in all cases this failed as trains which ran smoothly when controlled by the player got stuck on the very first hill when run as AI.
    Another major problem is the wide variety of settings for engine characteristics. Take brakes, for instance. Some trains have brake parameters such that you need to apply 25% brake, and still it will take some time for this to take effect. For other trains, though, if you apply 25% brake, it acts like a full emergency brake and the train stops almost immediately. As player, you learn to adapt to this (often after some failures with either stopping too soon or running through stations or signals), but the program does not have this information - there is no database where information is stored on how certain engines or trains react and how they should be run. But the last thing we all want is AI trains running out of control.
    I'm not saying that the present AI control can't be improved, but with definition of engine characteristics, implemented physics and availability of both information and control as these are now, it is an illusion that running AI trains using proper physics would be possible.

    As for the problem with this and other activities: the problem is that it is attempted to design one set of activities for both MSTS and OR. With the difference in physics and other characteristics which affect the running of the player train, passing time for the player train will differ between MSTS and OR, and this will lead to failures as discussed here.

    Regards,
    Rob Roeterdink

  4. #14
    Join Date
    Jun 2004
    Location
    Winnipeg, MB, CA.
    Posts
    187

    Default

    The biggest differences between player and autopilot control seem to be acceleration and braking, in that it behaves as if you're always travelling 'light'. As a first step, could the autopilot be made to simply 'de-rate' the forces applied, so the end behaviour is closer to prototypical? Does the autopilot have access to the train length or tonnage to adjust the de-rating as mass is added and subtracted?

    Bob

  5. #15
    Join Date
    Sep 2006
    Location
    .
    Posts
    2,207

    Default

    Along my line of thinking. ^^^^^^

    No, there need not be an accounting for every crosswind or wheel slip caused by every drop of rain that lands on the railhead or every dud clinker of coal that ends up in the firebox. Just some ballpark calculations to add tonnage to the drawbar and account for uphill gradients would be immensely more accurate. But you can't even ballpark it without cutting the cord to the past. Today, we can already safely use autopilot on long extended downgrades and not worry about getting extremely off schedule compared to any accelerated activity testing. It is the starting. stopping and upgrade segments that throw the biggest curve ball.

  6. #16

    Default

    Given the limitations of AI, maybe AI and Autopilot should be two separate functions, where Autopilot puts a Virtual Player in the cab. It could be a player using limited functions, such as described in the previous post.

  7. #17
    Join Date
    Nov 1999
    Location
    Netherlands.
    Posts
    155

    Default

    Quote Originally Posted by dcarleton View Post
    Given the limitations of AI, maybe AI and Autopilot should be two separate functions, where Autopilot puts a Virtual Player in the cab. It could be a player using limited functions, such as described in the previous post.
    That would defeat the whole purpose of Autopilot.
    Autopilot was never intended as an alternative to running a player train, but as a tool to test AI behaviour in activities. When separating AI and Autopilot obviously that function is lost, so yet another train control function would be required.

    Regards,
    Rob Roeterdink

  8. #18
    Join Date
    Nov 1999
    Location
    Netherlands.
    Posts
    155

    Default

    Quote Originally Posted by geepster775 View Post
    Along my line of thinking. ^^^^^^

    No, there need not be an accounting for every crosswind or wheel slip caused by every drop of rain that lands on the railhead or every dud clinker of coal that ends up in the firebox. Just some ballpark calculations to add tonnage to the drawbar and account for uphill gradients would be immensely more accurate. But you can't even ballpark it without cutting the cord to the past. Today, we can already safely use autopilot on long extended downgrades and not worry about getting extremely off schedule compared to any accelerated activity testing. It is the starting. stopping and upgrade segments that throw the biggest curve ball.
    I'm not a physics expert, so to set up something like that I would need input, e.g. algorithms or a properly documented list providing acceleration and max. speed as function of power/weight ratio and gradient.
    Now, this may come as a shock, but this is not the first time this issue is discussed, either here or at Elvas Tower. It's also not the first time I have indicated I need proper input if functionality like that is to be added. As yet, I'm still waiting for that input. Somehow, I think it won't be coming now either, so my advice would be not to hold your breath while waiting for AI behaviour to be changed.

    Regards,
    Rob Roeterdink

  9. #19
    Join Date
    Jun 2004
    Location
    Winnipeg, MB, CA.
    Posts
    187

    Default

    So all the focus on accurate physics only applies to the player train? That seems self-defeating: If traffic ignores physics, then all the player interactions with traffic won't be accurate.

    How does the AI/autopilot currently calculate acceleration and braking? It seems to have some sense of the weight it's hauling, so could we not just multiply that by an empirically determined fudge factor to slow acceleration and braking performance?

    Bob

  10. #20

    Default

    Quote Originally Posted by tooltroll View Post
    "...................snip....................If traffic ignores physics, then all the player interactions with traffic won't be accurate. .....................................snip......... .................... Bob
    How would AI performance make player interactions inaccurate?

    For instance, the PRR-Eastv2 activity Washington to New York if run in Autopilot Mode has exactly the same interactions with the over abundance of AI traffic every time the activity is run.

    Now if the activity is run with the Player controlling the train, it's different interactions every run, the player being the variable.

    So yes, I do see differences in from MY viewpoint as the player but the AI keeps the same time as always.
    This makes designing an activity easy . . . even using the MSTS editor as I did for all the PRR activities.
    I really don't care a whit what the AI is doing as it's doing what I designed it to do . . . interact correctly with the Player.

    Everything an AI does is controllable by the activity designer . . . everything! My take is I don't need to know how an AI runs, just so long as it runs (and interacts with other AI also) where you the designer wants.
    Do you need to know how your TV generates a picture? Of course not! The picture you the player want is the important thing.

    To me it's the same with the AI I encounter in an activity and the immersive feel it presents: running the right speed; being at the wanted location at the correct time, and so on. Autopilot Mode allows an activity designer to construct unbelievably complex AI traffic services that ALWAYS run exactly the same. This makes activity creation a pleasure.
    No need to fret that your AI traffic trains are bending or breaking the rules. If you don't see it what's the point? The stuff you do see can be controlled.
    Oh, just remembered . . . you want AI different every run? Okay, turn on Randomization! I'd suggest level 1 for a start. Some very interesting effects. From what I could see the AI spawn time were messed with.
    And if it suits you you can 'jump' into any of your AI and while you're driving it obeys your commands.
    regards,
    ............Vince ..............
    ...... Author NECv4 .......
    .... LIRR BUILD PHOTOS ....
    .............LIRR VIDEO.............
    ...... Eschew Obsfucation ......

    On the The Statue of Liberty in New York Harbor there is a Tablet. On it is written:
    "Give me your tired, your poor, your huddled masses yearning to breathe free,
    the wretched refuse of your teeming shore, send these, the homeless, tempest-tossed to me,
    I lift my lamp beside the golden door!"

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •