Open Rails Crashes With An Error

**geepster775** · 12-31-2018, 07:42

That log is from version 0.9 from 5 years ago.

**longiron** · 12-31-2018, 08:24

Please update your installation to the latest v1.3.1 here: http://openrails.org/download/program/

**Vince** · 01-01-2019, 15:14

Hi Karthik90,
These errors will still be present in the newest version of OR. They are exactly what I am fighting right now!

Most of them I see are Phantom Signals, a signal item in the Track database but not in the world file or two signals occupying the same 'exact' coordinates.

The information provided by the Open Rails Log is good start but is lacking very important data, Tile & World file Coordinates.

Information: Signal 1642 ; TC : 9325 ; NextTC : -1 ; TN : 4835

TN, is basic, a TrNode.
We absolutely need tile coordinate information with this Open Rails Error Log.

Searching out along a track vector with some vectors having hundreds of TrItems would take weeks to track down just one of these "Information" lines.
Not 'Information' but an a fatal error!
How do I know this? ChiFan (Chuck Rickert) and I just yesterday did ONE ome the PRR-EAST-v2 route!

The TrNode (TN) info is good but needs coordinate information also.

With the proper coordinates is is so easy using Goku's editor (I'm running his experimental version TSRE5_v0.6963 which allows selection and deletion of these rogue Track Items, in this most look like duplicate signal and crossover coordinate errors.

Detailed here by me and Rob Roeterdink responded

http://www.elvastower.com/forums/ind...signal-errors/

And here is part of ChiFans conversation how he tracked down one of the items:

"Hi Vince,
....................snip...................Regardi ng signals, yesterday I dug around in the TDB and world files to see if I trace numbers starting with the TN listed by OR. I traced the last one (TN 13638) because it has a lower number of TrRefs to chase down.

I found something that appears suspicious, here is what I found:

- TN 13638 is a TrVector with 11 sections

- The sections are in -11080/14332 and -11079/14332.

- Associated with them are 7 TrItemRefs (interactives).

- Four interactives are Sound Regions.

- Three interactives are Signals

- The TrItemRefs for them are 26270/13399/13417.

- SignalItem 26270 has "( 134.85522 96.681 595.40601 -11080 14332 )"

- SignalItem 13399 has "( 134.85522 96.681 595.40601 -11080 14332 )"

- SignalItem 13417 has "( -1009.41 96.681 327.38678 -11079 14332 )"

Then took a look in world files -11080/14332 and -11079/14332 for corresponding TrItemId entries of 26270, 13399, and 13417. Found 13399 and 13417, but not 26270. Oh Oh!.

Then went to TSRE where 26270 is supposed to be at "( 134.85522 96.681 595.40601 -11080 14332 )".
Found "USPldwrf.s/Pl Dwrf Absolute Signal" with UiD 52566.
In -11080/14332, that UiD has a "TrItemId ( 0 13399 )", which is one of the above. That one appears fine.

I don't know how signal links are handled in the databases and world files, but the duplication of location info for 26270 and 13399 looks suspicious. Found 13399 but not 26270. To me, that means that SignalItem 26270 is bogus, a phantom link.

I used TSRE to eliminate this particular error yesterday. These are formally known as "Phantom Signals" That is a signal in the track database but NOT in the World file

So Here an open request to the Open Rails Developer Team; We desperately need coordinate information to eliminate these type bugs. They are, depending on the type signal that has duplicated coordinates, (can be 2 different types!) whether or not it's a fatal error.
If the 'Phantom' is an absolute, a player will be stuck at that point. Fatal!
These bugs can now be eliminated with TSRE but only if tile coordinate information is provided with in the OpenRailsLog.txt file.

ChiFan mailed me this morning with this comment:

Hi Vince
What a great combination that would be: OR providing meaningful info like (world file positions instead of those strange numbers) on those signal errors, and TSRE providing a means to remove them from the TDB. My tool was designed to analyze paths and remove unwanted ones. It wasn't designed to deal with duplicated locations or missing world file UiDs or TrItemIds within those paths.
I hope the OR team will provide the world file info for bad signals, and soon. It would make resolution so much easier. Otherwise it would require tracking down hundreds of TrItemIds in the TDB for those signals to look at locations and checking to see if TrItemIds are in corresponding world files. Yikes!!!

Happy New Year to ALL!
Best regards,

Open Rails Crashes With An Error

Open Rails Crashes With An Error

Comment

Comment

Comment