Open Rails

Bug #1310587
Comment #25

Comment 25 for bug 1310587

Revision history for this message

Carlo Santucci (carlosanit1) wrote on 2014-11-14:

#25

EMU1.patch Edit (4.4 KiB, text/plain)

Rob,
I too went on analyzing the issue.
First of all, there is an error in the .eng file, because MaxForce is set to 26 and MaxContinuousForce is set to 51. MaxForce must be always more or equal MaxContinuousForce. So I set both at 51, and I attach the patch Openrails.zip, that has to be unzipped in RATP_SPRAGUE, not modifying existing files. Even so in my opinion the trains are underpowered, because also running the player train the acceleration is far too low for an (even old) metro train.
I attach here also the corrected sigfcg.dat file.
I went on analyzing the performance of the AI trains, and found some things that improve performance of the train. I have attached here a patch, that I would like to shortly discuss with you before uploading. As of now everything is under the compatibility flag, so it does not influence Timetable and working in non-compatibility mode. However, if you agree on some of these changes, the check for the compatibility flag can be removed.
First of all (lines 382 and following of AItrain.cs) I considered the category of EMU trains. Such category of trains has in general higher acceleration and deceleration values. So I have increased them for such trains - in a reasonable way.
Then I noticed that AI trains first decelerate very fast, and then roll for quite many seconds at about 30 Km/h. I investigated that, and noticed that this is due to the checks around line 2630. The formula computes a maxPossSpeedMpS with a 0.5 factor under the square root, which is the half of the value with which the point where deceleration begins was computed. So I increased it to 0.95 (1 would be the nominal value for a perfect braking).
Then (line 2874) I made two changes. First of all I removed the 0.5 correction factor, because else there is a double reduction - Efficiency and then such factor; then I increased the step size when in pre-update. In fact in pre-update there is an update only every 5 seconds. With a step size of 10 the throttle value increased quite slowly to the final value during pre-update.
For the same reason around line 3430 I increased the initial throttle step in acceleration state when in pre-update.
With these changes the activity runs well, even if trains are still delayed a bit with respect to MSTS.
By increasing MaxForce and MaxContinouosForce to 100 and MaxPower to 1000 things run even better, but not in pre-update.

Rob,
I too went on analyzing the issue.
First of all, there is an error in the .eng file, because MaxForce is set to 26 and MaxContinuousForce is set to 51. MaxForce must be always more or equal MaxContinuousForce. So I set both at 51, and I attach the patch Openrails.zip, that has to be unzipped in RATP_SPRAGUE, not modifying existing files. Even so in my opinion the trains are underpowered, because also running the player train the acceleration is far too low for an (even old) metro train.
I attach here also the corrected sigfcg.dat file.
I went on analyzing the performance of the AI trains, and found some things that improve performance of the train. I have attached here a patch, that I would like to shortly discuss with you before uploading. As of now everything is under the compatibility flag, so it does not influence Timetable and working in non-compatibility mode. However, if you agree on some of these changes, the check for the compatibility flag can be removed.
First of all (lines 382 and following of AItrain.cs) I considered the category of EMU trains. Such category of trains has in general higher acceleration and deceleration values. So I have increased them for such trains - in a reasonable way.
Then I noticed that AI trains first decelerate very fast, and then roll for quite many seconds at about 30 Km/h. I investigated that, and noticed that this is due to the checks around line 2630. The formula computes a maxPossSpeedMpS with a 0.5 factor under the square root, which is the half of the value with which the point where deceleration begins was computed. So I increased it to 0.95 (1 would be the nominal value for a perfect braking).
Then (line 2874) I made two changes. First of all I removed the 0.5 correction factor, because else there is a double reduction - Efficiency and then such factor; then I increased the step size when in pre-update. In fact in pre-update there is an update only  every 5 seconds. With a step size of 10 the throttle value increased quite slowly to the final value during pre-update.
For the same reason around line 3430 I increased the initial throttle step in acceleration state when in pre-update.
With these changes the activity runs well, even if trains are still delayed a bit with respect to MSTS.
By increasing MaxForce and MaxContinouosForce to 100 and MaxPower to 1000 things run even better, but not in pre-update.