[Csantucci]

No, it hasn't been committed yet. It's in the hands of James.

[Csantucci]

The feature is now available starting from release 1.3.1-12.

[dforrest]

Csantucci, on 25 January 2019 - 12:22 AM, said:

The feature is now available starting from release 1.3.1-12.

Thank you.

[dforrest]

This has resolved the problem I was having with reverse points in three particular activities written for the revised Potteries Loop route. However, there appears to be a more general problem in running activities written and running well in MSTS, in Open Rails. In many instances it is necessary to "anticipate" the reverse point location. That is, to reverse before the reverse point arrow actually disappears. In some instances, if you do wait for the reverse point arrow to disappear, you are not given the correct path when you do reverse.

[copperpen]

The only time I find that happening is when the EOT authority is at or very close to the RP which I think is caused by placing the RP too close to a switch. Once you are past the EOT you are considered to be OFF PATH which is then fatal for the activity, unless you happen to know the path and what happens in the rest of the activity. Losing the path also affects the interlocking along the path because the logic no longer knows where you are supposed to be going.

[dforrest]

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

Attached File(s)

•  OpenRailsLog.txt (47.96K)
  Number of downloads: 284

[dforrest]

Can someone please help with the problems detailed in the log attached to my previous post, or should I open a new thread?

[Csantucci]

Hi David,
unfortunately I can't be of help here. The crash has occurred within the sophisticated and valid deadlock logic code, which I don't know (neither the code nor the logic).

[vince]

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 (4.76K)
Number of downloads: 376

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

[dforrest]

Thanks Vince for this information. I will be investigating this in as much details as i can. I looks as if these is a lot of work to be done on the route.