Another Mystery - Broken Path on this track

[Vince]

I have come across a real puzzler;
+ If I set up a path ending at this buffer ( A1tUSBuffer.s ) the one shown in red and then save the path I get a 'Broken Path' message.

+ If I set up a path ending at the buffer on the adjacent track ending at the buffer the path saves successfully.

+ The properties of both tracks buffers are set up exactly the same.

+ If I move the end point just slightly away, less than 1/2 a meter from the end of the track dot in the AE, the path saves okay.

+ There are six other tracks in this yard, and a path ending at the buffers all save successfully.
( It's the Vanderbuilt Yard at Flatbush Ave. Brooklyn in case anybody is interested in the location. )

+ I am stumped! :confused: Really!!

Why allowing a path to end at the bumper gets a broken path, and ONLY on this particular track is something I have never seen. The two adjacent tracks have an engine escape crossover (two 10dLftMnl switches) about 30 meters from the bumpers. There are two other tracks in the yard with exactly the same configuration with the same type switches and as I said previously, ending a path on the other tracks all work fine.

Lukas (Swissie) wrote up a tip some time ago about never to allow or attach a track section past the bumper and never attach a bumper backwards as it will cause (unremembered by me) Track Database problems.

The only difference this particular track has with any of the other yard tracks is it located about (rough guess) 10 meters ABOVE the Flatbush Ave Terminal Station tracks which are below street level.
The tracks in the tunnels are continuous, i.e. No end of track anywhere near the yard tracks at street level.

If anyone has any ideas on this I sure would very much appreciate hearing any ideas you may have.
I have not yet done the 'nuke it' approach by removing and reinstalling the buffer and the track that it is attached to (a 25 meter straight) as I wish to explore all other possible solutions before tempting the fates by making changes that alter the Track Database.

This IS the area (the adjacent tile) that one month ago had a mega crash and meltdown of the TDB.
Oh, and to be sure, all the Route_Riter diagnostics and TSUtils diagnostics run error free!

Here are two screen grabs, one in the Route Editor and the Sim, bounding boxes displayed (Ctrl and NumPad '+' key).
The RED highlighted bumper is the bad boy and it sits about 10 meters directly above the underground terminal station tracks.

[krausyao]

One difference I see between the two tracks is that the selected track on the right has one track section indicator while the track on the left has two track section indicators. Track section indicators are the vertical line connected to the angled line that occur in the middle of each track section.

Could you post the end point and track vector of the highlighted track? The end buffers appear to be the same track object. Are the tracks connected also the same? If they are the same, why the difference in the track section indicators?

[GaryG]

Hello Vince

I remember seeing something written about "stacked" items in MSTS having problems. I think it may have been something about crossing gates thinking they were associated with an object either higher or lower than the gates.

Perhaps stacked tracks is your problem.

An example of what I'm remembering:

"http://www.trainsim.com/vbts/showthread.php?t=278853&highlight=crossing+gate+problem"

(Above link - remove any forum inserted spaces)

GaryG

[Vince]

Thanks for both these responses.

Jeff,
Good eyes but that is a short 5m track on the end of a 90m straight and is on the track that does not have a problem.

GaryG,
I checked for that by selecting all the tracks involved and there are no stacked tracks. Thanks, I hadn't thought of that.

As a picture is worth a thousand words, here is a print from the AE.
http://www.trainsim.com/vbts/attachment.php?attachmentid=27652&stc=1&d=1271903665
The green path line is the one that works fine if the path is allowed to default to the end of the track.
The track above the green path line is the bad boy. If the path is allowed to default to the end it fails. It matters not where I start the failing path, before or after the switches, it will fail. Additionally, the failing path LOOKS fine when it is added. It's only when I go to save that the AE pukes.

If I move the end point ever so slightly away from the end dot, it works!?!
The tracks with the slip switches are in the Atlantic Avenue tunnel, about 10 meters below the problem track, which is in the street level yard.

I will try looking in the Track Database to see what (if any) differences between the bad buffer and the others.
Jeff, correct me if I'm wrong here.I have to locate the TDB entry for the buffer and I think I have to:
1. Locate the world file entry for the buffer and record it's SectionIdx, the X, Y, Z coordinates and it's UId.
2. From the \Global TSection.dat get the Trackshape ID
3. Using the info in 1 and 2 above hunt through the TDB to find the entry.
Did I get that right?
I will look through your tutorials and check up on this as I am typing this from memory. And not much of that left these days. :p

Thanks again.

edit add: I just checked; All the yard tracks are close to about 10 meters short of the tile border but none of the yard track touches the blut border line. I do remember being careful with this when I was installing the yard tracks. :)

[krausyao]

You are right about the memory! :p There is no need to examine the global tsection.dat or any hunting.

Using the default Marias Pass route to locate an end track shape in the track database.

1. Select the track shape in Route Editor and note the position.

-12579 14766 319.079 934.203 -424.425

If the Properties dialog displays more than six significant digits, round to six digits.

2. Look in the world file w-012579+014766.w for a track shape at the noted position.

TrackObj (
UiD ( 30 )
SectionIdx ( 79 )
Elevation ( 0 )
CollideFlags ( 581 )
CollideFunction ( 1 )
FileName ( SR_1tBuffer_w.s )
StaticFlags ( 00200180 )
Position ( 319.079 934.203 -424.425 )
QDirection ( 0 0.551997 0 0.833846 )
VDbId ( 4294967294 )
)

3. Look in the track database for track section 30 of this world file, -12579 14766 30. For an end track shape this will find the end node and vector node.


TrackNode ( 469
TrVectorNode (
TrVectorSections ( 8 183 72 -12579 14766 20 0 1 00 -12579 14766 609.174 934.203 -532.382 0 5.11367 0 175 72 -12579 14766 20 0 1 00 -12579 14766 607.783 934.203 -531.792 0 5.11367 0 1 1 -12579 14766 21 0 1 00 -12579 14766 580.583 934.203 -522.959 0 4.93913 0 183 81 -12579 14766 22 0 1 00 -12579 14766 531.863 934.203 -511.718 0 4.93913 0 176 81 -12579 14766 22 0 1 00 -12579 14766 530.391 934.203 -511.378 0 4.93913 0 2 2 -12579 14766 24 0 1 00 -12579 14766 503.191 934.203 -502.545 0 5.11367 0 2 2 -12579 14766 26 0 1 00 -12579 14766 411.135 934.203 -463.485 0 5.11367 0 186 79 -12579 14766 30 0 1 00 -12579 14766 319.079 934.203 -424.425 0 5.11367 0 )
TrItemRefs ( 4
TrItemRef ( 533 )
TrItemRef ( 724 )
TrItemRef ( 725 )
TrItemRef ( 3263 )
)
)
TrPins ( 1 1
TrPin ( 468 0 )
TrPin ( 470 1 )
)
)
TrackNode ( 470
TrEndNode ( 0 )
UiD ( -12579 14766 30 1 -12579 14766 312.42 934.203 -421.6 0 -1.16951 0 )
TrPins ( 1 0
TrPin ( 469 0 )
)
)

I don't know what could cause the error you are getting although I may be able to see an error in the track nodes. The current version of TsUtil does not detect mismatches in track pins and track points. When you do find the end track node compare the position with that of the end point of the path that causes the error.

[Vince]

Hi Jeff and all interested parties! WHAT!! A party? Where? :p

First off let me say this is by far the oddest error I have ever seen the RE vomit into my lap! :eek:

After finding all the entries in the TDB I can see nothing wrong . . . so I backed up the route and then exercised the nuclear option. :eek:

1. I first deleted the buffer and was able to allow a path to run to the end of the track. No problem. Path saves normally

2. I then added the same shape buffer back. Attempt to save.Broken path as before!

3. Then I removed all track back to the switch, saved, and was able to allow a path to run to the end of the track which is the switch.

4. I added the track back in but used the buffer with the wood bumper. Attempted to save and got the broken path as before!

5. I removed all the track as before but also removed the switch. Path okay to where it ended at the switch. Path okay saved okay!

6. I replaced the switch but used different lengths of track to arrive at approx. the same location (it's 121 meters to where I attach the buffer) and installed the original buffer shape. (the one in the screen grabs) Again on a save, Broken path as before! Ai Yi Yi!!

Okay baby, this is WAR!!
Errr. . . . But tomorrow because I'm recognizing the beginnings of a burnout here and I need to think this through, but I will say that I really DO (seriously) enjoy shooting bugs like this. It's what I did for 32 years AND I am (was) an Army wrench puller. 63B20 for those who know! :D

Speculation Alert Engaged;
It seems that any track added to the 121 meters of the two track sections AFTER the switch fails if the path ends on that third last track section, the buffer.
It's NOT the fact that it's the THIRD section either because I previously used five track sections to span the distance before the end, above in step 6. of this unholy circus.
I think this has something to do with the tile border. Like I said, it's about 3 meters or so away but that should not cause a problem. It's also near the corner of the tile, about 20 meters south of the intersection of 4 tiles.
I must check the track in the tunnel to make sure there is no "Three Tile Crossing" with the tunnel track, something I had not thought of until just this minute.
Time to mellow out and do some thinking. Cuppa Jack will go nicely here. :p
G'nite folks.

[bcrailfan]

I think this has something to do with the tile border. Like I said, it's about 3 meters or so away but that should not cause a problem.

Vince : I do personally believe there is some kind of RE "twilight zone" as you approach tile borders . I , personally , resolved many issues just last few days , related to Tile border crossings, which caused significant track database errors . All those ( whackloads of ) errors, always were within 10 meters either side of a blue line .

If you ever worked with terrain 'shaping" , you may have noticed that where some tiles butt to one another, there is occasional "fault line" one can see , which extend about 10 -15 meters either side of the blue line demarcation . Either a downward "crease" or an upward "fold" . As much as your terrain is totally "Urban" , this does not preclude the tile's extreme 'eges" could have some ( 'digital" ) weaknesses to them .

I also think 3 meters really fits in that "twilight" ( or at least , "unstable" ) zone . Would making your end buffer track as a "Static" world object , something you tried so far ? Could there be a "blue pole" from one of the tracks below, that touches ( or 'interferes" ) with your end buffer track ?

As far as "burnout", I totally relate . Thinking this true, this is when I was in such a 'state", that I made most of my track database errors ( such as fitting 4 50 meters straights, where there was only space for 40 meters ( as a gap to be filled ) , and not oven 'seeing' the blue poles overlapping, as I was saving ( at 4 am , of course ) .

But , yes , those Tile border outer edge "unstable" zones , is the cause of a LOT of unespected track problems .

Jean Brisson BCLW Route Building team

[krausyao]

The broken path may be due to Activity Editor and not a problem with the track. It may be placing the end point on the track just north of the buffer. Did you compare the end node of the buffer to the last point of the broken path? One method of testing this is to edit the last point of the path and use the coordinates of the end node of the buffer.

If this is the cause of the problem with the path it may be possible to prevent the problem by changing the order of the node definitions in the track database. My guess is that the node definitions for the buffer track are after those for the track above the buffer.

You mentioned that you did not see anything wrong with the track database, but would you post the definitions of the buffer and track north of the buffer anyway? Perhaps someone else may see something in these definitions that you are missing. :D We want to win this war, right? :p

[Vince]

The broken path may be due to Activity Editor and not a problem with the track. It may be placing the end point on the track just north of the buffer. Did you compare the end node of the buffer to the last point of the broken path? One method of testing this is to edit the last point of the path and use the coordinates of the end node of the buffer.

If this is the cause of the problem with the path it may be possible to prevent the problem by changing the order of the node definitions in the track database. My guess is that the node definitions for the buffer track are after those for the track above the buffer.

You mentioned that you did not see anything wrong with the track database, but would you post the definitions of the buffer and track north of the buffer anyway? Perhaps someone else may see something in these definitions that you are missing. :D We want to win this war, right? :p

And this from Jean:
Vince : I do personally believe there is some kind of RE "twilight zone" as you approach tile borders .

Well, the war is over! But before it was won, I will detail how so others may be as confused as I am;
And I definitely like Jeans post! I raise my glass sir!

1. On the failing path on the top siding track there were three tracksections invloved; see the AE screen above.
From the switch moving to the left;
a. 21 meter straight
b. 100 meter straight
c. end buffer.

I replaced all these track sections with a single Dynamic Track set to the exact length (switch to buffer blue pole) on all the involved TrackSections.
It Fails!

Okay, I have so far eliminated the switch and all tracks that the switches attach to. The other siding track and buffer also.
Two things to consider;
1. The end of track is near a tile border/corner and
2. The track end sits 10 meters above a track in the tunnel.

so . .
On a whim, I removed the tracks in the tunnel, all 3 track sections that ran from the tunnel switch to the left and across the tile border.
The failing path now works!

I put the tunnel tracks back, trying many combinations of length and every one of them, no matter how I mixed up different track length, if that tunnel track was run within about 15 meters of the siding end 10 meters above, it would fail. Boggles the mind it does! :(

If I have the tunnel track removed and make a path on the siding which now works, and then place a single track attached to the tunnel switch that runs near that siding end, and then fire up the AE, as soon as the test activity loads it fails with a broken path.

Umm I DID say at the beginning that this was the oddest error I have ever seen in MSTS. I now add the term "wierdest ever" also.
This is why I love MSTS, always new mountains to climb! :rolleyes:

Anyway, enuf comedy. How to fix?
Well, recall I used Dynamic Track (DT) to replace the all the sections on the siding?
What I did was progressivly shorten the DT, 5 meters at a time and then test,
When I got just 10 meters shorter on that pesky siding track and I'm able to have a path end at a buffer. I removed the 21 meter section and replaced it with a 10 meter section, which means the siding is 11 meters shorter and everything works as it should.

I doubt I will ever 'know' exactly why this happens and it is consistant failure too.
It would take some deep digging into the databases and besides, I was a hardware guy with IBM and used to go crosseyed trying to read a core dump. :p

So there are a bunch of variables here to consider; Close to tile border/corner and above that tunnel track, QDirection of the involved sections(7) , altitude of all the involved track ect. A real bitch to track down (pun intended)

The tunnel track had no end points anywhere near the end of the siding, 10 meters above it at street level.

Thanks much for all the suggestions and thanks again to Jeff for producing those TBD tutorials. They helped but I'm afraid I don't have the skills to pick apart the TDB for THIS particular bug. I mean, it's unheard of; Nearby track causing a problem? Like I said; The Nuclear Solution. :cool:

I'll go into Google SketchUp and Pull that platform end forward 10 meters and I'm good to go. :)
I'm gonna pick up my guitar and relax.
adit add: a thousand words. ;)
G'nite.