Atomic Systems

Short answer : if you get one of these errors and can't find any stray bits of track hidden anywhere, move to the nearest tile boundary, delete the first piece of track which is wholly inside the tile boundary, and try a track database rebuild.

I got this error and a CTD this morning when I tried a track database rebuild, (because I hadn't for ages and suddenly thought I'd do it for a laugh). I had backups: but going back over a fortnight the error was still there, and restoring from months ago just wasn't an option.

I tried all the suggestions in the tutorial at the steam4me site, but there were no random blue poles buried underneath the terrain, no finescale 0.234m intermediate straights hidden beneath the track, nothing that I cold see to cause the problem The track itself looked fine, I could run trains over it. I tried the trick of using the activity editor to look for loose track, but found none, and could actually create a new activity with a new path which ran through the dodgy section. If the AE can manage it without crashing, surely there can't be anything wrong?

I ran the route through RouteRiter and the TKUtils checks, and neither of them reported anything that I didn't already know about.

What I ended up doing to eliminate the fault was, first ripping up the siding which I was sure was the cause of the problem, which it wasn't, and then ripping up several lengths of apparently good line, until the RE was able to do a track database rebuild, and I could relay the track again.

Then, knowing that it was a curable problem, I restored the faulty version, and had a more systematic investigation.
What I did was
1. Screendump the track database error so that I had the camera lat long and alt figures.
2 Start RE and jump to those figures. From the high altitude, it looked as though the siding was the culprit, but that was because the camera was looking at it, and I realised from watching the attempts to rebuild that the error was probably behind the camera, not in front of it. (Credit to the steam4me site, it was reading that tutorial which made me think about what might be going on when the error occurred.)
3. Came back down to ground and looked back in the direction the RE had been coming from when the error occurred.
4 Turned on tile indications using F7.I found I was very close to the blue line of a tile boundary.
5 Used F2 and left clicked to check the track sections. One 100m straight was crossing the blue line, and the next 100m straight was the one which was under the camera position.
6. Deleted the track section which was under the camera, (the first track section wholly within the tile boundary).
7. Saved, left RE, started up again, and asked for a Track database rebuild. Success.
8 Relaid the piece of track. Saved, left the RE, started it up again and checked it still did a track database rebuild without errors.

I did a diff between the now-working version and the version which had caused me all the aggro. I found that apart from some tiles and the track database file itself, one world tile had changed. When I uncompressed the two version of the world tile and compared them, I found that the first entry in the faulty world file had been moved to the end of the world tile which now was working correctly. That, I assume, is the section I ripped up and then relaid after the track database rebuild.

HTH

AdamsRadial wrote:I tried all the suggestions in the tutorial at the steam4me site, but there were no random blue poles buried underneath the terrain.......

<<< SNIP >>>>

4 Turned on tile indications using F7.I found I was very close to the blue line of a tile boundary.
5 Used F2 and left clicked to check the track sections. One 100m straight was crossing the blue line, and the next 100m straight was the one which was under the camera position.

Adam,

I suspect you may be referring to the "blue poles" tutorial.
However, the tutorial http://steam4me.railpage.org.au/trainsi ... ector.html does say

It's usually a piece of track that exhibits one of the following characteristics:

* an errant piece of track (often buries underground (press "W" to go into wireframe mode and "/" to drop beneath the terrain to look for these tracks);
* long (250m+ straights or 2000r10d curves) track sections crossing one or more tile boundaries;
* reverse curves along or near a tile boundary (eg a snaking piece of track);
* track crossing tile boundaries on a shallow angle; and
* track crossing tile boundary intersections too closely (the cross where four tiles meet seems to be the biggest culprit).

..... which is what you found.

Your post indicates that I should move the simpler correction (ie remove and replace with smaller sections listed in "Other Points/Tips" ) up the tutorial as a more obvious and quicker fix. I tend to write tutorials as I wrestle with a problem. Then I look for other comments and add that information into the finished document. I've now edited the tutorial to make the correction process more succinct and a little simpler.

Thanks for pointing out the obscurity in the tutorial.

Yuri,
I think your tutorial is fine as is, it certainly pointed me in the right direction. I assumed that I had found yet another oddity in the RE, or some peculiarity of UKFS. However, since the fault re-appeared yesterday despite my not doing any work on the tile in question, I am going to investigate it further, and one option is to follow your advice and split the long track section which actually crosses the tile boundary into two, and see if your advice then works.

For the re-appearance, I am puzzled, because I had a third pop-up box appear when I closed RE. The first two, as expected, asked me if I wanted to save track and terrain changes. The third didn't say anything apart from giving a UK Finescale track section and a question mark. I clicked on yes, and on a hunch, started up RE and tried the database rebuild. The puzzling thing is that I hadn't laid or altered any track at all in the session, just placed an object. The only clue I have as to why this error occurred is that when I closed RE the compass heading was pointing towards the tile where the error occurred. Co-incidence maybe?

I hace been plating with teh RE

The suggestion of splitting the track in Yuri's tutorial works, and is easy to implement because all you need to do is identify the track piece crossing the tile boundary. (There might be problems if you cannot find a pair of smaller pieces to replace it, say if it was a 2000m_1d curve?)

But, I think I have an even simpler method than splitting a section of track where it crosses the boundary.

One is the method I first posted, which is to work out the first track piece after the problem section that is completely inside the tile, remove it, rebuild the track database, and replace it. The problem goes away, and there is no effective change to the route. The hard bit is working out in which direction the RE rebuild process was moving, and then identifying the particular track piece to experiment with. The method is
1, find the problem section.
2. based on your guess as to the RE direction, delete the next piece of track connected to the problem section, remembering to note both the gradient and type of section.
3. try a rebuild. If it fails, go back and replace the section, then try deleting the section the other side of the problem piece.
4. Once the rebuild has worked, go back into RE and replace the section you deleted in step 2 exactly as it was.
5. Check with a rebuild that the problem is fixed.

An even simpler method I thought I'd try was to do the opposite of Yuri's suggestion, and instead of splitting the problem piece of track in two, combine it with the subsequent piece of track into one longer section, and to my surprise, it worked.

Until I can work out how to paste a screen dump into one of these posts, here is a text description.
1. The problem section on the tile boundary is a 100m straight at -0.450 slope. Deleting it and replacing it with 2 50m straights will work
2. The next section after the 100m straight is also a 100m straight, also at a slope of -0.450, and deleting it, rebuilding the tdb and replacing it will work. Nothing needs to be split in two or changed at all.
3. Deleting both 100m straights and replacing them with a 200m straight at a slop of 0.450 also works.

The new question is, is it better to have a lot of individual track pieces in a section of line, or as few as possible?

I've found that these can sometimes be caused simply by a memory issue.

Just jump to a blank tile, let the memory clear, and then jump back to the original position.

If track does need to be relaid, I find that replacing so that the old and new track node positions are in different places over the offending area to be the best solution.
For example, if you have 3 x 100m sections in a line, replace those with say, 50m,100m, 100m, 50m.

If the problem is with a recent bit of work, then replace the .tdb with the .tdb from an earlier successful back-up, and then do a manual tdb rebuild on the new work.
I tend to find that an 'automatic' tdb rebuild usually causes more problems than it solves, often in areas that previously were OK