Turntables - Converting Static Ones into Working Ones?
#1
Posted 30 May 2016 - 02:46 AM
My understanding of the concept for turntables is that they need to be in the Tsection file for them to be able to operate. Naturally a static object won't be in the Tsection file, so I am wondering whether it would be possible to use an "include" style of process to add the relevant code to the Tsection file for the route. By doing it on a route by route basis, it would eliminate the need to make modifications to the universal Tsection as the changes would only apply to the route loaded.
After speaking to Carlo, he has suggested that the current include methodology replaces lines of information rather then adding to it, so it would not work in this scenario. Thus a new method of adding to the Tsection file would be required.
As a result there are two questions that come to mind:
i) Is there interest in the turntable concept being extended to include the ability for static turntable objects to be animated?
ii) Any thoughts on how an alternative "include" functionality can be developed?
Thanks
#2
Posted 30 May 2016 - 04:34 AM
#3
Posted 30 May 2016 - 05:04 AM
The animation of turntables is already built in to the model and Carlo has added the functionality to make them work within a route database. It has been proven in the turntable thread that it is not a requirement for a turntable to be in the global tsection.dat, but the turntable must have animation already present in the shape file.
#4
Posted 30 May 2016 - 06:40 AM
I would love to see the turntables working on all the Australian routes that have them but it seems the turntable models would have to be remade.
I see that a lot of the Australian turntables are the same model used in several Australian routes.
Regards Geoff.
#5
Posted 31 May 2016 - 08:16 AM
#6
Posted 31 May 2016 - 11:03 PM
jovet, on 31 May 2016 - 08:16 AM, said:
Whilst I agree that this is the "ideal" approach, the original modeller may not be still active, so re-making the turntable shapes may not be possible without somebody being prepared to rebuild them.
I would prefer to settle for a 2001 working model turntable model rather then a static one.
#7
Posted 01 June 2016 - 09:23 AM
steamer_ctn, on 31 May 2016 - 11:03 PM, said:
The original modeller is not really relevant. Many talented people (including myself) are quite capable of recreating the appropriate shapes from scratch that match the original dimensions/specs but look a lot better and are also able to be animated properly. As long as the goal is to have them fit in with the appropriate track system (X-Tracks, DB/US-Tracks, ScaleRail, UKFS, etc.) it shouldn't matter who creates them.
#8
Posted 01 June 2016 - 10:58 AM
The more feasible way would be to look to the future and design new turntables. These will no doubt start to surface now that turntables are being worked on. I have two that I'm currently testing. Nothing special in appearance yet just a basic model strictly for testing. Also it is worth noting that new tables can be constructed to the demensions of the older turntables and there shape files replaced in Global folder as jovet mentioned.
I wonder if a way for these to be entered in a local tsection file in the route folder, similar to the way dynamic track works, would be an option... This approach would need more thought and discussion among the community as how to proceed.
#9
Posted 01 June 2016 - 02:04 PM
jovet, on 01 June 2016 - 09:23 AM, said:
Again I agree in principle, but as I am not a talented modeller, are you offering a service to rebuild turntables to the "new" standard for routes where the original modeller has left the community?
#10
Posted 03 June 2016 - 02:31 PM
jared2982, on 01 June 2016 - 10:58 AM, said:
As the "local" tsection.dat is currently only for the route's dynamic track, I vote that it stays that way. I think it's a lot easier for us (as a community) to manage a single, global tsection.dat than to try and spin off its duties. If everyone can be the same then we can get consistent results.
steamer_ctn, on 01 June 2016 - 02:04 PM, said:
The thought has crossed my mind more than once. I haven't seen all of the turntable shapes out there, but I've been annoyed with some of the default ones for a long time.
#11
Posted 04 June 2016 - 05:24 AM
I think that providing the ability to add route specific TrackShapes and TrackSections may be useful. The management of a unique tsection.dat has been effective, but the structure in itself is quite rigid.
So I made some tests, and I found that, unlike I thought, it is possible to use "include" files with tsection.dat after some small code changes.
So the feature allows to insert in the Routes's Openrails.dat a tsection.dat file that first includes the tsection.dat contained in the Train Simulator Global folder, and then includes some route specific TrackShapes and TrackSections. It can be also used to modify some TrackShapes and TrackSections included in the Global tsection.dat.
I attach here an example file that I tested with the USA1 route (but it could be any other route).

Number of downloads: 1439
The first TrackSection and TrackShape is present also in the Global tsection.dat, so the effect is that the original TrackSection and TrackShape are modified; the second ones are not present, and so they are added to the lists.
I think this can solve problems like the one of Peter.
Suggestion: to be able to use these modified items with the actual MSTS RE it is necessary that these modified items are present also in the original tsection.dat file. However, when the work with the RE is terminated and route is distributed, it is sufficient to distribute the above route's specific tsection.dat.
I attach here also the modified .exe and .dll files, that must replace the ones within x.3551. They include also the last changes for the car spawner lists.

Number of downloads: 2281
I'm open for discussion about the opportunity or not to have this feature included in OR.
#12
Posted 06 June 2016 - 12:03 PM
Csantucci, on 04 June 2016 - 05:24 AM, said:
I'd like to know what kinds of changes these are, as it is a complex area of code already and don't want to make things any worse or limit what we can do in the future.
#13
Posted 06 June 2016 - 12:38 PM
#14
Posted 21 June 2016 - 01:27 PM
Csantucci, on 06 June 2016 - 12:38 PM, said:
Thanks, that's pretty simple - good work! :)
Please feel free to commit the code if you think the normal rules are met (particularly, no objections from the community).
And sorry about the time to reply, I've had very little free time recently but promise to get to everything eventually.
#15
Posted 23 June 2016 - 04:17 AM