[R H Steele]

Another topic in the discussion area prompted me to go back to the PRR East and work on some more activities for it. In doing so I spotted quite a few track node errors and other track errors in the OR log. More than I've ever seen on other routes. Although, these errrors do not appear to affect running the route in Open Rails - in fact it runs rather well - I was wondering - just curious - if it is possible or warranted to fix them?

I did a little reading and it found that track nodes are of three types, switches, ends of track sections, and crossovers. All fixes would have to be done within the RE. So I suppose my question is moot since the route does run well and I do not know a thing about the RE. I would like to thank all the people that contributed to this project. Reading through the names contained in the route docs I spotted quite a few that post here at Elvas. I would suspect that a route project of this magnitude would be difficult and prone to some errors (especially using the RE - how in blazes did this route get built, anyway??)

Lastly, spent a few days repairing paths, installing most of the activities I found (good packs at CLW) and running some trains, decided it is a noteworthy accomplishment.

Attached File(s)

•  OpenRailsLog.txt (31.41K)
  Number of downloads: 140

[EricF]

I'm no expert on the route, not by a long shot, but I recall from its own documentation and some other forum threads in the foggy past that the construction of the route involved merging several smaller routes, and a lot of TDB corruption that had to be repaired laboriously by hand. Enough that it is recommended never to run Route Riter corrections on the route, and to expect paths that can't be used in certain places.

OR appears to be noting the areas that it spots are "wrong" but it seems to be doing an fine job of coping with it all. My hat's off to the developers; graceful error handling is rarely easy to program well. That's what makes MSTS so darn unpredictable at times. If it encounters an error condition, to appears to try it's level best to just ignore it and go on its way -- until it encounters an error it has no clue what to do with. At which point it throws the computer equivalent of a tantrum... and will gleefully take all your work with it in the editors... OR, ont the other hand does so much better at being consistent in handling things -- but that takes so much more work to provide ways for it to politely slide past sticky situations when confronted with less-than perfect input. (And that's a good part of the reason why I don't program for a living. I do like to hang onto what little sanity I have...)

[R H Steele]

I agree, I'm constantly impressed by how OR handles all the situations thrown at it in the various routes constructed for MSTS in the past decade or so. The credit goes to the Dev Team Members (past, current and future) that generously devote their time to this effort.

I usually try to sort out the sound stream errors, and other errors that I can fix, I've always thought (don't know if it has any basis) that the less errors OR encounters the better it will work.

[RTP]

Please, do not touch PRR East.
This route is miraculously stable.
And, in my opinion one of the best.

Regards.

[R H Steele]

No worries, just trying to adjustment my own copy.