[JohnnyS]

Testing with the new route SFS Hanover-Berlin v3 I noticed paths created heading west from Berlin main station are indicated as broken by OR. The same paths used in an MSTS activity function as expected. Have experimented with a test path beginning in Berlin and gradually extended the end point westwards until a broken path was indicated by OR. have found there is a specific switch/turnout that seems to cause the broken path.

Approximate location.
http://farm8.staticflickr.com/7385/12901601173_79d4e9a726_b.jpg

Closer view.
http://farm4.staticflickr.com/3688/12901597203_2afd26f0f4_b.jpg

I notice the offending switch is on a tile border could this be causing the error? Have tested with several versions of OR from 0.9 up to x2070, error is indicated in all so far.

I have attached a log file and two test paths, one with the path end point placed just before the switch and one with the end point just after.

Cheers,
John.

Attached File(s)

•  log_paths.zip (3.29K)
  Number of downloads: 283

[JeroenP]

Dear John,
Your hunch about the point being on a tile boundary is indeed correct. The issue is in the ICE-HB.tdb (which contains the Track Data Base). It contains

		TrackNode ( 1816
			TrJunctionNode ( 0 21546 0 )
			UiD ( -5584 14977 3019 0 -5583 14977 -1023.82 36.95 -77.917 0 1.71644 0 )

The 1st and 2nd number in the UiD are the tile X and Z values, and so are the 5th and 6th numbers. I have no idea why they are defined twice. But since they are inconstent, there is an issue. Changing the first number from -5584 to -5583 solves the issue in the paths.

Currently ORTS uses the second pair (so -5583) to determine the distance from junction to node in the path, and, for not particular reason that I am aware of, it uses the first number (so -5584) to cull the junctions (meaning that all junctions not on tile -5584 14977 in this case are neglected). Since the path node is on tile -5583 14977, and this junction node (appears to be) on -5584 14977, it is not taken into account. And this leads to a broken path.
Is this a bug in ORTS? Perhaps not. It certainly is a bug in the route.

Could ORTS be changed to forget about the first two numbers? Perhaps. But since I have no clue why they are there in the first place, that might be a bit dangerous. I will try to find some more details. But I am not sure I will succeed.

Best regards, Jeroen.

[JeroenP]

Dear John,
Because I (and many others) lack sufficient knowledge of the database of MSTS in all details, I asked a question about this problem in Why is the tile defined twice?. Possibly the current track database is correct and we should fix it in ORTS instead. I will keep you posted.
Jeroen

[JohnnyS]

Hi Jeroen,

Thank you for your investigations, I thought the location of the switch being on a tile border was too much of a coincidence. Was reluctant to file a bug report as I was guessing it was a route error, though I could not understand why the paths functioned in MSTS and not in OR. Thanks for the tip regarding the .tdb edit, can confirm paths passing through the offending switch now passable post edit.

Cheers,
John.