Hang starting some activities in Paris Metro

[Werner Heer]

I realize that not start some activities in the route RFSP (Paris Métro) since OR_Revision 1911.
There was no change in the task. Where is the problem? Thank you.

[r.roeterdink (r-roeterdink)]

Could you please try the latest version?
Also, could you please download that version from this site : http://james-ross.co.uk/projects/or/builds.
Those versions display line-numbers when there is a crash, and that helps a lot when trying to find the cause of a problem.
Thanks.

[Werner Heer (wehe-gmx)]

Thank you, Rob.
In the latest version ( 2193) it is the same bug.

[Werner Heer (wehe-gmx)]

Hello Rob
In OR_2193 and in the last official Version 2186 no error entry exists. The boot process will just hang.
Best reagrds, Avo

[Werner Heer (wehe-gmx)]

Sorry, wrong attachment (#5)!

[r.roeterdink (r-roeterdink)]

Seems to be a loop rather than a crash, just to make life difficult ...
I have that route somewhere so I will take a look at it.

[Werner Heer (wehe-gmx)]

Thank you, Rob for your effort.
The link to the route:

http://funtrain.net/fr/simulateur-de-train/microsoft-train-simulator/lignes/add-on-12/

Greetings!
Werner

Am 24.04.2014 16:02, schrieb r.roeterdink:
> Seems to be a loop rather than a crash, just to make life difficult ...
> I have that route somewhere so I will take a look at it.
>

--
Diese Mail wurde mit Thunderbird auf Linux-Mint erstellt.

[r.roeterdink (r-roeterdink)]

Tried to reproduce the error but the activity ran in version 2223 without any problems - started as expected.
All AI trains were running normally.
Could you try again using this version?

[Werner Heer (wehe-gmx)]

In Release 2223 as well as 2229 all activities start but 14 of 28 activities not yet run correctly.
I put the following faults:
- The timetable of the AI ​​traffic is retarded
- AI on the wrong track (Fig. 1)
- False cab side (Fig. 2)
- Message (Fig. 3)
- Broken driving route in Dispacher (Fig. 4).

What additional information should I provide?

[Carlo Santucci (carlosanit1)]

Fig. 4 is not a bug. The path extends itself with the train motion.
Pls. check the other problems with an actual release, like 2637 or later, by setting the "Enhanced Compatibility with MSTS activities" option in the Experimental options.
If problems persist, pls. open a bug report for each separate problem.

[Werner Heer (wehe-gmx)]

Test with OR-2637 and with routes RFSP-V3_6 for Open Rails ( alternative route: http://funtrain.net/fr/simulateur-de-train/microsoft-train-simulator/lignes/add-on-12/ ):
Exemples: Activity L01V1 (Fig.1) and Activity L06V (Fig 2).
In both examples, the above mentioned problems persist.

avo

[Carlo Santucci (carlosanit1)]

Hi Werner,
I downloaded and installed the route (the OR version of course), and started the L06V2.act activity with a release that is 2639 plus a patch that has no influence on this route.
First two points:
1) in line 1157 of file sigcfg.dat there is an evident error (that is shown in the OpenRailsLog.txt file): line
    Radius "RATPltex"
should clearly be
    Radius ( 0.6 )
2)there is an important difference between my logfile and your logfile: my logfile does not have the lines
Warning: Cannot place AI train L06V2V1 at time 11:53:00
this means that the related train runs in my case, and doesn't run in your case. Very strange. Maybe you have some different setting?
I then started the L01V02.act activity without problem
 I attach here my two logfiles after the correction of point 1. You can compare your settings with mine
Can you tell me how long I have to drive the two activities to find AI trains on wrong tracks or things like that?

[Werner Heer (wehe-gmx)]

Hello Carlo
Now I have RFSP (OR) reinstalled and tested with OR-2639. The sigconfig (line 1157) was corrected to 0.6.

General:
1. The AI does not move or only very slowly (Dispacher).
2. No oncoming traffic in league play. This is new to OR-2637!

To L06V1:
Start now ok / after about 2 minutes a red signal. It does not open.

To L06V2:
Start now ok / after about 4 minutes (station Picpus) red signal. It does not open / Track Monitur remains frozen.

I do not know if it's worth it to continue to trial and error. A viable solution I see is to program new the AI traffic for each activity without ring road.
In addition, the MSTS still remains. With it the interference are not available.
My Settings and log files I send via PM.

Regards
Werner

[Carlo Santucci (carlosanit1)]

Thanks Werner,
with this info I am able to check if I have the same problems and if I can slowly solve them.
Regards

Carlo

[Carlo Santucci (carlosanit1)]

Hi Werner,
I have tested L06V2. The signal opens after about 5 minutes, and you can run further, then you have again a long red, and so on. So there is no hang, simply things occur very slowly. As you also mentioned, the problem is that AI trains simply run too slowly (especially deceleration begins much before the station and lasts much time. Acceleration is slow too). It's something a bit outside of my know-how, so I don't know if I am able to modify that.

[Carlo Santucci (carlosanit1)]

Edit, I tested L06V1, not L06V2.

[Werner Heer (wehe-gmx)]

Hello Carlo,
now is absolutely clear, the problem comes from the automatic traffic.
Let the matter rest provisionally. Maybe bring future development steps of improvement.
You can see the routes even without AI traffic.
Thank you very much for your effort!

Werner

[r.roeterdink (r-roeterdink)]

I've had a look at this and there are quite a number of issues here.

First is a problem with a change which was made some time ago.
This change for AI trains holds AI trains at station stops if the exit signal for that station is at danger. But on Line 6, there are quite a number of sections with multiple stations. This caused the system to lock. I will commit a patch to sort this problem later today.
Even allowing the train to depart, however, did not fully sort this as in STOP state, the train will not move if the first signal ahead is at danger. I will add another patch which will allow trains to move if the signal is sufficiently far ahead (10 x safety distance).

The low speed of AI trains is not a program error as such. The reason is the short distance between station stops. The default acceleration and decelleration values as used to control AI trains are clearly not adequate for this type of service.
What happens is that when trains depart from a station, they almost immediately start braking for the next stop. On longer sections the trains do reach the max. speed of 70 km/h.

This low speed, however, is causing a problem on Line 6, because there is a long section without signals. There are no intermediate signals from just beyond Pasteur to the exit signal at Saint-Jacques, a section with 5 intermediate stations. The player train is allowed about 7 mins. for this section, but AI trains need 13 mins. from start at the signal beyond Pasteur, to clearing the section beyond Saint-Jacques. Clearly, if you have trains running at 7.5 mins. interval, but a section for which they take 13 mins. to clear, you have a problem. With 12 trains ahead of the player train (activity Loi6V2), you're going to have a looooong wait before that queue ahead of you has been cleared.

How to sort this is a different matter. Clearly, the control parameters should somehow be made variable, but which parameters need to be variable, how they have to be defined (actual value or multiplication factor), and where they must be set (as user options, per route or per consist) are issues which have to be dealt with. There are no equivalent MSTS parameters so these settings must be OR-specific. I'll open a discussion on Elvas Tower to see what the general thoughts on this are.

Finally, two notes on the route itself.
There are two errors in the sigscr.dat file which need to be corrected. Both are real errors, i.e. they are not syntax issues which MSTS supported but OR does not - in both cases the statements are incorrect.
The default station stop dwell times in the tdb are set to 180 secs. That's way too long for these stops. The activities generally set more adequate stop times, but it will certainly do no harm to set the default dwell times to 20 or 30 secs. for all stops.

And, by the way, if you still want to run these services with AI trains, than, at least for Line 6, generate trains at 15 mins. intervals - that works well.

[Carlo Santucci (carlosanit1)]

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.

[Carlo Santucci (carlosanit1)]

I have uploaded the patch of post #25 in release 2650.
Werner, can you have a run on line 6 with such release? Rob's improvement is always operating; to have my improvement operating you have to select the two Experimental Options "Enhanced compatibility with MSTS activities" and "No forced red at station stops".
Pls. apply also files of posts #26 and #27.

You shouldn't have red signals now. You will meet countertraffic some minutes later than in MSTS, but I hope it's not so bad.

Pls. report here.

[Werner Heer (wehe-gmx)]

Carlo
the journey L06V2 is executed.
OR 2650, options as required, replaced 2 files.

KLEBER: Arrival 12.03, departure signal red
KLEBER: Departure 12.11, " yellow, next red
BOISSIERE: Arrival 12.13, " red
BOISSIERE: Departure 12.23, " yellow, next red
etc.
During this time no oncoming traffic has occured.
The automatic traffic is much too slow.

[Carlo Santucci (carlosanit1)]

Werner,
sorry for inconvenience.
From your logfile errors I see that I was not clear about how to install the decompressed OpenRails.zip. It must be installed in the RATP_SPRAGUE directory, but taking into account that in the .zip file the two .eng files are within an OpenRails directory.
In other words at the end there must be in RATP_SPRAGUE an OpenRails directory, and in the OpenRails directory the two new .eng files.
Instead as you probably did, you overwrote the two original .eng files in RATP_SPRAGUE, that instead must remain unaltered. As maybe you haven't backed up them, I attach them here (to be decompressed in RATP_SPRAGUE).

This said, nothing changes in L06V2. In fact, due to long line parts without signals, as Rob noted, the AI traffic runs very slowly in OR.
I again wasn't clear, because L06V1 works well. You can test it.
I tested now some other activities:
L11 voie 1 is OK
L11 voie 2 has no traffic, therefore OK...
L5 voie 2 is OK.
I am now trying to understand what happens in L5 voie 1, where there is an AI train in front of the player train, as you mentioned in one of your first posts.

[Carlo Santucci (carlosanit1)]

Tested also L10 voie1 and voie2, should both work.
In the case of L5 voie 1 there is probably an error when AI trains change track and reverse at the end of their forward run. Only AI trains that did that before the player started are OK. Trains that have to do that after player started remain stuck before the trailing switch. This is probably a bug, but I don't know if I will have time to check it. The train in front of the player train is an AI train waiting to start (in the same direction of the player train). The problem is that, as soon as the AI train starts, another is created in that point and so the player train never has clear way.

[Werner Heer (wehe-gmx)]

Carlo,
thanks for the tip on installing your OpenRail folder within Sprague. I've corrected the error and then tested L06V2 again.
The activity works better now with the restriction that everything is slowed down. The first AI crosses at 17 minutes past the start.
L06V1 works (at the beginning!), because less trains go forward.

I have made with L06V2 two more tests:
Test 1: Start time of the players train at 12.30.
Consequence: Less waiting times at stations, AI cross earlier.
Test 2: L06V2 completely rewritten.
The files I send via PM.
I think this way could provisionally satisfy.

Werner

[Carlo Santucci (carlosanit1)]

Thanks Werner,
it's nice that now, due to Rob's and my changes, at least a part of the activities are playable.
Can we consider the bug report closed now?

[Werner Heer (wehe-gmx)]

Thank you Carlo, thank you Rob,
for your great patience in analyzing and improving a rather unusual problem case.
The bug report can be closed.

Werner