[gpz]

Variable1 is calculated by this equation:

            // Variable1 is proportional to angular speed, value of 10 means 1 rotation/second.
            Variable1 = (Simulator.UseAdvancedAdhesion ? LocomotiveAxle.AxleSpeedMpS : SpeedMpS) / DriverWheelRadiusM / MathHelper.Pi * 5;

From this line only the LocomotiveAxle.AxleSpeedMpS is questionable whether calculated for AI locomotives, I think. Unfortunately I will not be able to look on this in the next couple of weeks, so if someone would like to drop a fix, feel free. Maybe just a test is needed to drop in near to Simulator.UseAdvancedAdhesion, for using just the SpeedMpS for AI locomotives.

[James Ross]

 gpz, on 15 August 2014 - 04:30 AM, said:

Variable1 is calculated by this equation:

            // Variable1 is proportional to angular speed, value of 10 means 1 rotation/second.
            Variable1 = (Simulator.UseAdvancedAdhesion ? LocomotiveAxle.AxleSpeedMpS : SpeedMpS) / DriverWheelRadiusM / MathHelper.Pi * 5;

From this line only the LocomotiveAxle.AxleSpeedMpS is questionable whether calculated for AI locomotives, I think. Unfortunately I will not be able to look on this in the next couple of weeks, so if someone would like to drop a fix, feel free. Maybe just a test is needed to drop in near to Simulator.UseAdvancedAdhesion, for using just the SpeedMpS for AI locomotives.

I could be mistaken, but I seem to recall that AIs do not use the advanced adhesion at all - so you'd be right that LocomotiveAxle.AxleSpeedMpS is not used/set and we should drop back to SpeedMpS for AIs.

[midneguy]

I just wanted to give a little recognition to Peter and thank him for addressing this problem http://www.elvastower.com/forums/public/style_emoticons/default/sign_thank_you.gif

I finally took the opportunity to test this, and I have to say I was delighted to confirm that my AI steam locomotives (The Frisco 1500's in this case) do indeed make sound now, reflected by Variable2 varying with the AI engine load as shown in the sound debugging window. From what I've seen this is a huge leap over the clunky way MSTS handled AI steam engines, and it truly was fun to hear the volume change on the AI engine from coasting to pulling. Fantastic! :D

[rdamurphy]

James, you are correct. Rob disabled the advanced wheel slip for AI locomotives because many AI trains were crawling along because they had insufficient power to move the trains they were assigned to. MSTS AI ignores physics for AI trains, you can pull a 125 car loaded coal train with a handcar...

Robert

[roeter]

 rdamurphy, on 25 September 2014 - 09:48 PM, said:

James, you are correct. Rob disabled the advanced wheel slip for AI locomotives because many AI trains were crawling along because they had insufficient power to move the trains they were assigned to. MSTS AI ignores physics for AI trains, you can pull a 125 car loaded coal train with a handcar...

Robert

It's not only because of the power - and, actually, slipping as such is not disabled. It does not run as usual in advance physics, but when slipping occurs the effective power is reduced.
To keep the AI trains running, what happens is that if a train is accelerating and throttle is at 100%, but the train still won't move as expected, AI control 'overrides' the physics and sets the required acceleration and speed.

A major part of the problem is that AI trains are controlled at 'train' level, this is quite unlike the player train which is controlled by the player through the player engine.
Wheelslip is reported at engine level, and therefor to the player through the player engine, but for AI trains it is not reported back to the train. This means that AI control can not react to wheelslip (by reducing power) like the player can. Furthermore, sanding can not be controlled at train level, either.
In all, AI trains have a much greater chance of slipping, which, once it occurs, can not be controlled as it is not reported. The net result is that many AI trains are continuously slipping.
Some time ago I did a test, switching off the AI control acceleration override, but found that trains which were easily handled if run as player train, got hopelessly stuck on any gradient when run as AI train.

Another complication is that AI train behaviour during pre-update (i.e. before the player train starts) needs to be the almost same as during normal update - even more so for timetables as for activities. But the pre-update runs at 5 secs. interval, which is an interval the physics cannot handle. So a simplified calculation is used during pre-update. Without the override during normal update, the difference in behaviour between pre-update and normal update would be too large.

I would very much like to use real physics for AI trains even during pre-update, but this would require extensive changes to both physics and the pre-update logic.

Regards,
Rob Roeterdink

[gpz]

 roeter, on 26 September 2014 - 02:34 AM, said:

Furthermore, sanding can not be controlled at train level, either.

It is just an unimportant detail, but it is worth to mention just to the log that the current sander works by signalling an event to the train, which will call all locomotives to react. :sign_thanks: