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