LDraw.org Discussion Forums

Full Version: Should "Part Alias" files be listed in parts.lst
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
My guess is that MLCad looks into the file name and compares it to the entries in the Parts.lst

w.
These files frustrate me to no end when building, and I want to make them as difficult to access in my part browser as possible.

Please add a prefix. I prefer '_' because it is already well-established for identifying parts one should never actually use in a model. It is also already supported in software, meaning less work for software authors if you don't define a new prefix. For example, underscore-prefixed parts already get forced into Bricksmith's Alias category, where people are very unlikely to accidentally find them.

If you are going to use a different prefix, please let me know what it is so I can adapt accordingly.

Allen
Allen Smith Wrote:For example, underscore-prefixed parts already get forced into Bricksmith's Alias category, where people are very unlikely to accidentally find them.
Allen

Existing underscore-prefixed parts are NOT aliases, they are parts with hardcoded colours, so I think we already have a semantic issue. I would really prefer to have another prefix for (colour 16) aliases.

If you need a rule - any non-alpha first character should push the files into one or more "hard to find" locations: "~" for elements that are always delivered as part of a composite; "_" for physical colour parts; "something else" for aliases.
Chris Dee Wrote:Existing underscore-prefixed parts are NOT aliases, they are parts with hardcoded colours, so I think we already have a semantic issue.

That's a subtle-enough distinction that I'm not going to make it. One of the definitions of alias is "a false or assumed identity," and I think that describes physical-colored parts with sufficient accuracy for both my users and myself.

If more categories of non-parts arise in the future I can always change "Alias" to "Other" (or preferrably a more forbidding term).

Chris Dee Wrote:I would really prefer to have another prefix for (colour 16) aliases.

In that case, I just need to know what that prefix is going to be. I would like to modify my code now, or I'm apt to forget.

Allen
Allen Smith Wrote:In that case, I just need to know what that prefix is going to be. I would like to modify my code now, or I'm apt to forget.

How about ⓐ? (Just kidding.)

More seriously, if we want a new character, it seems that = is at least logical, since the alias is equivalent to some other part.
I know it should be, but most browsers have some fallback code when it is not,
and I fear that this fallback code will break things here.
I like "=", so 30097.dat would change from
Code:
0 Panel 10 x  6 x 11
to
Code:
0 =Panel 10 x  6 x 11

Are there any objections or does anyone see potential problems with this ?
Personally I think such things should be made out in the header (!LDRAW_ORG) not the caption/description. Cause it messes with sorting etc. I would love seeing a special file type meta (that isn't necessary ldraw org related) for this to emerge stating the file's purpuse (model, part, alias, coloured, etc), but I already tried launching such a meta in lsc with little success though.
That's exactly what the !LDRAW_ORG line is supposed to do. The current mklist doesn't read that metadata, so maybe the new version could use that rather than rely on special coding in the title.

One area that isn't quite covered by !LDRAW_ORG metadata is "parts only released as assemblies". There are still called Part, but have a leading "~" in the title to hide them from parts selection lists.
The current version of mklist2 can strip the character if asked. So even with such an approach you don't need to worry, just add -I= when you run it and your list will look fine.

I'll add the ability to read the !LDRAW_ORG line when I get the chance so either option will work.

Tim
Pages: 1 2 3 4 5 6