Search path discussion

[Travis Cobbs]

So to be clear, the way you expect it to work is like so:

given a mpd containing main.ldr, brick.dat and stud.dat  with a reference tree like so:

d:\model.mpd
  main.ldr
    3001.dat
       s\3001s01.dat
         stud.dat
   brick.dat

  brick.dat
    box.dat
    stud.dat

  stud.dat


The main.ldr reference will look in these
<mpd>    <--hit
d:\
<lib>\p
<lib>\parts

The 3001.dat reference will look in these:
<mpd>
d:\
<lib>\p
<lib>\parts    <-- hit

The s\3001s01.dat reference in 3001.dat will look in these:
<lib>\parts  (because its the parent folder of 3001.dat, just like d:\ is for the mpd)    <-- hit
<mpd>
d:\
<lib>\p 
<lib>\parts 

This last part is wrong. While logical, "current subfile directory" is never supposed to be in the part search path. In other words, 3001.dat will only be able to find s\3001s01.dat because <lib>\parts is in the standard search path. In the same way, s\3001s01.dat would not find a hypothetical s\3001s02.dat if it simply referred to it as 3001s02.dat. It is required to use s\3001s02.dat.

The stud.dat reference in s\3001s01.dat will look in these:
<lib>\parts\s  (parent folder of 3001s01.dat)
<mpd>     <-- hit
d:\
<lib>\p
<lib>\parts 

Edited.

So in short the mpd content and parent folder of the file being loaded will be prefixed to ALL following search requests?

No: the mpd content and the parent folder of the top-level file that the user opened will be prefixed to all search requests.

And every recursively loaded file will add to that by also prefixing their folder/mpd location?

As stated above, only the top-level folder is in the path. We should perhaps decide what rules should be followed if an mpd loads another mpd. I think a better solution to that may be to state that the behavior is undefined, and consider mpds loading other mpds to be invalid. (The whole point of mpds is to encapsulate a bunch of files into one, so having one load another defeats their very purpose, IMO.

Do note I make no distinction between .dat, .ldr, .mpd or if its located in parts / p etc, they are all just ldraw files being processed using a generic method.

Or are we suggesting that models have different kind of rules for resolving references then parts (which is even more messy imho).

From the standpoint of loading the files, all should be treated equal, no matter what they are or where they come from. Once the file is loaded, programs are free (and even encouraged) to detect parts and treat them differently. LDView does this (for seams), and I'm pretty sure LDCad does also.

so what would happen if you got a second mpd also containing a stud.dat which references the first mpd? 

e.g.

Code:

a.mpd
  main.ldr
     3001.dat
     b.mpd
  stud.dat

b.mpd
  main.ldr
     3001.dat
  stud.dat

If I understand the proposed system correctly it should use b.mpd's stud.dat for every brick used  in b.mpd's model's and it should use a.mpd's stud.dat for everything else.

You will end up with 2 different versions of <lib>parts\3001.dat this way.

The context approach wouldn't have this problem because every file on disk lives in it's own private container, which is very easy to cache as they never change, even when you load additional ldraw files.

In the context approach you would only end up with two different 3001.dat's if they have different ldraw sources much easier to maintain (especially in editors).

Hope this is somewhat understandable as I'm mainly trying to show we really should look beyond the single mpd impact of this 'global' system.

We can define what happens if one mpd reference another, but as I said above, I would prefer to state that it should be avoided at all costs and explicitly make the behavior undefined. I'm not entirely sure what LDView does in this situation right now. Either stud.dat from a.mpd will be used for the entire model, or stud.dat from b.mpd will be used for the entire model. (Probably a.mpd, but I'm not sure.) I'm pretty sure that it will never have two different files with the same "reference filename" in memory at one time, since my "loaded model" cache is keyed off the lower case version of that "reference filename". (Note: by "reference filename", I mean the filename listed in the type 1 line that caused the file to be loaded.)

What I'm not sure of is what it does when it encounters the second stud.dat. I think it just ignores it, but if it doesn't, it might in fact be broken.