[timothyskinner]

I found this thread useful as a starting point when dealing with this known problem:
http://www.trainsim....p/t-277495.html

However, working through the suggestions brought no positive result until I stopped a tdb rebuild after it it had passed the problem zone (I was watching the Lat/Lon) by left clicking Route then saving.... that did the trick and I was able to delete the unwanted track pieces.

Timothy

[caldrail]

I do get these problems occaisionally. In my Pahuseg project, the problem seems to repeat in the same places. Usually I do a little bit of jiggery pokery with Route-Riter and the problem goes away, or at least is editable so a tdb rebuild solves it. The problem can be stopped by leaving the editor before saving - if you know there's a problem.

[c36dash7]

Such type of issue, usually is not a definite problem, as such , and can also be a temporary "glitch" . Emphasis on "temporary" .

This can happen when doing a fair bit of work, over an extensive period of time , non-stop, in Route Editor .

If you feel really confident with your own tracklaying skills, then , best thing to do, is to merely "jump" , out of the tile ( I always prefer to jump outright into the "white void" ) , and then , jump back in .

The "supposedly" dysfunctional track piece, may simply have not been selectable, temporarily .

Same if you navigate ( "helicopter around" ) a fair bit, and find out ( visually ) missing track shapes . Simply jump out of the tile, and jump back in.

And / or , "don' t fix it, if it ain't broken" type of thing ...'-)

If it then ultimately turns out you do have a problem that is persistent , then , I personally prefer to "isolate" the co-ordinates for the track shape, first , perhaps using some of the tips offered in the linked thread ( I do believe this also would be a topic covered by a Steam4me tutorial ) .

Once I have "isolated" the co-ordinates for the dysfunctional track piece, I remove all the TDB / RDB / RIT / TIT files, and their backups , and "park" those to a side folder .

Opening Route Editor , with No... track database , I navigate to the problem track shape, and not only delete it, but to be super-safe, due to blue poles issues mentioned, often will also ... outright delete the track shape leading to it, as well as the one following it .

The object , of course, is to generate a "clean slate" ,and a squeaky clean Track database, which is far more important and critical , than losing ( temporarily ), 2 or 3 track shapes.

Save .

Exiting Route Editor, I now "ditch" any temporary track database that may have just been generated from doing this , and now, will go to the World folder, fetch all *bk world file backups, and also park those to a side folder .

Performing the advanced full TDB rebuild will "purge" the track database, from the dysfunctionality.

With the fresh new TDB generated , in then go back to RE, and install a fresh track piece ( or 2 or 3 in-a-row ) , although being "aware" if there are potential issues, such as track shape's blue poles, located too close the Tiles blue line demarcations, etc ... ( just so you don't make the exact / same mistake, yet another time ) .

"Stuff happens" ( when using Route Editor ...'-)

Jean Brisson

[OTTODAD]

There is a bit more to this problem.

Normally when track sections have not been joined properly, blue poles indicate that and can be fixed easily.

But when using Dynamic track sections the Route Editor saving them sometimes gets it mathematically slightly wrong when saving their extended decimals in World and Track Database files and no blue poles are visible.

It took me months to fix the PRR which had loads of such untouchable track sections !

[roeter]

Another famous source for these errors are 'Y'- points - and in particular if you remove 'Y'-points or track connected to it, e.g. because you want to reconstruct a certain area.
Normally, when removing a piece of track linked to a switch, the RE determines if the removed piece was on the facing end, the straight end or the turn-out end, and adjusts its links accordingly, replacing the link to the removed track with a link to a new end-of-track node.
But for 'Y'-points, the RE sometimes gets it wrong whether it was the straight or turn-out end which was removed, and replaces the wrong track by the end-of-track node. This leaves two errors - the track piece still in the route supposedly connected to the other exit of the 'Y'-point is now 'dangling' as its reference at the point end has been replaced and, worse, the 'Y'-point itself has a reference to a trackpiece which no longer exists. If you save at this moment, and come back to this spot later, you're in trouble.
What I found helped a lot here is first isolate the Y-point - and backup.
Remove one end, save, exit and come back - if you have an error, throw this version away and restore the back-up.
It sometimes helps to remove the 'Y'-point first, before removing any of its exits.

Regards,
Rob Roeterdink

[c36dash7]

I can relate to what is mentioned about mathematical calculations, by the SIM , as I have been pulling my hair out, all caused by mathematical "rounding errors" .

Yes , track shapes can be properly installed, within "range" as far as tolerances, for blue pole locations, and Yet, when a track database gets really large , there is much more likelihood that there will be some "rounding errors" and basically "microscopic" deviations, which can be sufficient enough , over the long run, to "dislocate" ( from a track database standpoint ), otherwise perfectly aligned & installed track pieces .

Such type of errors, usually creep up in Activity Editor, as "Path Breaks", as otherwise, you would never notice. "visually"..., that there are track database errors . There was one scenario where I had to entirely rebuild a 3 track curve-on-a-grade, 3 times over , until I got the track database rebuild to finally-finally "digest" that , and return an error free pathway.

Not mentioned enough , one should make a habit of routinely checking their Route , using the Route Riter / TsUtils tab , for "Check Integrity", and many real, as well as potential, problems, would be reported , in a format one can easily address .

I do know for a fact I do not perform such "Check Integrity" tests often enough. Most others who also try to avoid this , simply are unwilling to "face the music", and openly admit to their own errors. "Sweeping everything under the Carpet", is not such a good idea, with "digital" things ...'-)

Jean Brisson

[Genma Saotome]

AFAIK what is going on under the hood is this: When you click on a track shape the software tries to find that shape in the .tdb, (probably in anticipation of some kind of edit). If it cannot do that it throws an error message at you with the not-so-useful text "Cannot select adjacent track....".

There are no straightforward solutions... you can get into Archibald and try and fix it that way, something that usually requires very large cahones... or as Jean says above you get the .tdb out of the way so the software won't stop you when you rip stuff out and put it back correctly (you must be able to rebuild your .tdb).

[OTTODAD]

c36dash7, on 28 April 2014 - 02:03 PM, said:

I can relate to what is mentioned about mathematical calculations, by the SIM , as I have been pulling my hair out, all caused by mathematical "rounding errors".

That Rounding Error problem has been around for a long time:

http://support.microsoft.com/kb/214118

and Kuju not having corrected it in its Route Editor's code it is causing microscopic discrepancies when saving x-y-z location parameters of tracks into MSTS World and Track Database files.

Usually happens when placing Dynamic Tracks, I have ceased doing in the routes I have been working on, using some of the many new short length X-Tracks sections instead !

[Slim Rail Mike]

This was very useful, Admin please spike. This little bit helpped solve why some areas have had recurring blue pole issues. c36dash7, Jean, your walk though of what to do was the least painless TDB rebuild to date.

Michael

[rdamurphy]

There are rounding errors in OR, too. Not to mention just about every piece of software ever written.

It's known as the "Floating Point Error" and is part of x86/64bit CPU's.

The simple reason is: Conversion from binary code to base 10 mathematics.

You might try this also:

http://msts.steam4me.../matrix3x3.html

Robert