numbering scheme for assemblies

[Steffen]

At part
http://www.ldraw.org/cgi-bin/ptdetail.cg...343c02.dat
on the parts tracker, an important question got raised,
which is probably complicated to discuss, so I suggest to relocate it to here:

the problem is: what filename should we assign to assemblies?

let's assume we have a door 4343.dat, and a glass 4344.dat.

Let me describe the common practice of the past first:

Our technique was - not knowing official TLG item or design IDs -
to use the "main" part, here: the door, of the assembly and number the assembly after it.
Thus, in our case, 4343c01.dat was the result.
In some assemblies it's unclear what the "main", "dominant" contributing part is, but you have to make a decision.
In that assembly, that main part usually gets color 16 to still let the user colorize it as desired.

NOWADAYS we do know some of the item or design IDs of such assemblies.

The question that now arises is how we deal with that. Let's assume, we somehow know that the assembly
should get number 123456789. What to do now?
The options we have is:
(a) abolish the ...c01 suffix technique at all in this case, just using 123456789.dat for the assembly
(b) keeping the old technique, i.e., 4343c01.dat, and creating an alias 123456789.dat pointing to there
© using 123456789c01.dat, i.e., mixing the 2 concepts

Sadly, all 3 options have disadvantages
Solution (a) drops 2 nice features of our library:
- you can recognize from the filename to which part an assembly belongs to, i.e. 4343c01.dat belongs to 4343.dat
- the ...c01 suffix is nicely matching the ...s01 and ...p01 and ...d01 suffixes
Solution (b) creates 2 files instead of 1.
Solution © is IMHO totally misleading. It suggests that 123456789c01.dat contains an assembly of 123456789.dat, i.e., an assembly of an assembly. So to me, this is the weakest of all 3 options.

To me, the smallest disadvantage is solution (b), because we anyway create shortcuts and aliases all the time.
Would we correctly create 123456789.dat as an alias, having a leading "=" in its name, then users even can
leave away such files if they find them to be clutter.

So my opinion is to use option (b).

[Max Martin Richter]

The problems gets bigger and bigger if we take attention to fact, that a DesignID of TLG can be used for several colour combinations sometimes.
So we would need to make "AssemblyDesignIDcXY.dat" where XY is the counter.

IMHO we should use your second suggestion. so we can easily add a cXY if necessary.
This would mean, that we have "MainPartOfAssemblyDesignIDcXY.dat" (with a special colour combination) and we have "AssemblyDesignIDcXY.dat" with the same colour informations.

/Max

[Arthur Sigg]

Each part produced, independent of a "stand alone part" or of a part usable together with another one, has it's own Design ID, lets say 60594 Frame 1x4x3. To order such a part from the manufacturer in a specific color you have to use a Part ID which is unique to a shape AND a color but not a combining of numbers, e.g. 4530589 for a Black Frame 1x4x3. As far as I know the manufacturer has not implemented any relations (logical link) between parts, but there could be a "hint" as part of the name for. For example Design ID 86210 Glass for Frame 1x4x3 - for color Transparent Part ID 4552033. In this example numbering is completely different. Integrating a relation in the part name could be helpful but is far away from a systematic structuring, and in this example a "one way relation" :-)

My question now: Why assemblies ? A day the manufacturer will come to the decision to produce a different "Glass for Frame 1x4x3" with a completely other shape. Or vice verca some other frames or doors or walls or panels or ... using the same glasses. Crossover assemblies ? Multy assemblies ? The manufacturer's designer will use every part, indpendent of "assembly character" or not to build new sets, so one can imagine, that a part yesterday "assigned" to another part could migrate tomorrow to a "stand alone part" for such a new set. From my point of view there is no need to have "assemblies" in the part library. Such a overlaying combining of elements in a hierachical structure are "alien to the system".

BTW: Brickset's part content is obviously based on the manufacturer's structuring, naming and identifying [Quote: "Categories and colours are official LEGO classifications and names" Brickset Browse Parts. It is completely different from the LDraw part library ... sword of Damocles ?

It seems to me as if I could hear the rattling chains of your demons ... sorry, I do not say much, but what I have to say, I say, whether we like it or not :-)

Arthur

[Max Martin Richter]

Arthur,
please see Part 47899 on Brickset. This part is an assembly of 4343 and 4344. Nowadays it exists in four colour combinations with the numbers 4503011, 73436, 4258478 and 4514970. (The second ElementID seems a bit weird, but who cares...)
In our system we need the number 47899c01, c02 and c03 and/or 4343c01 to c03, because the glass (not the main part) is TransClear in two assembleys...

/Max

[Philippe Hurbain]

I too would like to see clear rules about this. Main problem is that we look for something consistent more or less related to LEGO numbering scheme when this one is NOT consistent...
Things are even more muddy when you add printed parts in the scheme, eg. there is only one design number for the cow assembly with different patterns (64652) and 3 cockpits 8x16x5 design numbers according to pattern.

[Max Martin Richter]

Sometimes I think, the numbering guys from TLG are somewhat drunken when they're making new numbers :-)
But you are right. It's hard to find a way for this...

/Max

[Arthur Sigg]

Sorry, I used a wrong example in my answer: Dismountable parts normally used together.

In case of the given example 47899 the four "assemblies" are not dismountable, they e.g. are glued together. From my point of view such objects cannot be assemblies, there are unique parts like a simple brick. A "forced dismounting" ends up in a defective part ! The method of manufacture of a part is not relevant, a brick could be glued together of pieces in different shapes and colors, therfore it is not an "assembly" ( a wonderful imagination of "popart bricks" :-). So, the only useful numbering of the four parts with Design Number 47899 I can see are the TLG part numbers with fixed colors.

And this brings me to a related problem which could be a discussion worth too. MLCad allows it to combine a part with all the colors of the (official) color table, no limitation with respect to the real production program of TLG. So I'm able to build a pink truck with a transparent ladder, lavender tyres, a yellow framed 47899 a.s.o. Ok, why not :-) But if you want to build your MOC as a "real possible model" there should exist a second library (or a expanded Design/Element library) with all the colors ever produced for each part (TLG Part IDs) and the CAD program has to check/propose the availability. Implemented as an option this could be very very helpful during the building process, understood as a preparation for a real MOC. To be sure, if a specific part in a specific color can be used, today you always have to have a look first at an other place like Bricklink or Brickset. Sometimes this could be very annoying and is unnecessary time-consuming !

In such a building environment the approach "a not dismountable assembly is a part" could have its best place.

Have a nice weekend.
Arthur

[Max Martin Richter]

Do you know about our physical colour parts "library" ?
The reason that it is not complete is a result of the time consuming creation for all these parts...

/Max

[Steffen]

> In case of the given example 47899 the four "assemblies" are not dismountable,
> they e.g. are glued together. From my point of view such objects cannot be assemblies.

But from a rendering perspective, they are. There still remains a "gap" between those parts.
That's something different than a single part.
For this reason, our library contains various "glued" assemblies.
We in the past have decided to go that way and ignore the fact if something is glued or not.
Example: window+glass where the glass is glued.

[Michael Heidemann]

I think that my application LDDMaker can be helpful for this task. It's a little bit outdated, but if there is interest in making those Physical_Colour parts more comfortable I will update that for the todays needs.

[Chris Dee]

... and the the library structure needs some modification to accommodate the use of the same number as an ElementID (Physical Colour part) and a DesignID. It is on my ToDo list, which is why there are a bunch of "Physical Colour Parts" waiting for Admin review.

[Michael Heidemann]

I just stumbled over this thread again.

Do we have a solution now? There is many input, but no conclusion - or I am blind? In which official document can I read about this question?