20006 - Clone Turbo Tank

[Allen Smith]

fileX.ldr (with mpd content)
contains file1.ldr and file2.ldr where file2.ldr is called from file1.ldr by a linetype 1.

fileY.ldr (with mpd content)
contains file1.ldr and file3.ldr where file3.ldr is called from file1.ldr by a linetype 1.

Now I create a new file with the following content:
1 16 0 0 0 1 0 0 0 1 0 0 0 1 fileX.ldr
1 16 0 0 0 1 0 0 0 1 0 0 0 1 fileY.ldr

If shown in LDView then I only see file1.ldr from fileX.ldr because:
1) It is the first file in fileX.dat and therefore should be shown
2) fileY.ldr contains also a file1.ldr, but it do not overwrite the already loaded file1.ldr.

I say that's a bug. The namespace for each MPD file should be private.

A linetype 1 reference to a neighboring MPD file should always cause the first model of that MPD to be displayed, irrespective of the submodel's name. Any other submodels than the first should not be directly accessible to the calling file (although any references to them from the called submodel should display just fine).

All that said, neighboring-file support presents a great number of complications. If you don't plan for it from the beginning, it can also break a lot of assumptions that are easy to make when coding up an LDraw program. Bricksmith prior to 2.6 had a whole pile of bugs with neighbor file support exactly because it was not only quite a bit harder to implement, but also hard to retrofit into my existing code. (Many thanks to Ben Supnik for contributing fixes for those bugs!)

Furthermore, none of my opinions are really anything more than opinions, logical though I believe them to be. The spec has this singularly unhelpful bit in it:

So far, there are no clear scoping or namespace rules on MPD files. If you put a file named stud.dat in your MPD file, don't be surprised to see your stud.dat file appear on the top of every single brick in your scene.

Allen