Atomic Systems

Can anybody help me please.
I am building Forest Of Dean / Wye Valley / Gloucester - Tidenham ( Main Line ) Routes, 1960's ish, for the past year or so. All tracks have been laid, with some scenery.

I have decided to extend the Main Line onto Chepstow - Severn Tunnel Junction - Severn Tunnel - Stoke Gifford Triangle - Berkeley Road - Gloucester.

But I keep hitting a problem, after I have laid more track on World Tile 6168+14932 (Chepstow), I can still jump to tiles, namely 6167+14933 (Tidenham) and 6162+14936 (Lydney) without a problem occurring.
When I exit Route Editor, restart etc. and go into Route Editor, to Start Tile 6164+14935(Woolaston) all is ok, but if I jump to tiles 6162+14936 or 6167+14933 and some other tiles, I then get the Send/Don't Send message.

I have looked at the technical details and amongst the info !!!, I can make out on the right hand side, either of the above tile numbers, also Global\Shapes\IMPLATFORM.S.

I have looked at those tile numbers in Wordpad, but cannot see anything obvious. I have deleted all my Platform / Siding markers from Route Editor. Tried everything I can think of, but I cannot proceed past Tidenham.

Any help would be very much appreciated, as hours upon hours and more hours have now been wasted on this problem

Thanks

DJB,

I have seen this one before..... Just a moment.

Have you got any Speed post's etc or Signal's?

Try this one- i dod answer it previously.

http://forums.atomic-systems.com/viewto ... highlight=


Twas an errant shape file on mine.

Tim

Thanks for your reply Alan.

No I have'nt put speed posts in yet and I have deleted all the signals that I did have on my route.

Dave JB

The signals that you Deleted... Were any of them linked?

If they were, They can leave Remnants in the TDB and TIT files.

I had a simmilar Problem when I removed the Signal's from Peak Rail v0.5. I had to check all the World File's for "Signal".

Then remove any References manually. IE delete them.

You must re-build the TDB after that though. Which should remove the problem.

Timcourt1 wrote:Try this one- i dod answer it previously.

http://forums.atomic-systems.com/viewto ... highlight=


Twas an errant shape file on mine.

Tim

Tim's right - this does sound rather like what I had - does your route crash at certain places when test-driving it in MSTS too? Mine did.

In my case I isolated the problem to some speed posts it didn't like, so removed them and all seems ok (I hope).

Even if your problem's caused by something else, Tim's methodology, though time-consuming, is the approach to take, as it is a logical way of isolating exactly where the problem is (and remember that it could be on more than on tile - it was 4 in my case).

Very best of luck anyway.

I think that EVERY route-builder has fallen into the same trap at some time or another... the key thing to remember is NOT to place any of the items listed below into a route until all track and road sections have been placed, followed by a final re-build of the TDB. Also keep a back up at this point...
Then, and only then should you add:-
1) Mileposts
2) Car Spawners
3) Signals
As regards the default Kuju telegraph poles, avoid at all costs! (My opinion!)
Cheers,
TC

Well, I don't want to rock the boat here but I have recently rebuilt TDBs several times with all 3 of those items in place - and lots of them. The only thing I don't place prior to the rebuild is linked (i.e. junction) signals.

I would add to Terry's selection

1. Level crossings
2. Platform markers
3. Yard markers

These have also caused me grief in the past when rebuilding TDBs, especially if some track has been laid subsequent to the placing of these items.

... and mile posts include speed limits!

At the end of the day its choice through experience- martin has got away with it so far, I found on a large route 50+miles say, rebuilding the track database with all your interactives places causes them to shift a few yards one way or another (Sometimes) and quite frankly it is not a risk I wish to take.

The way i do it comes from having had 3 errors before 2 mideast and one SVR and the cure was the same for all 3.

Again I will re- iterate- rebuilding the TDB is a good thing but to tell you the truth I have not really seen any benefits apart from putting all your track sections at the front of the world tiles and it doesnt always do that right anyway.

(Mideast TDB was last rebuilt on ecml3.1)

Tim

Agree with Tim on this one - Woodhead never got a TDB rebuild after the end of 2001 - simply because it would never have it!

But... when I forceably picked up my Blackpool Tramway route and moved it one tile to the East to eradicate the white terrain problem, a TDB rebuild was mandatory.

Many thanks to Alan, Tim, Mick, Terry, Martin, Mike and Steve who have taken the trouble to give me their help and experience.

Using Tim's method, I have established that it is the dreaded Dynamic Track, that appears to be causing the problem. As when I delete all Dynamic Track from a problem World Tile file, I can then visit that tile without the Send / Don't send message.

The only problem is that it appears to be many tiles that is now picking up this problem.

What I do not understand thou, is why does my backup run with no problems, on all World Tiles, then after I have added only about 12 pieces of track onto tile 6168+014932, save, then exit R.E., that when I go back into R.E., that many tiles are now affected with whatever the problem is, to do with Dynamic Track.


I am now thinking seriously about relaying all my track with UK Finescale. I know this will be a mammoth job, but my thinking behind this, is that I won't have to use Dynamic Track and that I am creating something for the future, so I want to do it , as good as possible, with whats available.

I assume that the best method would be to delete so much track at a time and relay with Finescale, to be able to follow my previously laid track layouts. I realise that the default track and Finescale are not compatible.

I would appreciate any comments or advice on this.

Many Thanks

Dave JB

If you've not laid any Dynamic track since the Back-up, try copying the Tsection.dat file from the back-up and pasting it into the Current version.

If this work's it is a Dynamic track section in the problem tile.

I'm increasingly of the opinion that these kind of problems come from the re-indexing of the item table when a tdb is rebuilt. (although that doesn't explain the dyntrack problems).

Picture this.

When you place any object which makes an entry in the Item Table, such as a platform, signal, level Crossing, CarSpawner, siding, pickup etc. etc. the object placed in the world file has a reference to that item in the item table (via the TrItemId entries).

Further, these Item Id's are also placed in the relevant TrVectorNode entry in the tdb.

If we then delete the tdb and get the RE to do a rebuild from the world files, we have effectively orphaned these item id's in the world files.

Now, without a tdb or item table, the only way to know which section of track a signal, or level crossing etc. belongs to would be by comparing its position with the trackobjects in the world file - however, this information is needed in order to ensure that the item id's assigned in the item table, and referenced in the vector node are correct.

My suspicion is that when the RE does a rebuild, it does not re-reference these item id's and trusts to luck that the item table will be built in the same order and the items will have the same id's as they had when originally placed.

As Alan2 has noted, the tdb rebuild is done in 3d by searching (it seems, from the current RE start tile position) for track nodes and items and I suspect that the node numbering and, more importantly the item numbering is based upon the proximity to this start tile position.

If that is true, then it would explain why moving the re start position before a rebuild can have such catastrophic effects - if this causes things to be numbered in a completely different order, it would completely destroy the item id relationships. If the start position is not moved, then it would seem to be down to luck whether an item retains the same id.

As a matter of interest, has anyone had any problems with placing platforms or sidings early, then moving the start point, deleting the tdb and tit and attempting a rebuild?


Dave C