Search path discussion

[Roland Melkert]

I'm writing this as a reply to the original post instead of replying to one of the sub-posts. What I say will probably refer to multiple threads. Based on everything written here, I would like to make the following suggestion for the official LDraw search path:

1. 0 FILE references in the currently active MPD. Note: an MPD in this context is any LDraw file that contains 0 FILE lines. "Currently active" in this context means that the files are only visible inside the MPD, and are not visible to any other files.
   
2. The directory containing the top-level model opened by the user. (Note: I think this dates to ldraw.exe. We can decide that it's not a good idea, but I don't personally think we should do that.)
   
3. <LDraw Directory>\p
   
4. <LDraw Directory>\parts
   
5. <LDraw Directory>\models
   

I could see adding an entry either before or after 2 that is the directory containing the current LDraw file.

The first hit found when searching for files in the above order would be used. 

Additionally, it should be noted that many tools add the following two entries to the end of their search path, but they are not part of the LDraw standard:

1. <LDraw Directory>\Unofficial\p
   
2. <LDraw Directory>\Unofficial\parts
   

Just as a note, to the best of my knowledge, LDView was the first program to support the Unofficial directory, and it did so as part of its feature that automatically downloads unofficial files from the LDraw Parts Tracker. Downloading unofficial parts into the main LDraw directories was clearly a bad idea, and I chose "Unofficial" as a directory to hold them. As far as I know, no other programs automatically download files into the Unofficial directory, but various other programs include it in their search path (presumably due to LDView's auto-download feature).

I still think #2 should be changed into something like "The directory containing the current file being processed."

I understand the ldraw.exe legacy but that program assumed simple self contained models (basically an mpd on disk).

The format as grown beyond that imho.

Enforcing the rule today will cause problems loading recursive multi folder models.

For example you open model "a.ldr" containing references to "subFolder\b.ldr"

Now when b.ldr contains a line referencing "c.ldr" the original #2 rule would dictate it looks for c.ldr inside the folder containing a.ldr.

It will not be found (unless there is another c.ldr there) so the loader goes on to 'p', 'parts' etc probably never finding it.

My suggestion would make it look inside the folder 'b.ldr' sits in which is, imho, much more modular and makes it a fully recursive system which is easier to write loaders for. (most current loaders probably already do it this way).

The original rule would mean you need to reference c.ldr like "subFolder\c.ldr" inside b.ldr which will break the model when loading just b.ldr

It would also create scooping/instances nightmare as parts/models can appear different depending from where they are referenced.


I have no objection to adding the unofficial folders though.