One activity with Fall Harvest on CN Ruel Subdivision

[dcarleton]

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.

[roeter]

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

[roeter]

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

[tooltroll]

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

[Vince]

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

[tooltroll]

Ok, fair point, but what I was thinking of is this:

Say I'm designing an activity (and I am working on a few, one of them for the LIRR, excellent route, btw!) and I use the autopilot to time the traffic. Then the traffic won't sync up when a player controls the train, because the autopilot generally accelerates/decelerates faster and reaches higher speeds than under player control. Conversely, I can go the other way, and time the traffic by not using the autopilot and strictly driving under player control, then anyone using autopilot will be out of sync. Seems like either way, someone's going to be disappointed. It might not be a big deal when the traffic is just running past on a more-or-less regular schedule, but when I try to incorporate advanced shunting, it gets complicated.

Say I've got an AI that's going to pick up some cars and deliver them to a yard for the player to pick up as he passes, but I'd like to have him see it working as he's taking care of some other switching earlier on. So the player is switching the south side (say) and the AI is switching the north side (and maybe sometimes they interact, even), and then drops his cut where the player can pick them up. Right now, I pretty much have to time it to accommodate the autopilot, because if I sync it to a human player, someone using the autopilot will arrive too early (and they'll miss seeing the AI dance I have choreographed, lol!) Meanwhile, there's all the other traffic going by as challenges to both the north and south side switching tasks!

All I'm saying is it would be nice if we could "weigh down" the autopilot to make it act more like a real driver.

Bob.

[peterman]

Hi,

I just want to point out that OR has a few logic errors, and for the purpose of this thread and the discussion of AI behaviour, the logic error is about trains chasing trains ( whether it's an AI chasing an AI... or a player train chasing an AI or an AI chasing a player train ) where the chasing train will always take the passing siding... which means the chasing train will be put off of it's schedule. I tested it about a year ago and all my paths have passing paths, and every chasing train went into the siding... oh yes!!... I should mention that there was no oncoming traffic. I did test without passing paths and for the life of me cannot remember the outcome. For the doubters... create a test activity and see for yourself.

Bottom line... AI traffic will present some unpredictable results as it stands now.

Peter

[Vince]

Never saw anything as you describe in building, testing and running of the activities on the PRR Eastv2.
I always use the latest testing verions of Open Rails

regards,

[R. Steele]

Hi,

I just want to point out that OR has a few logic errors, and for the purpose of this thread and the discussion of AI behaviour, the logic error is about trains chasing trains ( whether it's an AI chasing an AI... or a player train chasing an AI or an AI chasing a player train ) where the chasing train will always take the passing siding... which means the chasing train will be put off of it's schedule. I tested it about a year ago and all my paths have passing paths, and every chasing train went into the siding... oh yes!!... I should mention that there was no oncoming traffic. I did test without passing paths and for the life of me cannot remember the outcome. For the doubters... create a test activity and see for yourself.

Bottom line... AI traffic will present some unpredictable results as it stands now.
Peter

Vince: Never saw anything as you describe in building, testing and running of the activities on the PRR Eastv2.

Me neither (in testing activities), although I don't doubt what you observed...what my questions are...
1. How did you set up the testing environment?
2. Was there something in your method of testing that provoked the result you observed?
3. Can you provide a testing environment that anyone could use to repeat your results?

[roeter]

Hi,

I just want to point out that OR has a few logic errors, and for the purpose of this thread and the discussion of AI behaviour, the logic error is about trains chasing trains ( whether it's an AI chasing an AI... or a player train chasing an AI or an AI chasing a player train ) where the chasing train will always take the passing siding... which means the chasing train will be put off of it's schedule. I tested it about a year ago and all my paths have passing paths, and every chasing train went into the siding... oh yes!!... I should mention that there was no oncoming traffic. I did test without passing paths and for the life of me cannot remember the outcome. For the doubters... create a test activity and see for yourself.

Bottom line... AI traffic will present some unpredictable results as it stands now.

Peter

It happens if the chasing train tries to clear the route through the siding area while the preceding train has not yet cleared the main line in that area. As the main path is not available while trying to set the route, the path selection logic selects the alternative path.
It only occurs when the option 'location linked path processing' is switched on, and alternative paths are defined for that location.
The problem has been around ever since 'location linked path processing' was introduced and has been known for some time.
It's somewhere on the list of things to do, but that's a very long, long list.

Regards,
Rob Roeterdink

[roeter]

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

Basically, what happens when a train is starting is that the program increases the TrainThrottlePercentage (this, and TrainBrakePercentage, are the only controls available to regulate an AI train). Simplified physics are used to move the train.
The program checks the train's speed and acceleration, and if these are not as what is expected, the program will keep increasing the TrainThrottlePercentage. When the percentage has reached 100% and the train is still not moving as expected, the program 'intervenes' and just forces the train to move.
So if the train does move properly before the throttle percentate reaches 100%, true physics are used to move the train (be it a simplified version as compared to the player train). In that situation, you may indeed see a difference in acceleration between lightweight and heavy trains.
Braking is more or less the same, but the control is more strict to prevent run-away trains.

Regards,
Rob Roeterdink

[tooltroll]

Basically, what happens when a train is starting is that the program increases the TrainThrottlePercentage (this, and TrainBrakePercentage, are the only controls available to regulate an AI train). Simplified physics are used to move the train.
The program checks the train's speed and acceleration, and if these are not as what is expected, the program will keep increasing the TrainThrottlePercentage. When the percentage has reached 100% and the train is still not moving as expected, the program 'intervenes' and just forces the train to move.
So if the train does move properly before the throttle percentate reaches 100%, true physics are used to move the train (be it a simplified version as compared to the player train). In that situation, you may indeed see a difference in acceleration between lightweight and heavy trains.
Braking is more or less the same, but the control is more strict to prevent run-away trains.

Regards,
Rob Roeterdink

Thank you for the info. It's about what I expected, given the behaviour in-sim. Next silly question: You say that "The program checks the train's speed and acceleration, and if these are not as what is expected, the program will keep increasing the TrainThrottlePercentage." and so I'm wondering how the program knows what to "expect"? Could we just lower its expectations?

Also, how fast does it advance the throttle? A player should be advancing the throttle notch by notch, waiting for the RPMs to increase, or so my stack of EMD/GE operator's manuals suggest. Seems like the AP goes from idle to notch 8 almost instantaneously, and keeps it there until the speed limit is reached. Would it break anything to slow the throttle action to something more prototypical? Surely that'd just need a delay loop to prevent the throttle from advancing for a few seconds after the last advance? If there already is a delay, could it not be lengthened a few seconds more? (I get that the brakes need to be a bit 'prompt' to prevent runaways/collisions.)

Bob

[dcarleton]

You know how OR will load a consist even when a car is missing from the trainset folder? It will just load that train without that car. One car shorter. But what happens if all the locomotives from an AI consist get inadvertently deleted?

[peterman]

It happens if the chasing train tries to clear the route through the siding area while the preceding train has not yet cleared the main line in that area. As the main path is not available while trying to set the route, the path selection logic selects the alternative path.It only occurs when the option 'location linked path processing' is switched on, and alternative paths are defined for that location.The problem has been around ever since 'location linked path processing' was introduced and has been known for some time.It's somewhere on the list of things to do, but that's a very long, long list.Regards,Rob Roeterdink

Hi Rob,
I'm assuming that... "the preceding train has not yet cleared the main line in that area" is in reference to the NumSigAhead (4). If so, in my case, the preceding train is outside that number.

Your statement... " It only occurs when the option 'location linked path processing' is switched on "... I believe is incorrect. I don't have that option checked nor have I ever had it checked. It causes problems with switching activities. I first noticed what I'm talking about around the time that random activity and random weather were introduced. Don't quote me on that. 8-)

Gerry,

Pick a route, make sure it has passing sidings, add an AI that goes from one end to the other. Now add a player train that follows the same path and have it start 5 - 10 minutes after the AI. Start OR and drive your train or watch it on the track viewer.

Peter

[R. Steele]

...Gerry,
Pick a route, make sure it has passing sidings, add an AI that goes from one end to the other. Now add a player train that follows the same path and have it start 5 - 10 minutes after the AI. Start OR and drive your train or watch it on the track viewer.
Peter

Thank you Peter, will do.
Regards, Gerry