Searching for the perfect place to MPD format discussions, I think here is the least inappropriate.
/Tore
/Tore
MPD Issues
As a complete MLCad newbie, I started to play around with it last night. Much to my surprise, I noticed that MLCad does not recognize a "file" object inside an MPD if it has no extension known to LDraw.
So torso.dat and hips.ldr work fine
But "rleg.txt", "lleg.foo" and "rarm" were "not found" by MLCad (v3.30), even thought the Type 1 references and the "0 FILE..." names are exact matches.
As MLCad plays such a central role in the LDraw software family, I suppose it is "illegal" not to have either .dat or .ldr extension for objects inside an MPD, even though it presents no problems for LDView, L3P, or L3Lab?
/Tore
So torso.dat and hips.ldr work fine
But "rleg.txt", "lleg.foo" and "rarm" were "not found" by MLCad (v3.30), even thought the Type 1 references and the "0 FILE..." names are exact matches.
As MLCad plays such a central role in the LDraw software family, I suppose it is "illegal" not to have either .dat or .ldr extension for objects inside an MPD, even though it presents no problems for LDView, L3P, or L3Lab?
/Tore
Well, I would certainly not call it illegal, but given what you have witnessed, it seems like it would be a good idea to use standard extensions for the contained files. The MPD spec makes absolutely no mention of filename extensions.
I'm at a loss as to why MLCad behaves that way. Having written LDView, I think I'd have to add extra code in order to get it to not recognize contained files that weren't .ldr/.dat.
I'm at a loss as to why MLCad behaves that way. Having written LDView, I think I'd have to add extra code in order to get it to not recognize contained files that weren't .ldr/.dat.
Travis Cobbs Wrote:Well, I would certainly not call it illegal, but given what you have witnessed, it seems like it would be a good idea to use standard extensions for the contained files. The MPD spec makes absolutely no mention of filename extensions.
I'm at a loss as to why MLCad behaves that way. Having written LDView, I think I'd have to add extra code in order to get it to not recognize contained files that weren't .ldr/.dat.
I also would not call it illegal, and have no idea why MLCad cares how submodels are named. I had to add extra code in Bricksmith to force all submodel names to end in .ldr just to make MLCad happy, and then more extra code to hide those ugly internal extensions from the user.
Allen
Allen Smith Wrote:
-------------------------------------------------------
>
> I also would not call it illegal, and have no idea
> why MLCad cares how submodels are named. I had to
> add extra code in Bricksmith to force all submodel
> names to end in .ldr just to make MLCad happy, and
> then more extra code to hide those ugly internal
> extensions from the user.
>
> Allen
I can only throw out a wild guess on a possible historical background to this.
Original LDraw (and L3Lab) accepted
1 14 0 0 0 1 0 0 0 1 0 0 0 1 3001.dat
but also just
1 14 0 0 0 1 0 0 0 1 0 0 0 1 3001
as reference to a yellow 3001 Brick 2 x 4.
Then came the .LDR extension that brought both much more clarity and some new confusion. Can "3001" only refer to both 3001.dat and 3001.ldr? (And, later, even 3001.mpd?) If so, which scan order shall we agree on? I didn't follow that discussion in detail, but can imagine that the only reasonable thibg to do is to straighten up the syntax and allow only exact file name references.
With MPD, a whole new syntax was created that wasn't supported by original LDraw. I we talked about the LDraw 2.0 standard, with extended syntax not at all backwards compatible. In that situation, we didn't know what to expect from the future development of the LDraw standard. Maybe a new future file format with a new extention that would jam today's L-Cad software? What we knew was that .DAT, .LDR and .MPD was more or less static and our software would probably be able to support those three file formats.
Could it be possible that some software authors responded to that new situation with strictly allowing those three extensions only, and ignoring all other files? And then, later revised that policy to allow all kinds of file extensions along with no extension at all, but maybe forgot to make the changes when inside an MPD?
Or maybe there is some other reason that we simply have overseen? Maybe an early, never officialized draft of MPD format specification required file extension?
As MLCad accepts all kinds of file extensions outside MPD's, shall we consider this a bug and add it to the known bugs list?
/Tore
-------------------------------------------------------
>
> I also would not call it illegal, and have no idea
> why MLCad cares how submodels are named. I had to
> add extra code in Bricksmith to force all submodel
> names to end in .ldr just to make MLCad happy, and
> then more extra code to hide those ugly internal
> extensions from the user.
>
> Allen
I can only throw out a wild guess on a possible historical background to this.
Original LDraw (and L3Lab) accepted
1 14 0 0 0 1 0 0 0 1 0 0 0 1 3001.dat
but also just
1 14 0 0 0 1 0 0 0 1 0 0 0 1 3001
as reference to a yellow 3001 Brick 2 x 4.
Then came the .LDR extension that brought both much more clarity and some new confusion. Can "3001" only refer to both 3001.dat and 3001.ldr? (And, later, even 3001.mpd?) If so, which scan order shall we agree on? I didn't follow that discussion in detail, but can imagine that the only reasonable thibg to do is to straighten up the syntax and allow only exact file name references.
With MPD, a whole new syntax was created that wasn't supported by original LDraw. I we talked about the LDraw 2.0 standard, with extended syntax not at all backwards compatible. In that situation, we didn't know what to expect from the future development of the LDraw standard. Maybe a new future file format with a new extention that would jam today's L-Cad software? What we knew was that .DAT, .LDR and .MPD was more or less static and our software would probably be able to support those three file formats.
Could it be possible that some software authors responded to that new situation with strictly allowing those three extensions only, and ignoring all other files? And then, later revised that policy to allow all kinds of file extensions along with no extension at all, but maybe forgot to make the changes when inside an MPD?
Or maybe there is some other reason that we simply have overseen? Maybe an early, never officialized draft of MPD format specification required file extension?
As MLCad accepts all kinds of file extensions outside MPD's, shall we consider this a bug and add it to the known bugs list?
/Tore
« Next Oldest | Next Newest »
Users browsing this thread: 4 Guest(s)