Track Data Structure

[amtrak115]

Some you might know that I've been looking into trying to develop an Activity Editor for ORTS. I've setup a development environment and downloaded the source files for ORTS onto my local workstation. Now I'm an "old-school" programmer who learned to program long before Object-oriented coding came along and way before C++ and C# were developed and published. I "cut my teeth" debugging and coding Assembling language code. Fortran was a "miracle" as it was a much higher lanuage than Assembly. So looking into ORTS from a source code level was somewhat eye-opening. C# and objects...was a little tough for these old programmers eyes. Now, I'm not stuck in old ways completely...I did learn Object Oriented coding but much later in life long after i moved on from a "code-monkee" to program managers. (Let the young guys do the coding and debugging...I'll manage...) anyway to keep me up to date on new techniques, i learned Object Oriented coding using a language called Visual Foxpro. Foxpro is a xbase database coding language that was later updated to work in Windows using, at that time, a new paradigm called Object coding....Believe it or not that helped me figure out some of the things going on in ORTS.

So continuing my efforts into "developing a prototype Activity Editor" I've been looking at the Track Database....Hey it's a database...right down my alley...except for the kluge that the Kuju/Microsoft developers used in the original MSTS. Then to protect the guilty, they didn't document it. I decided that this weekend while, here in North Texas, we be in a Winter Storm area...I'd dig into the intricacies and try an understand ORTS/MSTS Track Database. Not much documentation in how the data is formated in the trackdb.tbd files that are part of every route. So I've attached a PDF that Describes (in my terms) the TrackDB portion of the .TDB files. I'm asing, if anyone has the time, to review the document and identify where I've gone ....."off the rails"....(sorry couldn't resist)..I would appreciate it...

Thanks

Barry LeBoeuf aka: amtrak115 TrackDB_Description.pdf

[docmartin]

Hi Barry,
I am not a coder or in any way particularly knowledgeable about the inner workings of Open Rails and TSRE but have had to dive into the Track Database from time to time to solve problems during the ongoing construction of my Chiltern Route. As a result, as far as I can tell, your analysis of the TDB seems to me spot on.

The main reason I am responding to your post, however, is simply to encourage you to persist with your project, which in my view is sorely needed. Since I have focused primarily on route building, I have used the TSRE Activity Editor only to build simple activities to test the integrity of the latest edits to my route. I am, though, in regular contact with a fellow train simmer who is a wiz at writing activities and, using the old MSTS AE, has written a large number of quite sophisticated activities for the Chiltern route and also for some other routes. For reasons that escape me and some other train simmers I am in touch with, my route no longer opens in MSTS AE (possibly because my TDB is so extensive now that it defeats the MSTS editor, though of course TSRE has no problems with it) and therefore my activity writing friend switched to using the TSRE Activity editor. However, he has encountered all sorts of problems in using it and it became clear that a thorough revision to this aspect of the editor was needed or possibly a completely new editor. I will alert my colleague to your post in case he feels able to describe some of the issues he has faced so that, hopefully, you can avoid them as you progress with your project, though I understand that this would be somewhat jumping the gun at this early stage.

Anyway, the very best of luck to you. I will be watching your progress with great interest.

Martin

[amtrak115]

Thanks Martin,

The main reason for starting this effort was the issues I found with TSRE's Activity Editor. Now I did find a work around for most of those issues, however it was still cumbersome and frustrating. Having to switch from TSRE's Activity Editor to Trackviewer to consist editor and a text editor (because some OR events were not handled....anyway...that's what started this.

Again thanks for the input.

Later

Barry

[eric]

This matches my limited understanding of the TDB.

[amtrak115]

It's interesting going though the structure of the name-your-route.tdb file and looking at the code that Reads the data from the file used by ORTS, to "load" a route. Some comments in the code seem to indicate that some things are only done to represent what MSTS did. and in some cases you see things that ORTS does that's "May" be different from what MSTS does. an example....A tracknode may contain a reference to an entry in the Track Item Table that contain in the .tdb file, and in the definition of the track item itself, there is a reference "back" to a TrackNode. When looking at a route that is ORTS only, I think ORTS ignores the back reference in the TrackItem description....or should I say TSRE does not use that back reference. Not sure...but it's interesting .....

[eric]

re: TDB version, my understanding is that the activity files or possibly the child files for traffic/service/path have a tag with the TDB version ID in it, which is how compatibility is checked. The node and vector ID's get changed when the TDB gets reorganized with modifications, which is why the TDB indicator gets iterated.

[amtrak115]

re: TDB version, my understanding is that the activity files or possibly the child files for traffic/service/path have a tag with the TDB version ID in it, which is how compatibility is checked. The node and vector ID's get changed when the TDB gets reorganized with modifications, which is why the TDB indicator gets iterated.

Interesting. There is no reference to the Serial token in the TrackDataBaseFile.cs where all the classes and methods for parsing the .TDB file. So I made an assumption.

Barry

[eric]

You might be right -- I'm looking in a few files and not seeing it stored consistently, so maybe not.

[c44d9w]

Interesting that this thread has a bigger discussion here than on ElvasTower. Below is a copy of the response I posted there.

This is great, and a good start. I have sent you a private message with some annotations to the document. I looked at this some time in the past, but then got side-tracked.

In terms of code (how the software works), this is only the tip of the iceberg. The TrackDB is mainly concerned with location and presentation of the track. Other structures are:

• Paths (TrackPDPs, TrackPath, TrackPathNodes): Paths describe a specific route that a train will travel. A path is essentially a reference to a contiguous section of track nodes. The interesting part is that there is no direct reference (no index), instead the location is used to match path nodes and track nodes. The advantage is that the track can be changed without affecting the path. The disadvantage is that matching is more complex.
• Signals (TrackCircuits, TrackCircuitItems): This is an internal representation of the route for controlling traffic. This is what the simulation actually uses. This structure is created from the track nodes and track items.
• TCRoutePath: This is a representation of the path based on track circuits. I am not very familiar with this.

In terms of documentation, I think there have to be two separate presentations: One that documents the configuration file, including the legacy MSTS fields that are required in the files but not actually used by ORTS. And one the documents the implementation, the classes that represent the configuration data and its derived views. This should include (important) fields that are maintained by the software (not in config files). Of particular importance are relationships and references.

Roger