Standardize official search path

[Travis Cobbs]

MPD subfiles
Model Directory (the directory that the top-level model resides in)
<LDraw>\p
<LDraw>\parts
<LDraw>\models

I have no problem with this part (it basically just adds models to the spec.)

But I never really liked the following

<LDraw>\Unofficial\p
<LDraw>\Unofficial\parts

Because it breaks the 'package', also imho you should look in the unofficial location before the official one because part and primitives can be updated.
With the current order the old ones will still load.

I'm OK if Unofficial is left out of the official spec, but I am not OK with putting it somewhere else in the spec. (Also, I'd prefer if it were documented in the spec as an optional pair of paths that can be checked after everything else.) The Unofficial directory was something that I created for LDView. If LDView cannot find a part, it checks ldraw.org for an unofficial part. If it finds it, it downloads it and puts it into Unofficial. Note that this was not designed to allow users to have the latest possible unofficial version of existing parts. It was designed purely to find (and auto-download) missing parts. LDView never deletes things it has downloaded into Unofficial. However, since Unofficial comes at the end of the search path, that doesn't really matter, since as soon as a part becomes official, the official version will be loaded instead of the unofficial version. (LDView also keeps track of when it downloaded unofficial files so that after a configurable time has passed, it can check to see if the file has updated. I only does this if it loads an unofficial file due to not finding it anywhere else in the search path.)

I also would like to make clear this order is to be followed within the context of the currently begin processed ldraw file.

Meaning a stud.dat in the mpd's subfolder (or as a submodel) will not be used for each part in the scene.

It will only be used if it's actually referenced inside the mpd itself trough a "1 ..... stud.dat" line.

This because all references inside the mpd will be tested against the parent folder.

But once e.g. 3001.dat start loading it will look inside it's own folder (parts) first before going to the library p folder etc.

This will also ensure you can cache meshes.

I'm not sure I completely understand what you are saying. My expectation (based on the proposed search path) is that if the user puts a custom stud.dat in the directory alongside the main model (or inside the mpd), the proposed path order (and what I feel is correct) would use that stud.dat for the entire model. LDView doesn't support having two different versions of the same filename at once. Once LDView loads a file (from disk, or while processing an MPD), that loaded copy goes into its in-memory cache, and all future references to that filename come from the cache. The cache isn't hierarchical either (other than that if the type 1 line includes any slashes, those are part of the filename key in the cache).

Just to be clear, I'm not saying that we have to define the spec based on how LDView currently behaves. I am saying that I think it behaves fine, though. If we define the spec to be different, we should do so because we don't think the way I proposed is right.

Your last sentence seems to say that you are arguing in favor of what LDView already does. However, the rest of that section is arguing for something else, which is why I said that I don't completely understand what you are saying.

In case I'm not clear here, LDView does the following:

1. Starts at the model the user opens (the main model). Records the directory that this model resides in for use in search path lookups.
   
2. Reads the model file.
   
3. If the model file is an MPD, parses it enough to know what MPD submodels are inside. Each of these goes into its global "loaded models" cache keyed off of the filename in the 0 FILE line.
   
4. Second pass full parse of the file (as well as parsing the MPD submodels). For each type 1 line, it first checks to see if there is an entry in its global "loaded models" cache matching the filename portion of the type 1 line. If not, it uses the search path to find the specified file and jumps back to step 2 for that file, then loads it and inserts it into the global "loaded models" cache based on the type 1 filename, then references the result. If the model was already in the global "loaded models" cache, it instead references the cache entry.