No, I can see where it'd still be useful. Sure, you've got some fancy paths with pickups and dropoffs, etc. But at the same time, there's still some mainline traffic 'through' trains going past, and reusable paths for those makes a lot of sense.
Bob
Announcement
Collapse
No announcement yet.
One activity with Fall Harvest on CN Ruel Subdivision
Collapse
X
-
If I made lifeless point A to point B activities, I might agree with you. But we are getting into more and more features like where an AI train can drop a locomotive to be added to your mechanically stricken train, or you can have a planned insertion of mid-train helpers totally by AI, where the odds of one AI path reusable in many activities seems like a moot gesture.
Leave a comment:
-
Originally posted by geepster775 View PostIsn't that the predicament that happens when you run the Rockslide activity on Feather River? OR simply routes the follower train onto the least congested route available.And doesn't that problem go away when the following trains lose their needless passing paths? Is it written in stone anywhere that all AIs must have passing paths at all sidings, or is that belief just another MSTS user practice hangover?
It may not be written in stone, but I would rather have one path that covers all possible meets that becomes re-usable in any activity, than to have hundreds of paths that accomplish the same thing.
Peter
Leave a comment:
-
Isn't that the predicament that happens when you run the Rockslide activity on Feather River? OR simply routes the follower train onto the least congested route available.
And doesn't that problem go away when the following trains lose their needless passing paths?
Is it written in stone anywhere that all AIs must have passing paths at all sidings, or is that belief just another MSTS user practice hangover?
Leave a comment:
-
Originally posted by peterman View Post...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
Regards, Gerry
Leave a comment:
-
Originally posted by roeter View PostIt 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
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
Leave a comment:
-
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?
Leave a comment:
-
Originally posted by roeter View PostBasically, 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
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
Leave a comment:
-
Originally posted by tooltroll View PostSo 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
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
Leave a comment:
-
Originally posted by peterman View PostHi,
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 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
Leave a comment:
-
Originally posted by peterman View PostHi,
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.
PeterVince: Never saw anything as you describe in building, testing and running of the activities on the PRR Eastv2.
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?
Leave a comment:
-
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,
Leave a comment:
-
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
Leave a comment:
-
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.
Leave a comment:
-
Originally posted by tooltroll View Post"...................snip....................If traffic ignores physics, then all the player interactions with traffic won't be accurate. .....................................snip......... .................... Bob
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,
Leave a comment:
Leave a comment: