 |
Special:
|
[DAT] (requires LDraw-compatible viewer)
|
Subject:
|
More MPD
|
Newsgroups:
|
lugnet.cad.dev
|
Date:
|
Wed, 22 Mar 2000 01:56:55 GMT
|
Viewed:
|
1022 times
|
| |
|
|
1. Are the files in an MPD public or private?
Consider this example with three files:
town.dat
1 16 -40 0 0 1 0 0 0 1 0 0 0 1 house1.mpd
1 16 40 0 0 1 0 0 0 1 0 0 0 1 house2.mpd
house1.mpd
0 FILE house1.dat
1 4 0 0 0 1 0 0 0 1 0 0 0 1 3003.DAT
1 4 0 -24 0 1 0 0 0 1 0 0 0 1 roof.dat
0 FILE roof.dat
1 16 0 0 0 1 0 0 0 1 0 0 0 1 3043.DAT
house2.mpd
0 FILE house2.dat
1 2 0 0 0 1 0 0 0 1 0 0 0 1 3003.DAT
1 2 0 -8 0 1 0 0 0 1 0 0 0 1 roof.dat
0 FILE roof.dat
1 16 0 0 0 1 0 0 0 1 0 0 0 1 3068.DAT
For this to work as expected, "local files" in an MPD must be private,
and cannot be referenced by other "real files".
2. I suggest BuildMpd and M-Peedy should be able to handle MPD's too
as input files, and SplitMPD and M-Peedy should be able to split an MPD
correctly into the original files, both MPD and DAT.
You can use the town.dat above for test ;-)
3. Can I generally use the NOFILE meta command to skip the rest of the file,
i.e. also for ordinary DAT files?
Should it be renamed to EOF/ENDOFFILE?
/Lars
|
|
| |
In lugnet.cad.dev, Lars C. Hassing writes:
> 1. Are the files in an MPD public or private?
> Consider this example with three files:
>
> town.dat
> 1 16 -40 0 0 1 0 0 0 1 0 0 0 1 house1.mpd
> 1 16 40 0 0 1 0 0 0 1 0 0 0 1 house2.mpd
>
> house1.mpd
> 0 FILE house1.dat
> 1 4 0 0 0 1 0 0 0 1 0 0 0 1 3003.DAT
> 1 4 0 -24 0 1 0 0 0 1 0 0 0 1 roof.dat
> 0 FILE roof.dat
> 1 16 0 0 0 1 0 0 0 1 0 0 0 1 3043.DAT
>
> house2.mpd
> 0 FILE house2.dat
> 1 2 0 0 0 1 0 0 0 1 0 0 0 1 3003.DAT
> 1 2 0 -8 0 1 0 0 0 1 0 0 0 1 roof.dat
> 0 FILE roof.dat
> 1 16 0 0 0 1 0 0 0 1 0 0 0 1 3068.DAT
>
> For this to work as expected, "local files" in an MPD must be private,
> and cannot be referenced by other "real files".
>
> 2. I suggest BuildMpd and M-Peedy should be able to handle MPD's too
> as input files, and SplitMPD and M-Peedy should be able to split an MPD
> correctly into the original files, both MPD and DAT.
> You can use the town.dat above for test ;-)
>
> 3. Can I generally use the NOFILE meta command to skip the rest of the file,
> i.e. also for ordinary DAT files?
> Should it be renamed to EOF/ENDOFFILE?
> /Lars
This seems similar to the recursive MPD problem. At least with the lich.dat
example the files weren't really recursive. It was just a matter of
the ring2.dat file in the local MPD scope supplanting the ring2.dat from the
global parts/primitives scope.
Perhaps when parsing we should (internally to the program) tack the name of
the MPD file onto the name of the subfile to keep the scope local. This way
we could tell house1.mpd.roof.dat apart from house2.mpd.roof.dat. Also
lich.mpd.ring2.dat is now different from p/ring2.dat
Of course this falls into the you implement it and I merely port it category
so feel free to tear this idea apart. :^)
Don
|
|
| |
Lars:
> 1. Are the files in an MPD public or private?
Public. - Mostly due to the need to be able to create a set
of LDraw readable files.
> Consider this example with three files:
>
> town.dat
> 1 16 -40 0 0 1 0 0 0 1 0 0 0 1 house1.mpd
> 1 16 40 0 0 1 0 0 0 1 0 0 0 1 house2.mpd
>
> house1.mpd
> 0 FILE house1.dat
> 1 4 0 0 0 1 0 0 0 1 0 0 0 1 3003.DAT
> 1 4 0 -24 0 1 0 0 0 1 0 0 0 1 roof.dat
> 0 FILE roof.dat
> 1 16 0 0 0 1 0 0 0 1 0 0 0 1 3043.DAT
>
> house2.mpd
> 0 FILE house2.dat
> 1 2 0 0 0 1 0 0 0 1 0 0 0 1 3003.DAT
> 1 2 0 -8 0 1 0 0 0 1 0 0 0 1 roof.dat
> 0 FILE roof.dat
> 1 16 0 0 0 1 0 0 0 1 0 0 0 1 3068.DAT
>
> For this to work as expected, "local files" in an MPD must be private,
> and cannot be referenced by other "real files".
Since the construction of the MPD files is based on a
collection of DAT files, there can only be one "roof.dat"
file, ...
unless you keep the DAT files for the two houses in
different directories.
> 2. I suggest BuildMpd and M-Peedy should be able to handle MPD's too
> as input files, and SplitMPD and M-Peedy should be able to split an MPD
> correctly into the original files, both MPD and DAT.
> You can use the town.dat above for test ;-)
OK. The transformation I imagine would result in:
0 FILE town.dat
1 16 -40 0 0 1 0 0 0 1 0 0 0 1 house1/house1.dat
1 16 40 0 0 1 0 0 0 1 0 0 0 1 house2/house2.dat
0 FILE house1/house1.dat
1 4 0 0 0 1 0 0 0 1 0 0 0 1 3003.DAT
1 4 0 -24 0 1 0 0 0 1 0 0 0 1 house1/roof.dat
0 FILE house1/roof.dat
1 16 0 0 0 1 0 0 0 1 0 0 0 1 3043.DAT
0 FILE house2/house2.dat
1 2 0 0 0 1 0 0 0 1 0 0 0 1 3003.DAT
1 2 0 -8 0 1 0 0 0 1 0 0 0 1 house2/roof.dat
0 FILE house2/roof.dat
1 16 0 0 0 1 0 0 0 1 0 0 0 1 3068.DAT
0 NOFILE
As you can see will this mean that we will have to change
some file names in the files, but it should be close to
trivial using a list of the files included in the MPD files.
> 3. Can I generally use the NOFILE meta command to skip the rest of the file,
> i.e. also for ordinary DAT files?
No. There can, theoretically, come a FILE meta-command after
a NOFILE meta-command.
> Should it be renamed to EOF/ENDOFFILE?
Due to its slightly different effect, no.
Play well,
Jacob
------------------------------------------------------------
-- E-mail: sparre@cats.nbi.dk --
-- Web...: <URL: http://hugin.ldraw.org/LEGO/ > --
------------------------------------------------------------
|
|
| |
I think this goes back to the discussion (from last week, I think) about
the MPD format, and if it does everything needed, and if there should be
changes to it, or a new file format. To handle nested files, and
sub-mpd files, I'd go for a new format.
This hypothetical format would be targeted to containing single models
made of multiple nested components. The sub-components within a file
would be private to that file. A model could also be made of several
multi-component files working together.
In lugnet.cad.dev, Lars C. Hassing wrote:
> 1. Are the files in an MPD public or private?
I don't *know* for sure, but I'd be willing to wager a small amount of
money that they aren't.
If someone develops a new file-spec, add an option so an multi-component
file could be referenced as either public or private, to allow libraries
of files to be developed.
> 2. I suggest BuildMpd and M-Peedy should be able to handle MPD's too
> as input files, and SplitMPD and M-Peedy should be able to split an MPD
> correctly into the original files, both MPD and DAT.
Do you mean, the builders should be able to stuff an MPD into another
MPD? This would definitely require a spec-change, either an endofdat
delimiter, or a file.subfile notation on the 0 FILE command.
> 3. Can I generally use the NOFILE meta command to skip the rest of the file,
> i.e. also for ordinary DAT files?
No. Well, you could use it, but I'd expect programs would either ignore
it, or report a syntax error.
> Should it be renamed to EOF/ENDOFFILE?
I'd prefer 0 FILE END, to match LDLite syntax for nested commands.
Which would mean we couldn't empeedy a file named END., but I think
that's a minor inconvenience.
Steve
|
|
|
