RE: Standardize official search path
2021-03-16, 1:51 (This post was last modified: 2021-03-16, 2:11 by Roland Melkert.)
2021-03-16, 1:51 (This post was last modified: 2021-03-16, 2:11 by Roland Melkert.)
Travis Cobbs Wrote: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 matterIf that is the intend of those folders I'm ok with it.
Travis Cobbs Wrote: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.I disagree on this, a stud.dat should not replace all studs in the whole scene if it's located in the mpd itself or its folder.
For example d:\test contains only these two files.
d:\test\awsomeModel.mpd
d:\test\stud.dat
The mpd contains:
Code:
0 FILE main.ldr
1 4 0 0 0 1 0 0 0 1 0 0 0 1 3001.dat
1 4 0 0 0 1 0 0 0 1 0 0 0 1 myPart.dat
0 FILE myPart.dat
1 16 0 0 0 1 0 0 0 1 0 0 0 1 stud.dat
In this case the references should translate like so:
For main.ldr
1 4 0 0 0 1 0 0 0 1 0 0 0 1 3001.dat --> <lib>\parts\3001.dat
1 4 0 0 0 1 0 0 0 1 0 0 0 1 myPart.dat --> <mpd>\myPart.dat
Then loading for 3001.dat starts within its own context, meaning it does nothing with the mpd content nor files inside that mpd's folder.
So any stud.dat will be loaded as <lib>\p\stud.dat unless 3001.dat has an embeded stud.dat (should never happen but could have been edited.) or another stud.dat is also present in the <lib>\parts folder.
Then for myPart.dat it will translate like
1 16 0 0 0 1 0 0 0 1 0 0 0 1 stud.dat --> d:\test\stud.dat (because its in the current context's parent folder 'd:\test'.)
Hope this make it more clear on how I always assumed search resolving should go.
The real question here is do we WANT a local stud.dat to affect the global scope or should it only affect its local context (like I assumed).
imho the local context approach is much more logical, global stuff should be handled by prefixing extra search locations to the global order.
edit: I assumed 3001.dat has no further dependencies. Otherwise it would recursively keep applying the context approach)