[dforrest]

 vince, on 03 February 2019 - 03:05 PM, said:

Hi David,

Perhaps I can offer some advice after reading through your log and reading Carlo's response today.
I too was plagued by excessive database errors in the PRR East route just as I see in your log. These errors contributed to the failings running activities in Open Rails just as you have experienced.

It was not until I dug deep into the route and was able to correct all the logged database errors of the same type you are seeing.
My activities didn't work reliably until I eliminated all these errors. It seems the Open Rails code was getting bogged down with error processing and such (dont know exactly what) that the activity running suffered random failures. I was able to use TSRE to eliminate these errors but it took a while for sure . . . Please see my example OR Log. TSRE is the only way I know of to eliminate errors of thsi sort plus a lot of detective work.

prrErrors.zip

I respectfully suggest you get the route errors cleaned up first before you try debugging activity running.

You really don't know why that the activities fail but you DO have a list of database errors in the log that could be partly to blame and in my opinion should be fixed first.
Kind of like you never go build a house on a crappy foundation.

Fixing the route will involve you slogging through the databases and cleaning them up and is a royal pain and boring to boot!
TSRE was the only way I was able to fix these errors. Thank you Goku!

It took me two years to fix the PRR East's databases and now the route is in pre-release beta test as the PRR_East-V2.
Ignore the logs complaints about steam code and shape file problems. It's the track node errors that are serious and must be eliminated before you build activities.
Good hunting.

regards,
vince

Can vince or anyone else give me advice on how I should go about trying to resolve this problem?

[Coolhand101]

The majority of routes have them kind of errors in the TDB or RDB. I believe out of 50 or so routes i have, only one or two are totally clean of TDB and RDB errors. Looking through your log, the main cause is right at the bottom.

Be careful if you edit the route in RE. The majority of those kind of TDB or RDB errors are track/road types that cannot be selected in RE without that dreaded MSTS bug of 'unable to select track/road piece'.
It is possible, but it's a lot of messing about manually editing the databases. It appears with TSRE, the problem pieces and be easily edited and corrected!

I will finally be installing the v2 of the Potteries loop route tonight, so I can maybe assist with future problems.

About the activity, does it involved reverse points and coupling/uncoupling with signals and track nodes in close proximity?

About these errors

Information: Train PLAYER (0) : Looped at 1396

Warning: Train 0 service PLAYER, reversal or end point off path; distance to reversal point set to -1

Warning: Train PLAYER (0) passing signal 177 at -125.9 at danger at 0.57

The bottom one is self explanatory, but the other two are in my own activity in another route with around 12 reverse points. The route is a 10 mile branch line mostly single track. The activity works 100%, but I'm still unsure what those errors mean, and what OR is doing to correct it?


Thanks

[dforrest]

Thanks Coolhand101. I will now try and analyses the problem further. To answer your question, yes it does have (many) reverse points and (much) coupling/uncoupling with signals and track nodes in close proximity.

There is also a patch to version 2 of the Potteries Loop to be downloaded.

[copperpen]

Unlike Vince, I dont feel there are enough track database warnings to cause OR to toss the toys out of the pram, but I do find these two warnings of interest

Warning: Train 0 service PLAYER, reversal or end point off path; distance to reversal point set to -1

Warning: Train PLAYER (0) passing signal 177 at -125.9 at danger at 0.57

These I think show that the start at least of the activity probably needs to be remade for OR.

[dforrest]

 copperpen, on 13 February 2019 - 10:19 AM, said:

Unlike Vince, I dont feel there are enough track database warnings to cause OR to toss the toys out of the pram, but I do find these two warnings of interest

Warning: Train 0 service PLAYER, reversal or end point off path; distance to reversal point set to -1

Warning: Train PLAYER (0) passing signal 177 at -125.9 at danger at 0.57

These I think show that the start at least of the activity probably needs to be remade for OR.

The problem occurs not at the start of the activity but about half-way through it.

[Coolhand101]

 copperpen, on 13 February 2019 - 10:19 AM, said:

Unlike Vince, I dont feel there are enough track database warnings to cause OR to toss the toys out of the pram, but I do find these two warnings of interest

Warning: Train 0 service PLAYER, reversal or end point off path; distance to reversal point set to -1

Warning: Train PLAYER (0) passing signal 177 at -125.9 at danger at 0.57

These I think show that the start at least of the activity probably needs to be remade for OR.

I agree.

Do you know what the 'reversal point set to -1' and the 'player looped at xxxx' terms mean? In my own activity, it all appears to work 100% with those warnings.

Thanks

[roeter]

The 'loop at' error is a bit of complex situation.
It can occur when a train is in 'Node' control (i.e. not under signal control).
The error is reported when the train tries to extend the cleared route ahead, and finds a section which is allready part of the existing cleared route. That can be a 'fatal' loop, for instance when the train is routed back unto the same path as where it is now, and in the same direction. But it can also occur when the route is reset, e.g. when attaching to static stock which is located short of the actual reversal point. The train is set to a special state (Looped), which means it is handled by special logic which tries to sort the loop and restore proper path. Usually this works well and the loop causes no problems. Occasionally, it can cause problems, in particular in routes where the train does indeed loop back unto its own path.

Regards,
Rob Roeterdink

[dforrest]

 roeter, on 13 February 2019 - 01:37 PM, said:

The 'loop at' error is a bit of complex situation.
It can occur when a train is in 'Node' control (i.e. not under signal control).
The error is reported when the train tries to extend the cleared route ahead, and finds a section which is allready part of the existing cleared route. That can be a 'fatal' loop, for instance when the train is routed back unto the same path as where it is now, and in the same direction. But it can also occur when the route is reset, e.g. when attaching to static stock which is located short of the actual reversal point. The train is set to a special state (Looped), which means it is handled by special logic which tries to sort the loop and restore proper path. Usually this works well and the loop causes no problems. Occasionally, it can cause problems, in particular in routes where the train does indeed loop back unto its own path.

Regards,
Rob Roeterdink

Rob, I believe that all of the criteria you have described are applicable the this actual problem. The strange thing to me is also that MSTS handles the situation with no problem.

[roeter]

 dforrest, on 31 January 2019 - 04:45 PM, said:

The activity is crashing part way into it. Attached is the log.

This crash rather baffles me. On the line which is indicated where the index is out of range, there is no array or list at all - it's a call to a method, without return value or parameters.
It could ofcourse be that the version you are using is different from mine, but it is the correct method in which the crash occurs, and also the next line on the stack is the correct location of that particular method call. As far as I know, this code has not changed for a long time, I checked various versions of the code and all came up with the same line.
It could be that the crash is caused by some of the other issues mentioned above, such that if these issues are addressed the crash also no longer occurs.
If not and the crash persists, it looks like it will need 'hands on' debugging to find out what's going on.

Regards,
Rob Roeterdink