20006 - Clone Turbo Tank

[Ken Drew]

First OMR for me. I think I got everything OMR compliant.

20006 - Clone Turbo Tank

[Michael Heidemann]

I would say yes, according to the written specifications.
I would say no, according to the unwritten !

You have put the content of an MPD file in a file with the extension '.ldr'. That is not what I understand as an MPD file.

In my opinion we have the following extension with the following meanings:
.dat - part files that references to sub part files (.dat) or primitive part files (.dat), but never to .ldr files.
.dat - sub part files that references to other sub part files (.dat) or primitive part files (.dat) but never to .ldr files.
.dat - primitive part file that references to other sub part files (.dat) or primitive part files (.dat) but never to .ldr files.
.ldr - model files that references to part files or other model files, but never to primitive part files or sub part files.
.mpd - simple container for several .dat and/or .ldr files and can not be set as reference in linetype 1.

So in my humble opinion you need to rename your file to 20006 - Clone Turbo Tank.mpd to be OMR conform.

To LSC: I could not find any of the above in the specifications! Please add that to the corresponding specifications.

[Travis Cobbs]

My personal opinion is that any LDraw-compatible user-generated file (MPD or not) can perfectly validly have an LDR extension. In my opinion, MPD is just one of many extensions to the LDraw language. Additionally, it is such a widely used one that it should be supported by anything that loads LDraw files; not doing so is just asking for trouble. It's my opinion that splitting LDraw files into MPD and not-MPD is antagonistic towards users due to being confusing for no particular reason. When the MPD extension to LDraw was first introduced, and most programs didn't support it, it made sense to have a separate file extension. I don't think that's the case now, at the end of 2012.

[Ken Drew]

While I agree with Travis, I don't consider myself a normal user. So for the purposes of the repository and the categorization of the repository, I've updated the file to use the .mpd extension.

I have about 47 other models for the OMR so the will be coming soon...

[Michael Heidemann]

I agree to your suggestion from your point of view (LDView). But if you need to do anything else than show a picture you have to know wheather it is an MPD file (container for several LDR or DAT files) or not. I also agree that it is easy to determine that a file has mpd content, but for windows (and unix I think) the extension is a basic instrument for determining its content. So why should we not use this systematics also for our files?
By the way, MLCad, the inventor of MPD-files suggests to save that file with the '.mpd' extension!

[Roland Melkert]

I always looked at mpd as a naming convention, but none of my tools will assume anything based on the extension. They just parse string lists

[Travis Cobbs]

I'm not trying to present the point of view of me as the author of LDView. I'm trying to present the point of view of users (and in particular, non-expert users). From the point of view of a majority of users, "MPD" is just some esoteric jargon that only programmers understand. All the programs they use to open LDraw files can open both "MPD" and "LDR" files.

And MLCad suggesting MPD as the extension is consistent with what I said: originally it was good to use the MPD extension due to lack of support in other programs.

[Michael Heidemann]

Ok, I understand your point of view and I come to the conclusion that I will follow your approach.

It would be great if there is a statement in the specifications that makes this clear to all application developer in the future. Somethink like "A valid MPD file is not determined by the extension of the file but on its content."

[Michael Heidemann]

I have dig a little bit:

LDraw.org Standards: File Format 1.0.2
Extension
All LDraw files carry the LDR (default), DAT or MPD extension.

As I could not find any further information on the different file types I assume that I can reference to a MPD file in any other file?

I have checked this and LDView do this! That's great, but pushed me back for years in coding my apps as MPDCenter definitely do not support this at present

[Travis Cobbs]

Topic started:

http://forums.ldraw.org/showthread.php?t...42#pid7242

[Travis Cobbs]

I think it's only fair to point out that LDView probably doesn't do it "right". I'm pretty sure that the contents of any MPD LDView loads automatically become global, which isn't technically the right thing to do. (In other words, if you have a model that references two separate MPDs, and those MPDs each contain a sub-model with the same name, only one of the sub-models will be loaded, and its contents will clobber the contents of the other.)

[Michael Heidemann]

Hmmm.
If I understand that correctly we have the following situation:

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 have added the files I used for testing.

So it seems, that the scope of a referenced mpd content will not end at all. After I realize that, I tried also to reference from combined.ldr to file2.ldr (that is not the first file of any mpd). And yes, it will be shown.

That is really not a good behaviour and until now nowhere mentioned. But....

I remember a discussion in our old forum about addressing files from mpd that are not the first one.
With the current behaviour of LDView it should be possible to address these files.
Please see files fileZ.ldr and combined_nothing.ldr
You can address all files from and mpd file!

One more thing!
You do not need to manipulate the mpd content file with an empty first model file. Just set the matrix to all zero works also great: 1 16 0 0 0 0 0 0 0 0 0 0 0 0 fileY.ldr

[Travis Cobbs]

What I was really trying to say is that while you might get something in LDView when you load an MPD as a sub-file, it's more by accident than anything else, and therefore what you get isn't necessarily what you expect. In other words, LDView doesn't officially support nested MPD files, so however it behaves should definitely not be taken as an indication that that's how I think nested MPD files should work.

[Michael Heidemann]

Thank for renaming and pointing especially me to the extension "problem".

With the content of your file I have the following concerns:
1) each file in the mpd needs to have a proper 0 !LICENSE line. Currently they have not.
2) not all part files you refer to are in the mpd file, so not every user can see what you have build.
3) You used files that have been renamed and now so called '~Moved to' files. They should be avoided.
4) The file naming is not according the current spec.
Example from your file:

Code:

0 20006 - Clone Turbo Tank
0 Name: 20006 - Clone Turbo Tank.mpd
0 Author: Ken Drew [Ken]

But it should be:

Code:

0 Clone Turbo Tank
0 Name: 20006 - Clone Turbo Tank.mpd
0 Author: Ken Drew [Ken]

I have done the following after loading your file to MPDCenter:
1) deleted the leading '20006 - ' from the description line at each file in editor windows
2) applied the header data from the first file to all other files by context menu command
3) imported unofficial files
4) applied correct name entry for two imported subfiles (not correctly importet - bug in MPDCenter)
5) Seached for '~Moved to' files and replaced them

I have attached the file that is the result of that.

[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

[Allen Smith]

One more thing!
You do not need to manipulate the mpd content file with an empty first model file. Just set the matrix to all zero works also great: 1 16 0 0 0 0 0 0 0 0 0 0 0 0 fileY.ldr

I don't follow this. The transform should be applied to the first submodel of the referenced MPD. A transform of all 0 should effectively obliterate the model.

Allen

[Roland Melkert]

I'm not sure how bricksmith handles this internally, but in LDCad I use a stack for the searchpaths this automatically ensures scoping while loading> This way MPD submodels are simply handled like another (virtual) folder in that stack.

While loaded the the virtual location information stays in effect so no other model would ever directly link to a non main model of a mpd, this is the reason I display the '?' in file names when using mpd (E.g. "d:\data\town.mpd?school.ldr")

[Travis Cobbs]

I personally feel that this is likely the pedantically correct way to handle MPDs. As I said before, LDView's current behavior is largely an accident, as it wasn't really designed to load MPDs as sub-models. I don't have any immediate plans to fix LDView, though.

[Michael Heidemann]

I just made some more tests with mpd content files used as a reference.

Both files should be in the same directory.

Open mehr.ldr with your favorite application. You should see two group of people with different helm color.
This example should also work if the files have different extensions (of course the reference needs to be changed as well).

The current version of LDView does a good job
The current version of MLCad does not show the correct content

[Michael Heidemann]

I am on the way to change MPDCenter to accept all mentioned file extensions and decide upon the content what to do.

By thinking about all the possibilities, it came to my mind that it can lead to some confusion if all files uses for example the ldr extension.
You can have a file model.ldr sitting on your disc. Only with the name you can not know is it a "packed" mpd file or a simple model file. As long as you are only viewing the model - no problem - all viewer cares about that.

What if you are building new models? I do not wonder if somebody will override his model with the wrong content.

The idea of having extension independing file processing is ok. But I feel to have the files named differently would be a benefit for the user. So MPDCenter will export mpd content files with ".mpd" extension.