TrainSimulations Scenery Assets in Freeware Routes: An Open Discussion

[pschlik]

For what it's worth, it is incredibly trivial in any programming language to check if a certain file exists in two places. An afternoon with python could produce a terminal tool to check if any shapes or textures in a specified route folder (the custom route) exist in a different route folder (the source [payware] route), marking the file as a copy of the original. Get a big list of the copied files, and they can be removed from the custom route and used to generate an installme.bat (automatically).

A more permanent solution would be to build in adjacent behavior to OR itself. Again, fairly trivial to look for a file of a given name in two different locations, which can be done on any 'missing' files to look for them in other routes (though ideally with a list of which routes are allowed to be scanned, so time isn't wasted looking through every single route just to find the wrong file) and load that file instead. That has the advantage of being more automated and saving loads of drive space (since files are never actually copied), but wouldn't be widely useful until a new version of OR is out as 1.6 went feature-complete like 2 months ago. Also, it would still be required to manually remove the copied files from the custom route before publishing, so this really just makes installation easier unless the route editor could load files from other routes.

[dcarleton]

Let's think about how that could work in practice....
Perhaps there could be a line in the .trk file that says:
ORTSAlternatePathForShapesAndTextures ( "..\\SP_Shasta" )

How complicated would it be to implement something like that?

[eric]

It would need to be more explicit of a path definition because TSN routes should be in their own directory, which could be on a different drive altogether, and that naming will vary by individual customer.

What ORTS might be capable of doing is searching all configured content directories and subdirectories for the first instance of a missing file or texture, which would be IO intensive, so maybe also writing a cross reference file into the route folder for use on future loading to reduce loading....


Sent from my SM-S911U using Tapatalk

[PerryPlatypus]

It would need to be more explicit of a path definition because TSN routes should be in their own directory, which could be on a different drive altogether, and that naming will vary by individual customer.

The ORTS team was working hard on some functionality to avoid the need to keep TSN routes segregated in their own directory (by looking for a missing DDS *or* a missing ACE texture if a file is found to be missing), and I believe that may have made it into the version 1.6 release - but I would like pschlik or someone else to confirm.

What ORTS might be capable of doing is searching all configured content directories and subdirectories for the first instance of a missing file or texture, which would be IO intensive, so maybe also writing a cross reference file into the route folder for use on future loading to reduce loading....

As I noted previously in this thread, it cannot be as simple as "search through the routes for the first instance of a shape or texture named XXX", because there are numerous examples of files with identical filename that are in fact *not* identical files between different TSN routes - for example, a texture that has the same *filename* in both Mullan and Shasta, but is in reality a different image.

My current thinking is the installer needs to be smart enough to know beforehand which specific route to look at for every file.

Also, I've seen several responses mentioning only Shapes and Textures, but perhaps Terrtex is also fair game? (although this subject becomes more complicated in the case of custom-painted terrtex patches, and I could see this being an area where TrainSimulations makes a reasonable exception to the rule). Perhaps even the Sound folder, Env, and others could be sources where a route developer wants to rely on our assets. I am not sure how well the aliasing will perform in all of those specific areas - and it's worth noting that by relying on aliasing, these routes would only work with future versions of ORTS, and be completely non-backwards-compatible. At the end of the day, it might be simpler to implement having an installer just copy the files over into the new route like we've always done.

[pschlik]

What ORTS might be capable of doing is searching all configured content directories and subdirectories for the first instance of a missing file or texture, which would be IO intensive, so maybe also writing a cross reference file into the route folder for use on future loading to reduce loading....

While that could work that does start to sound less like a 5 minute coding adventure as I believe the simulator itself normally knows nothing about other install locations. And sneaking in files across multiple installs feels like the sort of thing that some people wouldn't like as it appears to violate the (completely imagined, unenforced) "rule" that each install is independent. While I get where that comes from, there's also nothing technically stopping one file from loading from the C: drive and the next from the D: drive, and multiple installs can already share files if you use symbolic linking. But what counts is what the management team thinks about that and sometimes they side with convention, changing imaginary "rules" into capital R Rules.

It's definitely easier and lower risk to just look through the current installation. installme.bat requires routes to be in the same installation anyway, unless you want your installme.bat looking through the registry to find where TrainSimulations routes are installed (hint: you don't want that).

The ORTS team was working hard on some functionality to avoid the need to keep TSN routes segregated in their own directory (by looking for a missing DDS *or* a missing ACE texture if a file is found to be missing), and I believe that may have made it into the version 1.6 release - but I would like pschlik or someone else to confirm.

And yeah the whole 'don't install anything with TSN!' is another one of those "rules". The only reason not to do that was a bug in texture handling that is fixed for 1.6, and since any new feature wouldn't be until 1.7 there is time to re-train people that it's totally fine to put other routes in with your TrainSimulations install. Though I still expect 10 years from now there will be people attempting to attribute all manner of problems to installing other routes in the same place as TrainSimulations.

[superheatedsteam]

Having all the data for a route in one location is good practice from an install, update, backup, relocation and troubleshooting perspective.

In my opinion, having the application search for missing files just to suit just a small number of end users is code bloat and a waste of computing resources.

Apply the KISS principle. If an afternoon with python really is the trivial solution to the problem then why not offer that to the TrainSimulations team if they are unable to implement it themselves. TrainSimulations can then host the program on their web site for their customers to download as well as allowing for ongoing documentation, customisation and maintenance as required.

Cheers,

Marek.

[TrainSimulations]

The new policy for the use of TrainSimulations shapes and textures is now posted at the head of this thread.

Thanks,
The TrainSimulations Team

[eric]

This is a great step.

Hopefully MLT and 3DTrains can consider doing the same ( Bananarama & TorontoMainlineTrains ) with some of their route assets.

This appears to be very similar to the existing reskin policies -- do NOT include the actual payware shapefiles....

[Orbita]

This is a great step.

Hopefully MLT and 3DTrains can consider doing the same ( Bananarama & TorontoMainlineTrains ) with some of their route assets.

This appears to be very similar to the existing reskin policies -- do NOT include the actual payware shapefiles....

I'm also consider maybe 3DTrainStuff. Particularly their West Colton route. There are some shapes in there of particular interest. Such as the vintage car models.

[emd645e3c]

The thought of something along these lines did cross my mind years ago when TS released the free version of whatever route ( Stevens pass ?? ) it was. Since the shapes in it were being freely distributed would it of been acceptable to release freeware routes with both the shapes and textures from it and just give credit.

Steve

[fchrist16]

This is wonderful news TrainSimulations!!!!

Regards,

-Frank C.