LDraw.org Discussion Forums

Full Version: [LSC Request] End of header meta command
You're currently viewing a stripped down version of our content. View the full version with proper formatting.
Pages: 1 2 3 4 5 6 7 8 9
I think it would be really nice to have a meta command to indicate the end of the official part header information (especially) but also headers in general. Just something simple like:
Code:
0 !ENDOFHEADER

That way codes like LDMakeList of LDFind can know which comments are useful notes for the header (eg. in a needs work file) and which are just separators of the different part components (eg. 0 // Studs).

Of all the meta commands ever this one (hopefully) should be the easiest Smile

eg.

The ENDOFHEADER meta-command indicates that the header has ended, and that any software that processes the header can stop looking. It is not required.
Code:
0 Brick  1 x  4
0 Name: 3010.dat
0 Author: James Jessiman
0 !LDRAW_ORG Part UPDATE 2003-02
0 !LICENSE Redistributable under CCAL version 2.0 : see CAreadme.txt

0 BFC CERTIFY CW

0 !HISTORY 2001-10-26 [PTadmin] Official Update 2001-01
0 !HISTORY 2002-05-07 [unknown] BFC Certification
0 !HISTORY 2002-06-11 [PTadmin] Official Update 2002-03
0 !HISTORY 2002-12-12 [hafhead] New subparted version
0 !HISTORY 2003-08-01 [PTadmin] Official Update 2003-02
0 !HISTORY 2007-06-06 [PTadmin] Header formatted for Contributor Agreement
0 !HISTORY 2008-07-01 [PTadmin] Official Update 2008-01

0 // This file has been updated often
0 !ENDOFHEADER
0 // Include the sub file
1 16 0 0 0 1 0 0 0 1 0 0 0 1 s\3010s01.dat
0 // Add a quad on top
4 16 -40 0 -10 40 0 -10 40 24 -10 -40 24 -10
0
Yes, such a marker would help a lot to sort the comments in the file. But the only comments that are useful are at "Needs work" parts. As there has to be a comment telling us what is not correct with the part. All other official parts can stay like they are.

LDFind doesn't care about where in the file the data are stored. The whole file is scanned. As LDFind also should be usable with unofficial files i can not rely in any case on our official standards regarding the header Smile
The lack of such a meta command is a tremendous headache. It would make my life easier if it were mandatory and the whole part library had it.

Allen
That would be even better.

I've been calling the header done at the end of file, appearance of this meta (which never appears, but the code is there), or the first occurence of a non-type 0 line.

PS. You might have missed it, but could you send me any or all XML files you generate.
Tim Gould Wrote:I've been calling the header done at the end of file, appearance of this meta (which never appears, but the code is there), or the first occurence of a non-type 0 line.

So why to we need a new meta? The end of the header is already defined as per above (minus the new meta).
One problem is in comments before start of body, that are mistakenly integrated to header.
Because it's ambiguous. Not all type 0 lines are header info.
What Philo and Allen said. See eg.

Code:
0 Animal Rat
0 Name: 40234.dat
0 Author: Philippe Hurbain [Philo]
0 !LDRAW_ORG Part UPDATE 2009-02
0 !LICENSE Redistributable under CCAL version 2.0 : see CAreadme.txt

0 BFC CERTIFY CCW

0 !HISTORY 2009-09-03 [PTadmin] Official Update 2009-02

0 // Shape acquired with NXT-based 3D scanner
0 // Programmed with pbLua - Thanks, Ralph!
0 // Scans assembled and processed with Meshlab,
0 // a tool developed with the support of the Epoch NOE
[0 !ENDOFHEADER]
0 // Body
Exactly. Those informations are good but not header relevant IMHO.

Whereas:
Code:
0 Tile  2 x  2 with Map Red/Blue/Green Border Pattern (Needs Work)
0 Name: 3068bpa0.dat
0 Author: Stan Isachenko [angmarec]
0 !LDRAW_ORG Unofficial_Part
0 !LICENSE Redistributable under CCAL version 2.0 : see CAreadme.txt

0 BFC CERTIFY CCW
0 !KEYWORDS Adventurers

0 !HISTORY 2011-10-15 [MagFors] Corrected errors

0 // Needs work, many colinear vertices
this comment should go into the header data because it belongs to the "Needs Work" tag in the part description.
It sounds to me like we need a "0 !NEEDSWORK" meta-statement, then any "0 // ..." comment can be treated as not part of the header.

Some already consider the header to be bloated, so adding a mandatory "0 !ENDOFHEADER" would generate more bad vibes.
Pages: 1 2 3 4 5 6 7 8 9