LDraw.org Discussion Forums
3626a/b/c - 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: 3626a/b/c (/thread-12124.html)

3626a/b/c - Stephan Meisinger - 2014-01-18


i would like to adress the issue preventing 3626cpm0.dat (and maybe others) to go offical. (since Oct 2013)
Since printings with the same print on different stud types will increase. b and c types are both still in productions (and there also some a / b matches)

What are the options?
Where is the problem in general?


Re: 3626a/b/c - Christian Neumann - 2014-01-18

This is some formal problem. The unpatterned head variants have the stud type within the part title, this specific file doesn't. Instead it uses the !KEYWORDS tag to describe the type as "Recessed stud", which is inconsistent with the other descriptions (i guess "closed hollow stud" would be correct).

According to Magnus' analysis, various other files use different namings for the same stud types. He now suggests to
a) use correct naming per stud type variant
b) not refer the stud type in the part title
c) put the stud type in !KEYWORDS tag

Now it has to be decided what is the correct name for each stud type, and where to use it (title or keyword tag).

Re: 3626a/b/c - Christian Neumann - 2014-01-18

I would like to add some personal thoughts:
While i think it is important to be consistent along all files of a same type, i see no real benefit in adding the stud type in title as well as keyword tag, since the file name 3626a/3626b/3626c does already imply the stud. To enforce it as text is some kind of information redundancy and adds, as this specific case shows, another possible source for errors.
An end-user who searches the pattern will possibly ignore the stud type, as it is of very low importance. And people who really want the correct stud type for their models will probably know what they search for (a/b/c variant).

Re: 3626a/b/c - Max Martin Richter - 2014-01-18

If would go this scheme, all our a/b... versions had a redundant description...

My personal opinion is, that the stud type should be mentioned in the description. When I re-build an official model, I really look for the correct part types, whenever possible...


Re: 3626a/b/c - Christian Neumann - 2014-01-18

Max Martin Richter Wrote:When I re-build an official model, I really look for the correct part types, whenever possible...

Me too, but not by searching a (possible wrong or inconsistent) description, but the part name. The part name is the most reliable component. Titles and texts are very often inconsistent over time.

I already did some head patterns that are official now, and none of them contain the stud type as text. And no one noticed. If that was a fault, it shows how difficult it is to maintain all these unwritten rules when reviewing parts. I have seen parts on hold for redundant information, and here it should be mandatory?

Re: 3626a/b/c - Chris Dee - 2014-01-19

We are in danger of making a lot of work for ourselves for little benefit to the LDraw user. From a functional perspective how much difference does it make if a minifig is rendered with a type "a" head instead of a type "c", so long as the pattern is correct. I fear we risk a lot of fruitless discussion about which patterns were produced with which part design.

I'd prefer NOT to mention the stud type in the descriptions for patterned heads.

We have never tried to tackle this issue with the three (?) forms of minifig torso, and I'm not suggesting that we start now.

Re: 3626a/b/c - Christian Neumann - 2014-01-19

A similar discussion started in this thread.

Re: 3626a/b/c - Stephan Meisinger - 2014-01-19

which sadly don't had an agreement.

My view is:
a) allow every existing combination.
b) add information in title
c) keyword don't care if or if not

to a) what would be the point to deny a valid combination? If some modeller want to have it - he can do it. Of course it shouldn't be mandatory to do all existing combinations. With Subfiles the library shouldn't grow to an insane number.

to b) to help beginners to point to the diffs - so they can get the "oh"-effect. Then they either never mind again OR they are interessted and recheck every part they own ;-)
Imho If users don't like to have many near duplicate parts, the drawing/modelling software should have a filter. I don't think this should be an issue of the data to provide the possibility.

Re: 3626a/b/c - Christian Neumann - 2014-01-19

There is also a rule that denies duplication of info, so if you use the title for the stud type you cannot put it into keywords too. That's the reason why it should be clear whether to use title or keyword. Don't use both, and don't use none of them...

But i think also that if a pattern is known to exist in more than one mold, there should be no problem to model these, as for especially heads there is only the sud to be changed. The numbering is not necessarily consistent then, for example 3626bp05 would eventually be different from 3626cp05. But as long as the description is the same, i see no problem.

Re: 3626a/b/c - Chris Dee - 2014-02-04

After some thought and discussion, I would like to move ahead with
a) Solid Stud
b) Hollow Stud with Pierced Base
c) Hollow Stud

This qualifying text should be added to the end of the description, and only if needed to distinguish the same pattern on different versions of 3626.

I'll fix the current library.

Re: 3626a/b/c - Stephan Meisinger - 2014-02-12

great :-)