Genma Saotome, on 11 December 2011 - 08:36 PM, said:
There has been something rolling around in my mind that says "there is a problem with this idea" and I think I've pulled it out of the goo to look at and it's this: When a revision / patch occurs how do you find the thing to patch?
Finding the thing to patch is easy. The readme with the patch tells you what it's called and you open that thing in the content directory you've dumped everything in. (Or you can add an extra level of organisation by using multiple content directories as Wayne mentioned.) Actually patching things is a more interesting subject than finding them... (well, for zip files anyway; directory patching is identical to MSTS).
Genma Saotome, on 11 December 2011 - 08:36 PM, said:
Second, am I correct in understanding that the proposal allows for any sort of directory structure to fall under the top level directory of content? Everyone can do something different as it suits them? If so, that's flexible... perhaps waaaay too flexible for Joe Average to wrap his mind around on managing tens of thousand of files.
OTOH, if my understanding is incorrect, that there is an expected structure that exists under the top level directory... what is it?
It's not clear to me what directory you are refering to by "top level" here. Let's see if I can name everything:
\OpenRails\Content
This is a content directory. There can be any number of these and OR will merge its view as if only one existed.
\UserContentPackage1
This is a package directory. Its name is the name of the package.
\Shapes
This is a pre-defined directory. All the directories at this level are fixed in name. Extra directories will be ignored and you will not be able to access them from other files.
\Routes
This is another pre-defined directory.
\Route1 This is a required sub-directory. Certain pre-defined directories will need required sub-directories because each "item" they contain is made up of multiple files - in this case, a route will probably need multiple files to define it (the tiles and textures and so on will not be in here though).
Within each pre-defined directory, or required sub-directory when appropriate, the author can do pretty much anything they like with files and folders. So they could have all the shape files in "\UserContentPackage1\Shapes" or they could put them in sub-directories. If they put them in sub-directories, they'll need to use the sub-directory names when referencing the shapes from elsewhere.
The intention is that it is similar to MSTS, with pre-defined directory names and basic structure, but improved so that e.g. shapes are not "part" of the route and specifically allowing flexibility in organisation
within the pre-defined directories.