Track Database Problem?

[docmartin]

Hi eveyone,

Believe it or not, I am still working on my Chiltern Route. At present I am slowly modelling the various stations in the route - of which there are around 170 in total. I think it is important for the overall authenticity of a route to have reasonably realistic looking stations. As far as the trackwork is concerned, I can leave it as it is since it is pretty much finished, though there are a couple of places where I would really like to extend it a bit. For example, I have taken the ex-GWR line from Northolt Junction, where the former GWR and GCR lines part company from the joint line, as far as Old Oak Common and would really like to model at least the junction with the main GWR west of England line since I have included a stretch of the latter from this point as far as Southall. Also, having modelled most of the relevant parts of the London Underground lines which either run alongside or cross the BR lines in the route, I have, for example, included the Piccadilly line from Acton Town to Uxbridge on the one hand and from Acton Town to Northfields (on the Heathrow branch, though in my timescale it ended at Hounslow West) on the other. I would also really like to extend this part of the Piccadilly to its terminus at Hounslow West. However, this is where I hit a problem.

Does anyone know whether there is an upper limit on the number of track sections that can be used in a MSTS route? Now, if I add a single track section anywhere, or try to convert a section of dynamic track to UKFS (eg. to create a 4th rail curved section), the sim doesn't like it and shows its displeasure by refusing to allow me to open the Activity Editor or to run any existing activities. This is obviously a problem with the track database, but I am stumped as to what the issue might be.

Does anyone have any thoughts?

[tonyhap]

Good to hear that your route is still progressing. Yes, it will be a large size.

I don't have an answer, but I do want to make sure I have understood what is happening.

When you either convert ANY piece of DYNAMIC track to UKFS in RE, or you add one more piece of track ANYWHERE in RE, you can make an apparent successful save.

But then you find you cannot either open AE, or run an activity.

Is this the sequence of events? No error messages at all? And if you delete the just added piece of track everything reverts back to error free normal?

Regards,
Chris

[peacockg]

Try opening an activity in Open Rails. Then close it and look at the log file on your desktop.
I have found this identifies some unknown problems in the .tdb file.
However it is not always easy to resolve them.
Garry

[docmartin]

Chris - you have understood the sequence of events correctly, with the exception that I stupidly haven't thought to check whether everything reverts to normal if I delete the added track section. Up to now, I have simply replaced the route with the latest backup. I will experiment with simply deleting the offending track section and see what happens.

Garry - that's an interesting suggestion which I will have to try.

Many thanks for your replies.

Martin

[docmartin]

And if you delete the just added piece of track everything reverts back to error free normal?

No, I have checked and after deleting the just added piece the problem persists. I have inspected the tdb after adding the new track section and, as far as I can see, MSTS seems not to be adding the entries for the new piece correctly to the tdb. And it doesn't seem to be deleting the erroneous entries either when I remove the new track section. As I say, I am not 100% sure of this because it is so difficult interpreting what is going on in the tdb but I think this is the case.

I have managed to place new track sections totally unconnected to existing track without experiencing any problems. So it is only when I try to extend existing track that the problem occurs.

I haven't yet tried the Open Rails technique that Garry suggested so this will be the next task.

Martin

[smersek]

There is a limit to how many track nodes can be in the track database. Open the .tdb file in a text editor and note how many track nodes are in the file? The number is after TrackNodes.

SIMISA@@@@@@@@@@JINX0T0t______

TrackDB (
Serial ( 217 )
TrackNodes ( 732
TrackNode ( 1

[tonyhap]

And the track node limit in MSTS is?

[smersek]

I am not sure of the node limit in MSTS. It may be 32,767 which is the largest 2-byte signed integer.

https://msdn.microsoft.com/en-us/librar ... 2147217396

signed short int -32,768 to 32,767

[casperdog]

Hi,
A quote from a 2014 forum discussion on Trainsim.com:
eolesen

"When I was doing programming in the days of stone tablets and punch cards, we got nervous when approaching 32768 (8 bit limit) and 65536 (16 bit limit)...
It wouldn't surprise me at all if bad things are really happening when you exceed 32768, but just not manifesting as visibly as they are when you get further and further past that point..."

Cheers
Clive

[docmartin]

Sorry not to respond sooner. I've been changing my ISP - nuff said.

No, only 14,672 track nodes, so I guess that is not the problem. It seems that I can't do anything that affects the tdb. You know how interactives sometimes have a tendency to slide away from the position you originally placed them in? Platform markers, for example, which no longer align with their platforms, or signal markers which have strangely moved way in rear of the signals they relate to, ie you meet the marker long before you pass the signal. I noticed a few of the latter yesterday so tried correcting them and adding a few trainstops (these relate to LT underground signals), but had the same problem on doing this. I couldn't load any activities afterwards, again an indication that the tdb had got screwed up.

If I leave everything affecting the tdb well enough alone, the route works fine. But it is very frustrating not to be able to add or adjust track or signals.

Martin

[dee4141]

Hi Martin, it's good to see you're still working on your route.

I had a similar problem when RE would reject a track section. It was quite a while ago, but I think I managed to locate the offending track section in the tdb and then changed the tile reference so that the track section was still in the tdb but not in the original position - it was laying in an adjacent tile somewhere ....Geoff Forrest ( Ozziedriver ) came up with this idea....I believe you can also change the height so that the section gets buried below the terrain.

Then a new track section was added in place of the removed section....but it is important not to try to add a similar section as that removed...use a shorter or longer section so that the original node positions are changed. This worked OK, in fact it was used in more than one location.

Your situation might not be the same as mine, but this could provide another method for you to try.

[docmartin]

Thanks, Danny. Certainly worth a try.

[peacockg]

Hi Martin
Have you tried "Rebuild Track Database".
If this fails, it will usually stop above the problem. So note down the tile and position, then get down to ground level and investigate at this position.
Two other possibilities, both involve tile boundaries. A long piece of track crossing a tile boundary,or a point placed over a tile boundary, might cause a problem with the tdb, and these problems seem to wait until you are working miles away before they cause mayhem.

Garry

[docmartin]

On second thoughts, I'm pretty sure that the technique you describe, Danny, won't work since the problem is not a rogue track section as such. It is that any addition or alteration I make in the route that adds or deletes existing track or signals and thus changes entries in the tdb causes a problem which prevents me from running activities. For example, I tried deleting a lot of trackwork in the area I was working on when I first noticed the problem and experienced the same issue. The only thing I have been able to do successfully is to add a couple of track sections which were totally unconnected to any existing track.

Nor do I think, Garry, that a tdb rebuild will work. I have found, and this has been well documented on the forums, that with a route of any size an automatic rebuild throws up more problems than it solves. You get lots of "vector non-vector" errors in particular which, if they are genuine, seem to have absolutely no effect on the running of the route but which prevent completion of the tdb rebuild and would certainly stop one from identifying a specific problem.

The only possible solution I can think of is to locate among my saved versions of the route one in which the tdb is functioning OK, substitute it in my current version of the route and then delete any trackwork I have laid subsequent to the old tdb version to bring the tiles back into coordination with the tdb. This shouldn't affect things too much since the problem began when I was adding an extension to the route that could easily be dispensed with. And fortunately I have learnt from bitter experience to keep numerous backups; I keep a backup everyday for the current working month and backups from the 1st of each month going back to 1 December 2014 so I should with a bit of effort find a working tdb, hopefully not too far back.

[dee4141]

Martin, if you have good backups then it's definitely the safest and surest way to make progress again....hopefully you won't lose too much work....good luck!