LibraryFAQ
Rail3dWiki — Library faq
Mark Goodspeed answers questions about the Rail3D Library
Q Is the library to be the main/only source of models?
- Only: No — There is always distribution by email, group vault, layout packages and of course someone can set up their own website and library of models.
- Main: Yes — at least until someone comes up with a better idea.
As a point of principle I am strongly in favour of having a definitive reference library of models. If this can be complete as well — even better. Having a single main source of models avoids many of the problems associated with other programs such as msts, where models may be available from one or more of a large number of competing distribution sites.
So, I am convinced that for Rail3D we should have a definitive central library, we should strive to ensure the contents are compatible and not duplicating or fighting each other, and ideally it should be as complete as possible. Standards are good, so if we have a standard for folder structure it should be encouraged.
And of course the updater — assuming the library is up-to-date, the updater takes care of distributing updated files to users with the minimum of hassle - again contrast with msts.
Q For clarification, is the library accessed via the updater and the web site the same library?
Yes. The only difference is that the online library on www.rail3d.info allows you to browse through individual folders whereas the updater pulls down a single list from the root, but these are generated at the same time so should be identical.
Q When a user distributes a package, we really need to keep the folder structure correct — I found my J36 in a folder called \Stock\Steam as well as my own version in its correct place and that is just one example of incorrect folder structure (Russell).
Of course it helps if everyone has the same folder structure, which is another argument for having a central definitive reference and a distribution mechanism such as the updater that preserves that.
In theory:
- if you have signed your model, the package contents won’t overwrite it or duplicate it.
- if you have items (in whatever folder) the package contents will go into the same folder, ie if you originally have model xx in folder yy/zz and you open a package with a new version of xx, the package will update the file in yy/zz regardless of where the package creator has it.
At least that’s the design - if it’s not happening properly, please report a bug ;-)
Q Does the updater place downloaded items in the “correct” folders?
On a clean installation the updater places things in the “correct” folder.
In order — the folder structure and file location on my machine determines the folder structure and file locations of the online library and the updater catalogue and these in turn determine the target folder of the updater.
However, like the packager, the updater is designed to recognise local differences, so if you have a particular model in a non-standard location the updater may pull down an updated version of the model but should put the updated version in your chosen non standard location instead of the standard. Again, that’s the design aim, if it ain’t doing it please raise a bug.
Q Downloaded items from the web site are in a zip file, so it is at the whim of the user what folder an item ends up in?
Yes. But users should be encouraged to copy the folder structure of the library, or better still use the updater which gives you the standard folder structure by default.
A particular issue is sub-components, the zips on the library should include all required sub-components and textures - which of course may come from different folders. If you use the zip the natural tendency is to unzip the contents into the same folder. The updater of course knows which folder they should be in and puts them there (Except as above of course).
imho the updater is so good that I can’t see why anyone wouldn’t want to use it. Getting stuff manually is such a hassle and the updater is so easy why wouldn’t you?
Q Should we do away with uploading stock etc to the group vault?
Well, that would be ok if the main library could be kept up to date. As discussed I don’t have enough time to keep on top of it very often, but if it was updated more often and more likely to be up-to-date then it would be a preferable route.
At the moment, the vault is a useful way to distribute stuff pending their arrival in the library.
Q I expect the group vault contains valuable items not in the library.
I don’t think there is much there that I haven’t got (unless people are sneaking stuff in and not telling anyone). I usually download anything uploaded straight away: most of the stuff that hasn’t got to the library yet is sitting on my machine in the “Rail3D stuff waiting to be processed” folder.
Q On a practical note, it would be nice to have the ability to de-select all items in the updater before choosing the one(s) you want.
I’ve heard that said before ;-)
Q The library (stock and scenery) probably needs a clear out of old items not “of sufficiently high standard”
Yes, it’s not too bad, I have cleared a lot of old stuff out, but I have kept some in even though the standard is not good, simply because it would leave a big hole without it.
Q Perhaps adding a version number in the stock/scenery file (by the library updater) might be an idea?
Possibly. The updater operates on file date/time which to my mind is good enough. You know how much trouble I have with program version numbers ;-)
Q So do I have to use the “standard” arrangement of folders?
No. It’s a good idea for all sorts of reasons to stick to the standard as it makes a lot of things work more smoothly. But see notes above re the updater and the packager, if you decide you prefer a different folder structure for models, the updater ought to be able to cope with it.
import