[Genma Saotome]

I'm always fiddling around with how I have set up MSTS and Open Rails... it's always one thing or another that I'm trying to "fix". My latest effort got started when I had to upgrade my C:\ drive from a small SSD to a larger one (what a PITA that was!). I eventually got that working which left me with the old SSD... about 80GB. Not knowing what else to do with it I installed it as an ordinary drive and there it sat for a while while the ideas swirled around in my head.

What I wanted to get was to take advantage of the speed of the SSD AND have era-specific \trainset directories.

This is what I've come up with:

• All routes are placed on the old SSD drive, making them very fast to read/load into a sim.
  
• I use Junctions to place logical copies in several other locations that are organized for either use in AE/RE or as a run environment setup for a specific era. These are on ordinary disc drives.
  
• Because the rolling stock roster is so large I thought it impractical to use Junctions again so instead I just copy directories to where I want to use them. All edits to .wags and .engs occur in the library.

The net effect is I can have multiple instances of a specific route that are "joined" with era specific cars and locomotives. If I need to do edits on that route I can either copy it from the SSD drive to \MSTS_Development\routes (the copy will isolate my work from the run environment) or use a Junction in which case all updates appear in the run environment in real time.

So far I'm pleased with the result. I can't say that is better (or worse) than any other set up as what's best for each individual varies so much but for my arcane desires it works well. IIRC <100gb SSD's can be purchased for under $100 now and so the approach can be reproduced at a reasonable price.

Now... the expected questions:
Q: Why isn't everything on the SSD?
A1: 80GB is pretty small. I've already used up 5/8ths of its capacity and wanted to reserve open space for more routes and by using Junctions to larger drives I can keep (1) my rolling stock off the SSD and (2) not have MSTS on the SSD. Also, most rolling stock files are read at game start and so fast read speed then doesn't add much value.

Q: Would I do the same thing if I had a bigger SSD?
A: Pretty much. The SSD gives me speed but the other objective was era specific \trainset trees and given the limitations of the KUJU design the only way to accomplish that is to have multiple \trainset folders, each holding the subset of the whole rolling stock library that is correct for that era. So if I had a larger SSD I'd still use the era specific directories as shown and given what I said about when rolling stock is read I don't see the need to have those files on the SSD... so no, I wouldn't change anything with a larger SSD.
===========

Hope this gives folks some useful ideas.

[Lindsayts]

I have done something similiar on my systems for both the train sim and Linux.

MSTS and OR are on an SSD, with Linux the main root directory containing the kernel and the main libraries are on a normal drive, one does not require an SSD for this as both the kernel and the main libraries are always loaded into ram once the system is running, Note: the main usr directory containing the rest of the system is on another SSD.. Interestingly Linux starts up in a flash with this setup.

Nearly all development work on OR is done on native Linux or by using wine. Each major route has its own installation, any common rolling stock is in a separate directory, updates and mods to the machines are done here and then automaticaly copied to where they are used. I did it this way rather than simlinks (junctions in windows) as I like to keep all modified items seperate in a single location.

Lindsay

[Genma Saotome]

Food for thought....

The problem of dealing with too many directories in one \trainset folder has bugged me for years. I just don't want to see the wrong stuff when I'm looking for things -- and that's not just making up a consist but also includes zipping up groups of directories for distribution. That issue led me to try and find some solution for how I happen to think of all my routes -- by era -- and so I've setup era specific miniroute installations.

Having setup up those installations I then wanted to improve the organization of the rolling stock folder (\Trainset). After multiple trials I went both radically different from MSTS and logically "straightforward" and set up a directory tree based on Country of Origin plus build date.

The next step is something I think would be an improvement but I cannot fully implement because the OR software doesn't support route specific consists, etc.... and that is to have route specific \consists and \trainset folders in addition to the KUJU design of installation-wide \consist & \trainset. But if one were to ignore that feture and look instead at the installation based consists and trainset... that is possible and that is what I'm doing now. The whole picture would look like this:

• Directories would be manually copied from the library to where they are used.
  
• Multiple instances of the same rolling stock may occur... and could get out of sync with each other.
  
• Adding route specific consists and trainsets helps you keep a focus on what is being used only by that route / what was distributed with that route.

All of that would be okay.




OTOH, I think having the OR software "look up" and read the .eng and .wag data from a standardized library would be much, much better. It would look like this:

• There would be only one occurrence of each .wag; Everything would be "the master" and all the problems inherent with having copies everywhere would go away.
  
• The consist file would hold the path to the standard library.
  
• Route installations would not need any \trainset folders.

I do think something along those lines would be best for OR and the user community. The basic structure of the rolling stock library can be 90% defined before implementation and anything overlooked could be easily added. That would leave changing the way paths work on the WagonData() line in consists... not a terribly hard problem.



n.b., for simplicity I omitted a level from the rolling stock library tree displayed above... between Country And Built... are \Locomotives, \Freight Cars, and \Passenger Cars. Whatever directories belong under each would be specific to that type (e.g., Steam, Diesel, Electric would be under Locomotive where as things like Boxcar only belong under Freight cars).

[rdamurphy]

Google "Ramdisk". Mine doubled FPS in OR...

Robert

[conductorchris]

Robert, I googled it. Thank you - something new to learn.
Do you load openrails into the ramdisk before playing? Is there room?

[Genma Saotome]

Something else I did was add "\Route Consists" to each folder (it might not be apparent in the first diagram but the what is being junctioned is the routes' home directory and so \trains is not included. Adding "\Route Consists" to each route on the SSD means the .con files will appear in each of the OR folders when I can then copy them to \trains\consists.

I could also do that with \trainsets but I'm not sure about that yet.

[Genma Saotome]

Some revisions... I decided I wanted to have the individual installations reflect both era and geographic local and so with a bit of initial work my setup is like this:


On the left, in peach, is a list of routes installed on a small SSD drive. I handle them entirely as read-only.

Across the top, in green, is a list of mini-route installations. The names shown are the folder names. Each one of those has the usual \global, \sound, \routes, and \trains folders.

In the center, in blue, is how I have used Windows Junctions to present what is on the SSD drive to the various mini route installations. As you can see some routes appear in more than one mini-route. Because of how junctions work, no files are actually copied from the SSD... it's all just links (think shortcuts).

The bottom rows, in dull yellow, show two more content directories on the SSD that are junctioned to the mini-route installations

The result is one set of files, located on an SSD, appear to be installed in many other directories... which directories depends on geographic location and era. As you can see they're junctioned to all of the mini-route folders.

What is not shown here is \trains, with it's two folders of \consists and \trainsets. These are created in each mini-route -- nothing is junctioned -- and all of the files contained in each of those is specific and unique to the mini-route. This means there are no Western Pacific steam locomotives in the Midwest mini-routes, no AC powered modern Locomotives outside of "aaaaaaa 1895-Present", and so on.

[conductorchris]

I've run into problems with activity generator and junctions. Somewhere there must be some kind of links that expected to check the trainset folder in the same relative location as the route.

Has this come up in any other way?

Christopher

[Genma Saotome]

conductorchris, on 03 May 2015 - 05:38 PM, said:

I've run into problems with activity generator and junctions. Somewhere there must be some kind of links that expected to check the trainset folder in the same relative location as the route.

Has this come up in any other way?

Christopher

I'm not familiar with Activity Generator so I can't really answer your question. I can add that folders for \trains (with \consists AND \trainsets) is present in every mini-route -- that is to say each of the green columns in my image, above, has those folders as they are required for OR to work. What is in them varies from one column to the next.