[steamer_ctn]

As a result of the new operational turntables that Carlo has created, I started thinking about a point that was raised in the now rather long turntable thread, re the possibility of making some static turntable objects into working turntables. In some of the routes that I have, there are some turntables that have been made using static objects, and I would like to see them made operational if possible.

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

[Csantucci]

More precisely the actual include process can't add blocks to a list of blocks (e.g. a new light within the lights section in the .eng file, or a TrackShape block within the TrackShapes section of tsection.dat). As of now, to modify a list of blocks with the include process, the whole modified list must be present in the include file.

[copperpen]

Only a select number of turntables in the tsection can be animated, the rest either have no IDX entries, are not constructed in the same way, or both. Looking at "includes", they are generally a method of including common data structures into an existing file set, thus reducing the overall file size and allowing for bulk edits using a single include file common to all that use a particular data set.

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.

[elvasleis]

Hi Peter,
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.

[Jovet]

An advantage of re-making the turntable shapes is that we can give them some 2016 quality versus some 2001.

[steamer_ctn]

jovet, on 31 May 2016 - 08:16 AM, said:

An advantage of re-making the turntable shapes is that we can give them some 2016 quality versus some 2001.

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.

[Jovet]

steamer_ctn, on 31 May 2016 - 11:03 PM, 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.

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.

[jared2982]

As it looks now the main goal appears to be trying to get old obsolete turntables to work. Nothing is impossible. The A1t27m and 16m Turtables are indeed functioning. Making static turntables functional is not impossible. It can be accomplished by rebuilding the turntable and editing you tsection.dat file with the appropriate entries. This can be done without having to acquire space in the standardized tsection.dat by making the route a mini route. You can go the extra mile and contact Derek to have the entries added to the resection.dat if you wish.

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.

[steamer_ctn]

jovet, on 01 June 2016 - 09:23 AM, 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.

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?

[Jovet]

jared2982, on 01 June 2016 - 10:58 AM, said:

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.

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:

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?

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.

[Csantucci]

Returning to Peter's original problem:
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).
 tsection.zip (548bytes)
Number of downloads: 1440
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.
 tsectionint.zip (1.11MB)
Number of downloads: 2282
I'm open for discussion about the opportunity or not to have this feature included in OR.

[James Ross]

 Csantucci, on 04 June 2016 - 05:24 AM, said:

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.

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.

[Csantucci]

Hello James,
here is the patch
 extendedtsections1.zip (970bytes)
Number of downloads: 1129

[James Ross]

 Csantucci, on 06 June 2016 - 12:38 PM, said:

Hello James,
here is the patch
extendedtsections1.zip

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.

[Csantucci]

A blueprint has been created here https://blueprints.l...or-tsection-dat .