Genma Saotome, on 12 June 2017 - 07:50 PM, said:
I very much agree with what's said above.
I'm greatly worried by the impact of any changes to the .tdb data structure as a result of the switch to procedural track. The .tdb is not just about displaying tracks - it is the core of everything which has to do with placing or moving anything which has any relation to tracks (and .rdb to roads).
A simple check in the compiler for references to the 'TrackNode' variable shows 173 references in over 20 modules.
When it is stated that "all required C# code will be provided", does that mean the required update to all these 20+ modules? And, ofcourse, the present structure will have to be maintained in parallel to the new structure, as existing routes will clearly not be converted.
And worse - that update to those 20+ modules will have to be in place and up and running before even a single millimeter of procedural track can be laid. For without it, OR cannot run using such a route, as nothing can be placed and no train can move, because all placement and movement is based on the 'traveller' module, and that is based on the present .tdb structure.
That 'traveller' module is a very complex piece of code, and I don't think that anyone with knowledge of that bit of code is overjoyed by the prospect of changes to it. Similar for the derivation of TrackCircuitSections - the core of everything which has to do with signals and train control. That too is based on the present .tdb structure, and that too is quite complex.
Ofcourse, it could be that the .tdb structure need not be changed - but there is no statement to this. But given how things are described, and based on previous discussions, I would be greatly surprised if that could all be done using the present .tdb structure.
Clarification on this, and proposals on both the new structure and the way the required changes are to be implemented, would be very welcome before work is started on the editor.
Regards,
Rob Roeterdink