As you probably have read, OTTODAD in his post about not being able to get a TDB rebuild on his route, mentioned that it would not work on Seaview 3 as well. I asked Bill if he would mind me taking a look, and he responded most positively. I had a lot of thories about TDB rebuild and needed to look at someone else's route to verify them.Well to start with, so much with theories. This darn program just kicks you in the teeth and then goes for the stomach. I have learned some things though, the most important is perhaps to let sleeping dogs lie.It went like this:
First TBD rebuild, Track database error 'Remove_end_end' one non-vector, one vector (Which I will Call VEE) followed by debug crash screen. The tile was -111193x13853 Long -81.71484 Lat 31.38429. I jumped to the Lat Long given and was right on top of the green marker for a dynamic track piece that was about 500 meters long, and immediately crossed the tile boundary. I replaced it with a few stock curve pieces and finished up with a short piece of dynamic track. There were two sound regions now off the track, so I put them back. Ran TDB rebuild.This time VEE error at tile –11192x13852 –81.67989 31.36357. I jumped to that position fully expecting another dynamic piece. Total surprise. A 10m straight piece where it joins a few other 10 m pieces. The piece did cross a blue boundary line. I deleted the track piece and replaced it with another one. Ran TDB rebuild.This is where things went to hell. Instead of getting a VEE as before, the rebuild ran a long time then went straight to debug crash. I jumped to the coordinates still on the screen which were on tile –11198x13852 and was surprised to find myself on a sand dune with no track around. I spent the next 4 hours trying to find what was causing the crash. I totally removed the w file for the tile and it still crashed at the same point. I tried modifying terrain. I tried deleting objects from adjacent tiles to see if that was the actual cause. Nothing worked. Finally as an act of desperation, I clicked on the link in the debug message to see what would be reported to Microsoft. One of the things is a memory dump. I read through the memory dump and noticed that there was a reference to ..\seaview3\world\w-011197+013852.w , That was very interesting. It was the only tile listed anywhere in the dump list and it wasn’t the tile being displayed when the crash occurred. I jumped to that tile and found it consisted of a long bridge which Y'ed to a section of track that disappeared to the right and the left branch that took off and guess what: had one piece of double track that spanned the corner of another tile and joined another short piece that joined the track on the tile I had been working on! I replaced both sections of track, ran TDB rebuild….and got a ALL TILES VISITED!
The celebration was too soon. Now I noticed that tile –11197x13852 had rogue blue poles at both places where track crossed the boundary at the north end. I found that these last pieces could not be selected getting the familiar can’t select because the piece is not connected to anything error. I deleted large portions of track, and laid new track down with a slightly different path. By the way, when adjacent track was deleted, the rouge pieces showed track lines to one end like there was a piece still there. In some cases I laid new track directly over the top of the rouge pieces. Next I ran TDB rebuild again.I got another VEE error on another tile not yet visited. My notes fell apart here, but it was a 250 meter section that crossed a tile boundary. I replaced it with a few 10m , 100m, and 50m sections. Ran TBD rebuild again and got All Tiles Visited. I went back to –11197x13852. I got all kinds of signal error messages. I refused to allow the program to delete them and just kept drilling through the messages until I finally reached the tile. The track pieces were all still good. The rogue pieces now showed a blue pole at each end as they should, and the extra length of track marker line was gone. I selected the pieces and deleted them!In Bills email he had also clued me in on a rogue piece of track on tile –11199x13851. He couldn’t get rid of it since Seaview2 and had buried it underground. I had looked at it before beginning, and it was a 10d right switch with two phantom pieces of track attached. You could not select the switch. After the successful TDB rebuild I went back to the location. The phantom pieces were gone and I was able to select the switch and delete it.I spent the next 3 hours trying to find a way to fix the broken signals. Mile markers, speed zones, and sound markers did not seem affected unless the track they were on was moved, in which case selecting them and putting them back on the track fixed them. On the signals, I give up. From all of this I am drawing the following conclusions:1. It is indeed a good idea to run TDB rebuild often when building the route. At the point that you start placing signals, you should have a good TDB. You may run TDB after signals are placed, but if you get a bad rebuild forget trying to fix it unless you want to replace all the signals.
2. Crossing tile boundaries is the primary cause of TDB rebuild failure. It seems to me that from the way the ends were on the pieces, that going from North to South is the more prone to the problem than the other way around. Crossing 3 boundaries with a single track piece is a killer.
3. It is not necessarily a dynamic track crossing that will get you. Once a tile was fixed, it seemed to stay fixed.
4. Rogue blue poles and pieces attached to them seem to be caused by isolated fragments in the TDB. Once you are able to run a good TDB rebuild, the piece becomes selectable again.
5. It is not necessary to have a good TDB rebuild in order to have a usable route, as we all already know and SeaView demonstrates.Special thanks to Bill “Tree Frog” Burnett for allowing me to pick his route apart. I think SeaView will go down in history as the most famous non MSTS route. I thank him for giving it to us. It is truly a payware quality route.Larry
Printer-friendly page | Top
SeaView 3 TDB rebuild analysis [View All], lfriddle, 00:02 AM, May-19-03, (0) RE: SeaView 3 TDB rebuild analysis, griffinmt, May-19-03, 09:12 AM, (1) RE: SeaView 3 TDB rebuild analysis, OTTODAD, May-20-03, 07:51 PM, (12) RE: SeaView 3 TDB rebuild analysis, enocell, May-19-03, 02:46 PM, (2) RE: SeaView 3 TDB rebuild analysis, rgarber, May-19-03, 07:02 PM, (6) RE: SeaView 3 TDB rebuild analysis, jleslie, May-19-03, 11:16 PM, (7) RE: SeaView 3 TDB rebuild analysis, lfriddle, May-20-03, 00:05 AM, (8) RE: SeaView 3 TDB rebuild analysis, OTTODAD, May-20-03, 07:26 PM, (10) RE: SeaView 3 TDB rebuild analysis, Tree Frog, May-19-03, 04:45 PM, (3) RE: SeaView 3 TDB rebuild analysis, lfriddle, May-19-03, 06:03 PM, (4) RE: SeaView 3 TDB rebuild analysis, Tree Frog, May-19-03, 06:23 PM, (5) RE: SeaView 3 TDB rebuild analysis, OTTODAD, May-20-03, 07:36 PM, (11) RE: SeaView 3 TDB rebuild analysis, OTTODAD, May-20-03, 07:04 PM, (9)
Conferences | Topics | Previous Topic | Next Topic
Never had any errors in these places.I'm thinking (in my convoluted mind) that the real bug here lies not in the way we lay our roads and tracks, but rather within the code that creates the track database, and that something within that code writes to the various TDB files incorrectly which causes the errors we see. There doesn't appear to be any pattern to these errors, rather they appear to be random; one person like Cal can isolate and repair an error on his route that many of us already have in place on our routes and that don't cause us any problems. On the flip side of that, some of us have had problems on our routes that others don't seem to have on their routes.I can run trains on routes that aren't able to complete a TDB rebuild; somebody mentioned somewhere it may be better to let sleeping dogs lie.Jeff L