LDraw.org Discussion Forums
subfiles in MPD files - Printable Version

+- LDraw.org Discussion Forums (https://forums.ldraw.org)
+-- Forum: LDraw Programs (https://forums.ldraw.org/forum-7.html)
+--- Forum: LDraw Editors and Viewers (https://forums.ldraw.org/forum-11.html)
+--- Thread: subfiles in MPD files (/thread-6659.html)

Pages: 1 2 3 4 5


subfiles in MPD files - Michael Heidemann - 2012-11-10

I am still unhappy with subfiles in MPD files and what to do.

Example:
I have a file "testpart.dat" like this:
0 Testfile
0 Name: testpart.dat
1 16 0 0 0 1 0 0 0 1 0 0 0 1 3001.dat
1 16 0 32 0 1 0 0 0 1 0 0 0 1 s\testparts.dat

"testparts.dat" like this:
0 Testfile subfile blue
0 Name: s\testparts.dat
1 1 0 0 0 1 0 0 0 1 0 0 0 1 3001.dat

If I put the testparts.dat in a subfolder relative to the folder where testpart.dat resists I see with MLCad and LDView both parts.

Now I open testpart.dat in MLCad.
After that I import testparts.dat.
I save that content in the new file testpart.mpd

I would expect that I can now give this testpart.mpd to another user and that he can see what I have build, but that is not the case.
If I open the file from another location on my system MLCad claims "File s\testparts.dat not found! Continue loading?"
After I answered yes only the main color brick has been displayed.
One more bad thing with MLCad - if you export the files ("Multipart" - "Export Models...") the reference "s\testparts.dat" is changed to "Unknown".

With this behaviour it is impossible with the current tools to show the complete model direct out of the MPD file nor to export all files in a good shape.

For this reason I have in MPDCenter implemented a full export of the files in the correct foldertree and then all is shown correctly.

BUT MPDCenter is not designed as a viewer tool (build in viewer is ldvlib.dll).

To have also good experience with LDView I suggest to also implement something that avoid these mistakes.

Or, if we want to do it completely different, we need to forbit subparts to be in the MPDfiles. This can be archieved by changing all references to those subparts and delete the leading "s\".
But then one problem still remains - '48\' primitives. We can not just cut the 48 away, because then we have a different part (16').

Any other thoughts on this?


Re: subfiles in MPD files - Alex Taylor - 2012-11-10

It's an error in your .mpd file - the second file should start with "0 FILE s\testparts.dat" not "0 FILE testparts.dat". Change that line and LDView and MLCad open it correctly.

Don't forget that parsers will look at the filename, not the 'Name:' meta-command, when trying to resolve a sub-file reference.

This is basically a bug in MLCad, although to be fair it wasn't designed with this in mind.


Re: subfiles in MPD files - Michael Heidemann - 2012-11-10

Ok, then I have to adjust MPDCenter again Sad

What you discribed was also my intend, but as MLCad did not work this way I decided to emulate the behaviour of MLCad for the import of files as MPD files has been introduced by MLCad!

One more bad thing with MLCad in this context:
If I use "Multipart" - "Change Model Info..." and add the missing "s\" in front of the filename the Name: entry that has been correct until my change will be changed to not carry the leading "s\" anymore.
You have to change the Name: entry line manually after you changed the file info.

STRANGE!!


Re: subfiles in MPD files - Michael Heidemann - 2012-11-10

As a result of all these findings we should NOT use MLCad if any kind of "s\" or "48\" files needs to be nested in a MPD file.
Because once you get a file not found error this reference is changed to "Unkown" if you safe the file.


Re: subfiles in MPD files - Alex Taylor - 2012-11-10

I think what it comes down to is that MLCad's primary function is a model-editor. Sub-models (note: not sub-parts) do not have prefixes on their names, so MLCad simply doesn't support them. It has no way of knowing that the file you imported was a subpart and thus should have the 's\' prefix.

Given the above it's not too surprising that trying to use it like this has unexpected results :-)

My own parser takes this into account: it reads the 'FILE', 'Name:' and '!LDRAW_ORG' lines and when they disagree it attempts to work out the most probable solution. In the case of your file, although the 'FILE' line just gives the filename as 'testparts.dat', because the 'Name:' line reads 's\testparts.dat' the parser concludes that it is in fact a subpart and fixes the 'FILE' line accordingly. Hence if I load the file into my parser it renders both bricks first time :-)


Re: subfiles in MPD files - Alex Taylor - 2012-11-10

Michael Heidemann Wrote:As a result of all these findings we should NOT use MLCad if any kind of "s\" or "48\" files needs to be nested in a MPD file.
Because once you get a file not found error this reference is changed to "Unkown" if you safe the file.

That I think is an old bug which has been fixed in v3.4.


Re: subfiles in MPD files - Michael Heidemann - 2012-11-10

That is exactly what I thought our current application would do also.

In the specs for the MPD file it is stated that after FILE the real filename should be written and not with a leading "s\".
The implementation that you made is perfect, because it make sence to have the Name: entry line.
For MLCad and LDView it seems to me that this line could be cancelled.

I prefer very much your implementation.

Will the spec for MPD files be updated to reflect this - tiny - difficulties?


Re: subfiles in MPD files - Alex Taylor - 2012-11-10

Michael Heidemann Wrote:In the specs for the MPD file it is stated that after FILE the real filename should be written and not with a leading "s\".

Actually, it doesn't. It says:

Format: 0 FILE <model>

Where:
<model> is the name of the following LDraw file.


The name of the file is the value that would be used with a type-1 line: the value of the 'Name:' meta-command, not the literal filename it would have if written to disk. 'FILE' and 'Name:' are thus required to have the same value (something which the OMR spec appears to be trying to break, incidentally).


Re: subfiles in MPD files - Michael Heidemann - 2012-11-10

Stupid me - did not yet realized that version! - Thanks.


Re: subfiles in MPD files - Michael Heidemann - 2012-11-10

"(something which the OMR spec appears to be trying to break, incidentally)"

Can you please explain that to me and where this should happen?