LDraw.org Discussion Forums
Precise meaning of '~' and '_' - Printable Version

+- LDraw.org Discussion Forums (https://forums.ldraw.org)
+-- Forum: Models and Parts (https://forums.ldraw.org/forum-18.html)
+--- Forum: Parts Authoring (https://forums.ldraw.org/forum-19.html)
+--- Thread: Precise meaning of '~' and '_' (/thread-5607.html)



Precise meaning of '~' and '_' - Roland Melkert - 2012-07-23

I find the docs somewhat unclear, could someone shine some additional light on when and why the '~' and '_' prefixes are used?

For example I used to think the ~ is 'depreciated' and/or 'moved' but looking at 4179 this seems weird because it's a complete (and valid?) part as far i can see.

I'm struggling with this while tweaking the default part bin content of LDCad, currently I exclude all parts starting with ~ and _ but I'm starting to think I might be cutting away too much.

So in short how should these prefixes be handled in means of putting them in a part bin yes/no.


Re: Precise meaning of '~' and '_' - Philippe Hurbain - 2012-07-26

I'd prefer that someone more knowledgeable gives advice, but the case of 4179, this part is part of a glued assembly (4180cxx), and should normally not be used alone. But such parts could be used for example for custom, non-standard color assemblies, so I'd prefer to have some way to access them.


Re: Precise meaning of '~' and '_' - Chris Dee - 2012-07-26

Firstly, the original point of these prefixes was to provide a quick way of moving these files to the end of the parts.lst file.

With the formalisation of the header in 2008, some of this need has been superceded and tools should really query the LDRAW_ORG line to determine a file's category.

Files with a "_" description prefix are hard-coded colour versions of parts where we know the official LEGO part number for the part in that colour. These may be individually moulded parts (0 !LDRAW_ORG Part Physical_Colour ...) or assemblies of several moulded parts (0 !LDRAW_ORG Shortcut Physical_Colour ...).

Files may have a "~" description prefix, to move them out of the parts list for 4 reasons:
1) "Obsolete" files, errors or files that use patterning techniques that we no longer use. These also have the word "Obsolete" somewhere in the description.
2) "Moved to" file references, where we originally used an "unknown" (3-digit or uNNNN) part number and have since discovered the official number, or to maintain backward compatibility where a part has developed variants.
3) "Assembly component" files that represent an individually moulded part which is always issued by LEGO as part of an assembly and are therefore unlikely to be needed on its own, except by advanced users. Parts can be promoted out of this category if LEGO start to issue the part on its own, e.g. the 2x2 turntable plate base (3680).
4) "Flexible part component" files that ease the construction of flexed versions of the part

I would support a wholesale update to the LDRAW_ORG metadata lines for these files to separate and identify these categories and move away from the use of special characters to imply meaning.


Re: Precise meaning of '~' and '_' - Allen Smith - 2012-07-26

Chris Dee Wrote:With the formalisation of the header in 2008, some of this need has been superceded and tools should really query the LDRAW_ORG line to determine a file's category.

Files with a "_" description prefix are hard-coded colour versions of parts…

Does that mean that new physical color parts might not have a leading '_' ?

Allen


Re: Precise meaning of '~' and '_' - Chris Dee - 2012-07-26

For the foreseeable future, we will still use the "_" prefix for physical colour parts. Nevertheless, I'd prefer tools to identify the file category from the LDRAW_ORG line metadata, as that has the capacity to provided more semantic richness.


Re: Precise meaning of '~' and '_' - Roland Melkert - 2012-07-26

Thanks all,

I think I'm going to add special '~' and '_' subgroups in the bin, which will give access to them divided on a per category base just like the main 'by category' group (which currently excludes ~ and _ parts).