One activity with Fall Harvest on CN Ruel Subdivision

[cn bala]

I do have a question for anyone to see if you have the same problem as I have. The activity is Fall Harvest which run east from Foleyet to Capreol. I see that the first meet did not happen at Tionaga with first AI train which is [b]CN 203 Windsor to Vancouver. When the player train, CN 880 (Fall Harvest player train is getting closer to Tionaga and the first AI train with CN 203 Windsor to Vancouver disappear from the Dispatch Viewer. I understand that the player train will be stopping at Tionaga but the signals changed to green and the first AI train is not at Tionaga at all. I am not sure why is this happening with this first meet? I run Open Rails Simulator with " AutoPilot " for this activity. Is anyone else have the same problem or just me.

Thank you,

John

[geepster775]

It's not just you.

I saw something similar when running the 418 activity.

I was watching the dispatcher screen as the 418 was approaching the meet at Kukatush with the 201 that was holding the main. On the DS screen I could see 203 (the problem train) meeting the 204 (the train that overtook me at Foleyet) at Tinoaga siding ahead, and I figured I would meet 203 at Kukatush too. But just before I diverged into the siding at Kukatush to meet the 201 the 203 just vanished at Tionaga without completing its meet with 204, giving 204 the signal to carry on ahead of me. Since the second meet was now a bust I had a green to exit and when I got down to Tionaga myself I was routed through the siding where I met nobody.

I checked the path for 203 and he was supposed to run the entire route and not terminate early.

I did not have logging running during that run so I don't know if there would've been any barf in any log.


In the screens the background has 418 approaching 201, the meet at the left side of the DS screen inset, while 203 vanishes during its meet on the right side.

[TrainSimulations]

John,

Try running the activity, but actually be in control of the train. You can use the time acceleration to speed it up a bit, but you don't want to impact the physics by adding too much time acceleration. You will find that the meet should take place at Kukatush, and not Tionaga. The autopilot isn't impacted by train physics, so it will get up to 60 mph in no time, when in fact, you won't ever get to that speed if you are in control of the train and you have the advanced adhesion model enabled.

Cheers,
Jason

[cn bala]

Thanks to you and I think that the team of Trainsimulations should look into this scenario. Hopefully they can fix the problem with this.

John

[baldwin]

John
Jason has already told why the activity is failing, and also provided the fix. Turn autopilot off and control the train yourself.


If it is fixed to run under autopilot, then those who like to have control of the train will get problems as well.

[cn bala]

I did not see Jason's message as I replied to Geepster775 message and that is why I missed his. One thing I am not sure what Jason mentioned about time acceleration in Open Rails. I thought that can't be done in Open Rails only with MSTS? Is that correct?

Thank you,

John

[derekmorton]

OR Manual
7.12.1
time acceleration

[cn bala]

Thanks Derek for the information to find in Open Rails Manual. I did search this and don't see but must be overlook the index of the OR Manual. Will look up shortly in OR Manual.

John

[daniellouwrens]

John
Jason has already told why the activity is failing, and also provided the fix. Turn autopilot off and control the train yourself.


If it is fixed to run under autopilot, then those who like to have control of the train will get problems as well.

But if OR and the activity were correctly configured it should run correctly either way.

I really enjoy running acts in Autopilot but so far have only found one "freight" act that works well until the third of fourth pickup
then it goes awry.

However I have found that most passenger train acts work well and I can "train fan" view them which I enjoy.

My point is OR has an Autopilot function so the best outcome is to make it work 100%, this is an aim, not a criticism,
I am fully aware that OR is an amateur, as in not paid, venture but so many fixes have been applied because of a request.

Regards to all OR contributors

Daniel

[R. Steele]

I believe there is a card on the OR Trello board for "cruise control" which would be more sophisticated than the current autopilot...which was expressly designed for the purpose of speeding up activity testing. If used correctly for testing it works well, saving the activity creator some time and trouble. However, when it is used to run an activity, it can and will present problems that may not normally happen if the activity is run with normal controls...Jason mentioned this in an earlier post.

Autopilot, unrealistically, keeps the player train at speed, no matter what...physics do not play a role.

[geepster775]

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.

[R. Steele]

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.

[roeter]

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

[tooltroll]

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

[geepster775]

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.