+- LDraw.org Discussion Forums (https://forums.ldraw.org)
+-- Forum: General (https://forums.ldraw.org/forum-12.html)
+--- Forum: Help (https://forums.ldraw.org/forum-13.html)
+--- Thread: 0 NAME and 0 FILE: to sync or not to sync? (/thread-28265.html)
0 NAME and 0 FILE: to sync or not to sync? - N. W. Perry - 2024-05-20
Kind of a random and trivial inquiry, but one I keep going back and forth on…
In model files, do you prefer that an MPD filename (the 0 FILE meta) always match the—well, the file name, i.e. the 0 Name meta?
LDCad, for example, offers the option to sync these two metas by default, and it's also required by the OMR spec. But apart from that, are there reasons why these two entries should or should not always match?
Couple of points I can think of:
- The 0 FILE meta accepts a filename as a parameter. If this filename is always the same as the 0 NAME meta, why would it need to appear again as a parameter for 0 FILE?
- I've always understood 0 NAME to be the filename as it's saved in my system. At least, that's how it is for parts, including whether it's saved in the s/ or 48/ directories. But for the main subfile of an MPD, it's expected that the filename be "main.ldr", which is not how the parent file is saved. (I know they're different, but the parent file is really nothing but an empty wrapper, and it doesn't have its own header other than that of the main subfile.)
What do others do? Does it ever break anything, other than maybe OMR compliance, if these entries don't match?
RE: 0 NAME and 0 FILE: to sync or not to sync? - Orion Pobursky - 2024-05-20
While not explicitly stated, I think the intent is for Name: and FILE to match.
RE: 0 NAME and 0 FILE: to sync or not to sync? - Roland Melkert - 2024-05-20
(2024-05-20, 19:32)N. W. Perry Wrote: But apart from that, are there reasons why these two entries should or should not always match?
NAME does not have to match the filename, its purpose is to name the following (single) model. This is useful when the model is not stored in its own file like when put into a email (pre attachments era).
The FILE meta didn't exist back then, this was later introduced as an extension to allow for multiple ldraw files in a single file. This also makes it easier to extract valid ldraw content from mixed text files.
Keeping them in sync or using NAME at all (outside omr) is purely up to the user.
RE: 0 NAME and 0 FILE: to sync or not to sync? - N. W. Perry - 2024-05-20
(2024-05-20, 20:57)Roland Melkert Wrote: NAME does not have to match the filename, its purpose is to name the following (single) model. This is useful when the model is not stored in its own file like when put into a email (pre attachments era).
So, does NAME not have to be a name+extension format, i.e. "something.ldr" or "anything.dat"?
Now that I think of it, NAME isn't defined anywhere except the official library header spec. That document says it "is the file name of the part"—but of course that only applies to library parts, not models.
Quote:The FILE meta didn't exist back then, this was later introduced as an extension to allow for multiple ldraw files in a single file. This also makes it easier to extract valid ldraw content from mixed text files.
Right, like back in the r.t.l days when files were appended to newsgroup messages.
So then, if NAME isn't required, you can use FILE instead to give names to the (sub)files. And if you do use NAME in an mpd subfile, you can just leave the name off of the FILE statement. Something like that?
And therefore…
Quote:Keeping them in sync or using NAME at all (outside omr) is purely up to the user.
…the only reason this comes up at all is if the user decides to use both. And that, I guess, should never be necessary, as NAME is only required in official parts (in which case it is required to be the filename), and official parts have no reason to appear in an mpd!
Am I figuring it out, or am I still confused?
RE: 0 NAME and 0 FILE: to sync or not to sync? - Travis Cobbs - 2024-05-21
Maybe it's just me, but the only reference I can find to the 0 Name meta-command is in the Official Library Header Specification. And that specifies that it is the path name inside parts/p. Shouldn't all the standard header metas be documented somewhere that describes what they are in a generic sense, and not the restricted sense of a library file header?