Mini Route Blues The Problem with Mini Routes
#1
Posted 31 December 2018 - 06:31 AM
Mini Routes were on my mind going to bed last night and again this morning when I woke up. I know, I need more to do. I'm off for a couple of weeks and I'm toying with a game. At any rate, I thought about how we make Mini Routes, and I wondered... why? I tried setting up a Mini Route last night in Windows XP with simlinks and it didn't work. Perhaps it's just Windows XP. I don't know, but it made me go reaching for a better way of doing things.
For a Mini Route we need three folders with their content. GLOBAL, ROUTES, and TRAINS with a trains.exe file in there. But why do we need that at all? If you have a folder that has your GLOBAL folder (and the trains.exe file), say one for US routes, one for UK routes, one for European routes, etc., then you have what you need. In Yardmaster, you point the program to each of the directories it needs to find your consists, engines, and wagons. Why couldn't Open Rails do the same thing with Mini Routes?
In the options tab (or in its own tab), you choose where the GLOBAL folder is. Then, you have options to build a Mini Route without actually having to build a Mini Route. Say you want to create a Mini Route for the Milwaukee Road. You choose the two or three routes that cover that road and add them to it. Then, lets say you have a folder set aside just for Milwaukee Road with their rolling stock in it. You point the game to that folder, hit the create button, and now you have a Mini Route, without having to use up disk space. It's all found in a config file for that Mini Route. You could even get more inventive and go with different eras for different Mini Routes.
The question is, could this be done? Has it already been put on the "to do" list and I just didn't see it? If this could happen, it would free people up to create their own file system for Open Rails, pointing the program to their data without having to move it around or create multiple Mini Routes that take up way too much diskspace.
Anyway, that was my rant for the morning. I'm off to toy around with this game again.
#2
Posted 31 December 2018 - 07:35 AM
What was new to me is that people are editing the consist files to re-link engines and wagons in them. Has there been some kind of editor created that does this? Can it be done in Goku's Consist Editor? It would be an awesome function to put in a potential Open Rails Consist Editor. I like the guy's use of the word "divorced" here. If you point the game to different directories that cover different functions, then it doesn't matter how your file system is set up, you can always point it to the files it needs to function.
#3
Posted 31 December 2018 - 09:25 AM
There are utilities you can download for free that give you a graphical user interface to the symlink process. You can also download plugin's to windows explorer that add right mouse invoked symlink funtions to that program, both of which make symlinks easy to use.
In some cases I use symlinks to cast individual \trains folders into various miniroutes but i also use an inexpensive utility called Beyond Compare to keep lots of \trains\folders identical (FWIW I also use a "library" for all rolling stock. They have a generous trial period and I highly recommend this tool for use if you have multiple \trains directories with numerous supposed-to-be-but-maybe-are-not-anymore identical folders
In short it works very well. Part of your problem may be inexperience, part of it may be Win XP.
#4
Posted 31 December 2018 - 10:21 AM
I also don't like how the Timetables are put in the ACTIVITY folder. Timetable needs its own folder, with a separate folder for each timetable with all of the relevant information within (paths, consists, pools, etc.). All you would have to do is expand the pools concept a little to create blocks of cars for timetable mode and you wouldn't even have to have a consist editor for it. In fact, the block of cars can be a spreadsheet with the name of the cars and links to where they are found.
#5
Posted 31 December 2018 - 05:04 PM
shadowmane, on 31 December 2018 - 10:21 AM, said:
Everything in those tabs applies to ALL locations when you run OR. What if the relationship between your central library and all those miniroutes is not 1:many? For instance you could have a \global directory specific to Europe and another to North America, or one for route development and another for playing the game.
IOW in some cases there are legitimate mini-route specific folders and in other cases there are sharable folders and both conditions can exist in many combinations on one PC. IMO it is much better each end user make those decisions than somebody on the OR team assuming he knows what's right for everyone.
#6
Posted 31 December 2018 - 07:12 PM
You can still set up Mini Routes, and you can still use simlinks to do everything you were able to do before. If the program broke down where it pulled the data from in each instance, and the user can define that (or leave it alone and go with just the Mini Route directory), it would provide a more powerful way to put things together.
And yes, you would be able to have a Global folder for the European stuff, one for the US stuff, and one for just about anything you want it for. You would be able to define as much or as little as you want the program to look for, and tell it where to look for it. If you don't define it, the program simply looks for it where it has always looked for it (leaving you to put things together however you like). It would be one option among many, thus why it would be put in the options section under the content tab. You're simply defining where to pull the content from. This is something that probably should have been thought of a long time ago.
Say an end user wants a setup like this:
Open Rails OR Data GLOBAL US UK Europe Trainsets US Milwaukee Road Norfolk Southern Great Western UK BR LMS LNER Southern SDJR Europe Routes RMD East RMD West
If he could simply point the game to the different folders in the options content tab for each "Mini Route" he wants to deal with, he has the data in one place, but if, say, he wants to set up something just for the Milwaukee Road, he would point the game to the US GLOBAL file, the Route file, and the Milwaukee Road folder. The game would then use the data from the US Global folder combined with the data from the Route folder to build the world like it does when it's all together in a Mini Route. Then it would find the consists, wagons and engines where the end user told the game to find it.
#7
Posted 31 December 2018 - 09:10 PM
#8
Posted 01 January 2019 - 08:38 AM
Is there a potential for breaking things? Of course. There is that potential now. But if the game is doing the heavy lifting, enabling you to set up mini routes without moving files, what's the drawback in that? It's just a different way of doing things. Remember, most end users aren't programmers, and won't have their system set up like a programmer. They just want to simulate running a train, or a "day in the life of a railroad" using timetable mode.
#9
Posted 03 January 2019 - 09:32 AM
shadowmane, on 31 December 2018 - 06:31 AM, said:
Interestingly, although you started by asking why do we make mini routes (by hand), I don't think you addressed why you make mini routes in the first place - so let me ask, what is the purpose of creating a mini route for Open Rails?
I ask this because we are working on letting content be shared between the installation profiles, so that you get all of your content as one; it'll still work as it does today for existing scenarios, but you'll also be able to load up any consists into any route (even via activities/timetables).
shadowmane, on 31 December 2018 - 07:35 AM, said:
I am hopeful that the above plan to merge the installation profiles would remove the need to put in these specialised paths in the consists, as a reference from one TRAINS\CONSISTS file would scan all the TRAINS\TRAINSET folders to find it (preferring its own first of course, and probably other priority orders).
What hasn't been figured out yet is how all the consists would be organised, but that will be part of the work on the consist file format (which will very likely contain metadata properties) and the consist editor itself.
shadowmane, on 31 December 2018 - 10:21 AM, said:
All good thoughts; although we won't be changing the layout within MSTS content, we are planning to create a new content directory file format (AKA structure) and a content directory editor to manage/inspect it.
Genma Saotome, on 31 December 2018 - 05:04 PM, said:
We also need to remember to keep Open Rails simple for the average user, who, I posit, wants to add content without any questions and be able to mix and match it with all their existing content.
For that reason I am not supportive of this thread's idea to have OR manage GLOBAL, ROUTES, and TRAINS with individual configuration - instead, I want all the content to be treated as one (even if it isn't on disk) for the average user, and document how content is "found" so that users with more advanced needs can set things up just right.
shadowmane, on 01 January 2019 - 08:38 AM, said:
A good guideline is to think of features as starting out at minus 100 points and having to demonstrate that much worth to make it out of the hole. This particular one is duplicating what people can already accomplish, and only a few people (relative to all users) would even want to set it up AFAICT. So the drawback is a bunch of additional complexity in the code for a minority of users who could do the same thing with OS-level features.
#10
Posted 03 January 2019 - 06:13 PM
I've been tooling around a looking at RTrainsim the last couple of days. Have you guys looked at what was done there to get any ideas? I like how they have their cabs set up, and how they have done certain effects. If you had their way of putting a locomotive together with Open Rails' way of doing physics, you would already have all of the capabilities of Run8 and then some.