Search path discussion

[Roland Melkert]

Lars C. Hassing's LDrawIni code (which LDView and l3p for sure use, and possibly other programs) have always used it as the first entry in the default search path (ignoring MPD subfiles which have to be dealt with separately).

When you are working with a single folder this is really only a naming thing.

So maybe Lars wrote it with only that usage in mind.

Can we get Lars into this discussion?  I really doubt he purposely wanted to restrict the format this way?

Also standardizing the search order is the perfect opportunity to address this (ihmo) problem/bug so it won't be an issue of confusion again.

I made a small test model demonstrating the problem.

LDView an MLCad both can't find roof.ldr but I really think it should load ok using the (new) standard search path rules.

And again this change won't break the single folder approach everyone (else) is using, it only introduces recursion to the loading process.

And it also handles mpd references because the recursion will automatically support that.

So the spec would be:

<current file's MPD content>
<current file's folder content>
<library>/p
<library>/parts
<library>/models
<library>/Unofficial/p
<library>/Unofficial/parts

And a loader just needs to push/pop the 'current ...' items while walking the model tree.

And if your program only supports the existing 'working folder' you don't have to change a thing, all (new) single folder models will still load.

Sorry if I appear to be stubborn about this, but I truly believe it will hurt the format if we keep the top level folder approach.

Imho it will ruin the (potential) modular/recursive nature of the format. (especially for software working with multiple open models).