Correcting Track Database Errors in Route Editor

compiled by Yuri Sos
based on lots of work by Jim Ward
also contributions by Vince Cockeram, Charlie Leveritt, Chris Markle, Phil Voxland

Overview

"Track database error: 'remove_end_end' one non-vector, one vector"

This is a common and dreaded message when you're trying to do a track database rebuild.

It often shows up after RE crashed whilst trying to save: and THAT often occurs because you've been working in RE too long without saving, exiting to the desktop and rebooting your system to free up memory.

There is simply no reason to not have back-ups of your work in progress: Route_Riter makes it easy: click here for a tutorial on using Route_Riter to back up your files.

The value of backups

People often ask "How often should I backup?"

The answer to that question is another simple question:

How much work are you willing to lose and do over?

 

The Problem

You're doing a tdb rebuild and you come across this dreaded pop-up:

The easiest way to fix this problem is to step back to the last known good backup. But you say "nooooo, I've done SO MUCH work since then and it will make five days of work go away - don't want that! oh, and the backup is on a CD I put somewhere so what do I do next?".

 

Correction

  1. The screen may have stopped but it's given you the exact location of the error: latitude/longitude, tile, co-ordinates within the tile.
    Write down the figures in the "Camera" window.
     
  2. It's usually a piece of track that exhibits one of the following characteristics:
    • 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).
    • 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).
  3. If you find the "track piece crossing a boundary" that is the problem, replace the offending section(s) with much smaller pieces of track, making sure NO single track section crosses more than one tile boundary.

    To find the "errant track piece" in a large route, it may be easier to go into Activity Editor, select the route, click ok, ok again (you won't be saving anything), and scan the track looking for an errant piece of track.

    When you find it, place the cursor on it and note the latitude and longitude in the top left hand corner.

    Quit Activity Editor without saving.

  4. Go into Route Editor WITHOUT DOING A TDB Rebuild) and jump to the location of the error.
    • Find and delete the offending piece of track.
    • Save and exit.
    • Delete the tdb, tdb`bak, rdb, rdb`bak files from within the route's folder.
    • Go back into Route Editor, select route/do a tdb rebuild;

      The advanced rebuild takes the info from the numbers in the .w file and uses it to make the tdb files, so;

      • if you run the rebuild when the orphans are still in the W files it attempts to construct the track database from the faulty info;
      • if you delete the orphans from the W file and don't run the TDB rebuild, the track database (invisible line that the trains actually run on, what you see in the activity editor) is still the way it was;
      • if you don't delete all the backup files (*.bk), the TDB rebuild attempts to shortcut the process by copying info from the .bk files;
      • if you don't delete the .tdb and .tit files before running the rebuild, the TDB rebuild subroutine attempts to repair the existing .tdb and .tit files instead of building new ones from scratch (using the numbers from the .w files). That usually causes errors

      Therefore, the only good way to rebuild the TDB is to delete all .bk files, delete the .tdb and .tit (plus .rdb and .rit if they exist), then run the TDB rebuild. It's still an imperfect subroutine in an imperfect editor, so the TDB rebuild is a crapshoot anyway, and sometimes (watch it, incoming pun) you roll boxcars no matter what. Following the proper procedures before running the TDB rebuild at least assures that the dice ain't loaded.
  5. Keep doing the above until you get the message "All Tiles Visited".
     
  6. Check the route again. NOW do a backup before anything else goes wrong - it will!
     

 

Notes & Comments

  • One user has reported the experience of a TDB failure popping up in an area where he had not been working for a long time, even though several good rebuilds have happened since he was last was there. This seems to be related to the structure of the data base as it is being put together by during the rebuild. He finally set the start tile to a new location and no errors were reported.
     
  • There is one area in another user's route where blue poles show up after a rebuild (even after replacing the track with shorter pieces). However, removing a track section that touches one of the blue poles, then do the rebuild, a succesful data base is created. Then he puts the section back in, and everything works fine (until he needs to do another rebuild!).
     
  • Finally, some words of advice from Vince Cockram:
    "you are doomed to failure if you are modifying a route's track while signals (and for that matter, ANY interactive objects) exist anywhere on the route. Ignoring this little requirement has trashed many many routes where the builders didn't understand or who decided they could get away with it.

    If you want to modify a route with interactives installed you must get rid of them. . .ALL of them. When you finish stripping out all the objects the track item table and the road item table should be empty, with the ONLY exception being entries in the track item table (routname.tit) being crossover entries."
     

 

Matrix 3x3 Errors

Another error you're likely to run into is the "matrix 3x3" error, click here for information on solving this problem.