Should "Part Alias" files be listed in parts.lst

[Chris Dee]

Currently "Part Alias" files do not have any leading "_" in their descriptions, so are listed as duplicates in parts.lst. This class of files includes duplicate LEGO numbers for part re-issue (e.g. 44237 for 2456) or transparent part moulds (30065 for 3960). We are also starting to get LEGO numbers for patterned parts, which I have treating simlarly, continuing to use NNNNpXX numbers to "tie" the patterned parts to the un-decorated versionand creating an alias for the true number.

I thinking that from a user's perspective these "Part Alias" files are not that different to "Physical Colour" files which are hidden by the use of a leading "_". They are both in the library so that if someone wants to insert a part by number, then the file is found, but do we really need the same description twice in the parts list, and the image twice in the visual parts catalogue?

There are currently 64 official "Part Alias" files and the descriptions could be changed in the background without re-cycling through the Parts Tracker.

What do people think?

[Tim Gould]

I'd prefer to see them hidden. In particular it reduces the chance that instructions will have multiple copies of the same part thanks to the model maker choosing different numbers.

Tim

[Jude Parrill]

This is actually something that's been on my mind recently: The case of part aliases and physically colored parts. It's my understanding that these parts exist primarily to ease conversion from LDD to LDraw. However, this comes at the cost of having additional files which, as you say, tend to clutter up the parts list and cause confusion for those who don't understand why two versions of the same part exist.

I have thought of a couple possible solutions for this, although I don't know how well they'll be recieved.

---

1. Right now, there currently exists one main "library" with all the certified parts in it, called the "Core". One could seperate out the alias and physical color parts into a seperate library called "Conversion" which could be downloaded seperately. Both library's could be included in the AIOI, if desirable.

Pros:
- Only those who want the parts will get them.
- Parts will no longer exist in Parts.lst for those who don't have the files.

Cons:
- May cause confusion for those who don't know the second library exists.
- Potentially causes segmentation in the PT.

---

2. A more radical approach would be to eliminate these files and include the information in the original part files as META data. There would likely be a need for new keywords to such as "0 ALIAS [Alias_Number]" and "0 PHYSICAL_COLOR [PColor_Number]"

Pros:
- Would eliminate the files altogether which would save space.
- The Data exists for those who need it and those who don't won't know of it.

Cons:
- Would break current conversion software. A solution to this would be to introduce the new files (with the meta data) while keeping the old ones for a period until the software authors have had sufficient time to update their software (say 1-3 years).
- Several files would need to be updated, which would cause additional work. Additionally, as time goes by and more aliases/physical color parts are released, the files would need to be constantly updated.

---

Of course, there's always the option to simply "underscore" them as Chris suggested, although in my opinion this only serves to clutter the "Other Parts" section in MLCad even further.

Personally, I'm more a fan of my 1st suggestion than the 2nd, but I thought I'd put them both out here as food for thought.

[Chris Dee]

Option 1 is exactly how it implemented for those who install the library using the Windows installer (e.g. LDraw1102.exe). In fact there are three optional libraries; Alias parts, Physical colour parts and Non-redistributable parts. I don't know what the AIOI does, but from what you're are saying it sounds like it installs everything.

But this does not solve the question I posed, because Alias Parts currently have identical descriptions to their target, so users that install them still see the part twice.

Rather than dumping them in "Other Parts" I think editors like MLCad should put "underscore prefixed files" somewhere "special" - only selectable by parts number.

I don't like option 2 because it requires an update to the source of the base part when a new alias or physical colour version appears in the wild.

[Willy Tschager]

Hide 'em. IMHO users get confused as they usually pick from the preview panes and don't care about the part number. Sometimes you get models with different numbers for the same part and it looks weird on the model's part list.

As for the AIOI I guess I'm going the way the installer does and let the user decide if they wanna have them on the disk.

w.

[Philippe Hurbain]

I don't like the idea of hiding anything. Using the _ prefix, the aliases or physical colors can be sorted in another bin in a correctly configured editor. IMHO it's enough...

[Chris Dee]

Yes, that's what I was asking. I don't want to hide anything either, just allow them to be put in the "bottom drawer". Currently only Physical Colour files have the "_" prefix. It sounds like everyone supports extending this to Alias files.

Or would it help to have a different prefix for Alias files?? "+", "|", "?", "<", ">" would probably all work.

[Tim Gould]

A different symbol would probably be better. '>' makes most sense to me since it's an 'arrow'. Is it acceptable on all systems though?

[Philippe Hurbain]

I would tend to prefer a different prefix for aliases.

Maybe we should have more discussions about this with LDraw editors too... Eg. I was not able to access any ~ or _ prefixed part in SR3D, and it's rather clumsy with LDCad (on the latter I may be wrong, since I'm not used to it...)

[Steffen]

what about the "number sign" '#' ?

[Chris Dee]

I try to avoid them due to their special meaning in URLs.

[Steffen]

I cannot imagine of a usecase where a part title (that's what we're talking about here)
is being used as a URL. A part _number_ would be something different,
but we're talking here about the first title line of part files.

[Chris Dee]

True, but can we really guess what web-interface we might want in the future? If we have a choice of characters and no special reason for using "#", I'd still rather avoid it. Personally, I like ">", too.

[Steffen]

Yes, but using > will also not work in URLs I think, because much existing software will not treat
it as part of the URL - example:

<a href=http://www.ldraw.org/cgi-bin/coolquery.pl?someparttitle>my link</a>

[Chris Dee]

Doh!! You are right.
Actually since the href attribute should be quoted (reference here), surely this will be OK:
<a href="http://www.ldraw.org/cgi-bin/coolquery.cgi?someparttitle=>my link"></a>.

[Magnus Forsberg]

I think we should keep the different kind of aliases of a part, away from each other.

I want to see which partnumber to use for transparent parts.
"54200 is used for moulding opaque parts, 50746 for transparent parts." from the alias file 50746.dat
When searching for this part I today find:
"54200.dat / Slope Brick 31 1 x 1 x 2/3"
"50746.dat / Slope Brick 31 1 x 1 x 2/3"
Nothing tells me which part is the transparent one, and I don't want them hidden among the "Physical Colour" files.

I use MLCad and have moved all "Physical Colour"-parts to a "bin" by searching for "parts beginning with _" in my mlcad.grp-file.
Don't mix transparent parts with physical colour parts.

How many aliases can a part have?
Take this one, for example: 3626bp82.dat
Also known as 50003.dat (Design ID), and should also have a seven digit alias, ???????.dat ( Element ID)

[Chris Dee]

I now agree that we should not mix aliases with physical colour parts any more than we should mix them with "core" parts, that's why I'd like to reach a conclusion on the title prefix to be used for Aliases.

Parts may have mutliple aliases, due to a combination of the opaque/transparent mould phenomenon, LEGO part numbering evolution and our desire to group patterned parts with their pain version using pNN suffices. In the case of 3626bp82 (which is what prompted this discussion), 50003.dat would be an alias. The 7-digit element ID (if/when we know it) would be a Physical Colour file. There are many examples of more than one 7-digit number for the same colour, possible indicating the LEGO has just as much trouble understanding their colour palette then as we do.

[Steffen]

I agree, and your contribution makes me also want to have a title prefix for aliases,
so I'm able to quickly/easily sort them out e.g. in MLCad's part tree

[Willy Tschager]

I'm currently adding Orion's Architecture models the AIOI and the aliases for Tile 1x1, Panel 1x2, ... he used are a real pain in the ass. I didn't install any alias and physical part to see what would happen to the models just with the core installed and the warnings in MLCad are literally driving me crazy - beside the replace job once I've got the list of aliases use. Please "hide" them as soon as possible so people don't get tempt to mix them in a model.

w.

[Chris Dee]

Aliases are created the way they are to "transparently" (sic) refer to the main part. If a tool author decides to "warn" the user about a singular reference, I believe the usability issue lies with the tool, not the library. Why does MLCad even care? How does it know - from the LDRAW_ORG line, or because the file contains just one type 1 line?

[Willy Tschager]

My guess is that MLCad looks into the file name and compares it to the entries in the Parts.lst

w.

[Allen Smith]

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

[Chris Dee]

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.

[Allen Smith]

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).

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

[Travis Cobbs]

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.

[Steffen]

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.

[Chris Dee]

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 ?

[Roland Melkert]

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.

[Chris Dee]

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.

[Tim Gould]

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

[Roland Melkert]

That's exactly what the !LDRAW_ORG line is supposed to do. The current mklist doesn't read that metadata

Yes but that one describes the official status, and also (seems) to imply the file is LDraw.org managed.

I would like to see a similar meta for general/user level tagging any file, i could probably be solved by introducing an alias for the !LDRAW_ORG meta combined with additional 'type' keywords.

[Chris Dee]

Has it really been over a year since we last discussed this?

Does anyone have a problem with using "=" as the description prefix for alias parts? I think it is a good compromise.

[Tim Gould]

For the record, the version of LDMakeList that will ship with the new AIOI (available here) can remove aliases based on their definition as an alias part without resorting to prefixes (-a option).

It can also strip the '=' sign from the alias parts if you go down that route (-i= option).

Tim

[Philippe Hurbain]

How time flies!
Yes, I'm fine with = prefix for aliases.

[Willy Tschager]

For the record, the version of LDMakeList that will ship with the new AIOI (available here) can remove aliases based on their definition as an alias part without resorting to prefixes (-a option).

For the record, the new AIOI with the above behavior has already been shipped.

w.

[Chris Dee]

So, the decision has already been made! I missed that.

[Willy Tschager]

Chris,

sounds like you didn't read the email I sent you Sun, 21 Jul 2013 12:33:06.

w.

[Allen Smith]

I implemented alias detection using !LDRAW_ORG Part Alias.

That was correct, right?

[Tim Gould]

That's how I detected them.

Tim

[Chris Dee]

Yes, perfect - that's what that line is really there for.

[Chris Dee]

Does this mean that people no longer feel the need for a one-character prefix in the Description line for aliases?

There are a bunch of ready-to-approve aliases on the Parts Tracker that I'm happy to admin-edit if we still think it is useful to have a "=" prefix (and I'll fix the 78 parts already in the official library).

[Philippe Hurbain]

Mixed opinion here: I like the "=" prefix as it allows to tell at 1st sight which is an alias and which is base type - Now question is which is "base type"? And so, if we don't have "=" prefix, the user has the possibility to choose the exact design number he wants (without "=" all such aliases are sorted together) and if he doesn't care, then LDMakelist can simplify things for him.
Using no prefix finally seems a (weak) winner...

[Rolf Osterthun]

Hey,

in my opinion, alias parts and normal parts should be handled as equal as possible. It is too bad that LEGO uses different numbers for equal part designs but they will have their reasons. And I think that Philos argument "choose the exact design number" is weighty. So, I think it is not useful to have that "=".

Another possibility to get rid of the alias files would be to deposit the alias numbers in the original files. Maybe with some kind of new META statement. That would save time and space but make the search algorithms more difficult. Anyway, I think that the ldraw file format (and the tools based on it) is too deadlocked to accept such a cut.

Rolf

[Chris Dee]

I agree that all known DesignIDs should be available to someone to wants to select a part by number, but the duplication of identical descriptions in a descriptive list is frustrating to users who don't care about the existence of aliases. Randomly choosing an alias instead of a base part unnecessarily complicates model files. LDMakelist helps to solve that (with the appropriate options) by excluding aliases from parts.lst.

Adding alias numbers into the base part as metadata is not a restriction of the LDraw file format - we can invent whatever meta-statements would be useful. The main problem is lack of support for such extensions in tools that are no longer in development (e.g. MLCad).

However, adding the alias numbers to the base part would mean that we would be forever re-issuing parts when a new alias is released. Managing the existence of an alias as a separate file has strong benefits to me from a release management perspective. Support questions like "why is this model not finding this part" are much easier to answer with "that part (file) was not released until update YYYY-XX" than "well, that's really an alias of part NNNN and the relationship between the two was not established until the version of NNNN released in update YYYY-XX". So, I'd much prefer the unit of release control to be the Design ID.

[Tim Gould]

I think the '=' still has merit. It allows the user to keep the alias files in parts.lst, but hide them away in searches via the first character.

I'll certainly be excluding them from my own parts.lst, but other people may not and it's best to give them the wider choice. Removing the '=' is easy (there's an option for it). Adding it is harder.

Tim

[Philippe Hurbain]

Removing the '=' is easy (there's an option for it). Adding it is harder.

Good point.

[Magnus Forsberg]

I have two question here

1.)
There is still no GUI for LdMakeList. How would a user do, without that?

2.)
May I again point out the difference between an "Part_Alias" and a "Part number used for transparent/laquered parts".
Will I be able to find what number to use, if I want to build with, say, only transparent parts.

Please read more below in this thread.
Don't forget the all important playabillity...

[Steffen]

After some doubts I am happy to see that the aliases now have appeared on the PT
carrying the "=" prefix.
http://www.ldraw.org/cgi-bin/ptlist.cgi
That character IMHO is the ideal choice for that purpose.

The small weakness that an alias and its "base part" this way are not "equal"
is _tolerable_ for me.

Sadly I will not be able to exclude all the aliases from my parts.lst
because I will then not be able to open models using them.

So I'll use the "=" just for filtering.

I like that we have it now.

[Chris Dee]

So far I have only updated the descriptions on the "ready for admin certify" files on the Parts Tracker, but I'll work through the others and re-cycle the 78 existing official alias parts through the tracker with Fast-track approval.

[Steffen]

thank you very much for all this tedious work.

repetetive tasks like this are probably the most boring things to do as a PT admin,
but this cleanup is necessary and needed.