[roeter]

It appears that version 3863 is causing problems with timekeeping for AI trains in activity mode.
A little background information.
Control of AI trains when approaching a stop location (signal, station or waiting point), or some other restriction (speed limit), is a two-step action : first, a 'trigger' is set at a specific distance from the stop or restricting location, this 'trigger' informs the train is must prepare to stop or slow down. When the train receives that trigger, it changes its state to 'braking' mode.

When testing the changes for version 3863 I found two errors in this logic. One error was in the calculation used to determine the trigger point distance - the result of this was a too short distance on the approach to the restriction.
The other error was in the 'braking state' logic, it calculated a too restrictive speed on the approach.
These two errors kind of evened out - the late trigger was compensated by running at a too low speed, but, in reverse, the late trigger also prevented too much loss of time because of this low speed. It all seemed to work correct, but when looking in detail at the train's behaviour there was a distinct 'break' in speed at the moment of the trigger, in particular for speed restrictions, with speed dropping 30 mph or more in just a few seconds.

The error in the trigger point calculation really needed correction, but I did not change the braking logic for activity mode as I feared it would have too great an impact on the behaviour of trains in activities.
That was a mistake - by removing the error in the trigger point, trains now run for a much longer time on the incorrect low speed, and this is causing timing problems.
Together with Carlo, we're working to sort out this problem as soon as possible.

Regards,
Rob Roeterdink

[Csantucci]

That should have been fixed in x.3868, but don't pretend matching at the second with x.3862...