design-id vs item-id

[Michael Heidemann]

Since some years we have beneth the designid.dat files also itemid.dat files in our /parts folder.
This will be ok if there is never a conflict between design id number and item id number.

Joshua Delahunty now identified such a bad situation.(Please read his comments: http://www.ldraw.org/cgi-bin/ptdetail.cg.../74333.dat).

We need to stop immediately the usage of item-id.dat files in our standard /parts folder.

Any suggestion how to solve this issue is highly wanted.

[Roland Melkert]

I have an idea, you're not gone like it though

Adding a third Library folder, e.g. 'instances'.

edit: never mind, it would cause lookup problems, unless it's a subfolder like the /s and /p ones.

[Michael Heidemann]

Yes, you are right, we need to have a folder that is separately mentioned in each line type 1.
Maybe a subfolder of /models would work here ?
I would prefer that, because it is somewhat already a model with fixed colors.

On the other hand maybe not all applications will handle subfolders of the /model folder like the subfolders of /parts.
My second suggestion is therefore a subfolder for the /parts directory. Mabe named "/ldd"?

[Tim Gould]

Yes, you are right, we need to have a folder that is separately mentioned in each line type 1.
Maybe a subfolder of /models would work here ?
I would prefer that, because it is somewhat already a model with fixed colors.

On the other hand maybe not all applications will handle subfolders of the /model folder like the subfolders of /parts.
My second suggestion is therefore a subfolder for the /parts directory. Mabe named "/ldd"?

A subfolder of 'parts' would, IMO, make the most sense. ldmakelist will read it as soon as it's there so it should be fully compatible with existing code (unless they hardwire folders in, which I really hope they don't).

Tim

[Roland Melkert]

My original thought was to add 'instances' along side p and parts thinking, these colored LDD parts are actually a higher level just like parts > primitives.

But it will cause circular references when a ldd part references a normal one with the same number, although this might not happen often or at all. And of course most software use hardcoded parts and p references, so adding a third one will need updates.

The subfolder approach is a workaround, but a messy one though.

[Chris Dee]

This is not really a recent discovery, but I guess I have been in denial, and tried to fudge around it in the library. It has only become an issue with the decision to include "Physical Colour" parts (i.e. Item-IDs) in the library, which I do think is a good idea with greater public awarenes of Item-IDs with their publication in instructions and LEGO online brick ordering. As I understand it the conflict only occurs in 7nnnn numbers. I assume that all 6-digit numbers [4-digit DesignID+2-digit LEGO colour code] and all 7-digit numbers (4nnnnnn) are itemIDs.

I agree that this needs to be resolved.

I think that there are basically two options to solve this a) a file naming convention, or b) a file storage convention.

- A file naming convention (e.g. prefixing Item-ID files with "i") and leaving these files in the LDraw/Parts folder has the least impact on existing tools, but raises concerns with some users who already see the inclusion of such files as "bloat". [Note that the installation of these files can be skipped in the Windows installer, but for simplicity the zip-file distribution still includes them all]. 74333.dat would become the colour 16 designID file and i74333.dat would be the "Physical_Colour" version.

- A file storage convention (e.g. a new LDraw/Items folder) would impact tools that don't have the capability to extend the search path through a configuration file. It would be much cleaner from a distribution management perspective. I could even envisage a much more streamlined review process for this library, if a review process were even needed. A file named 74333.dat could exist in both LDraw/Parts and LDraw/Items, but maybe it would be clearer to give the Item files an identifying prefix.

Whichever way we go, I think it would be good to dispense with the cumbersome

Code:

0 !LDRAW_ORG Part Physical_Colour
0 !LDRAW_ORG Shortcut Physical_Colour

and use something like

Code:

0 !LDRAW_ORG Item

[Joshua Delahunty]

Chris is on the right track. I already use both solutions, and it works out really well (35031 items in my $LDRAWDIR/parts/items/ folder and counting).

Note that items come in three varieties: primitives (hard-coded color), decorated, and assemblies, so this is not a simple case of "regular" parts in specific colors, there is true value to assemblies (multiple primitives that could be hard-colored or decorated with their attendant transforms in place), one that can't be solved by a "simple" database text file of associations of color + design, which has been suggested as a workaround.

-- joshua

[Philippe Hurbain]

one that can't be solved by a "simple" database text file of associations of color + design, which has been suggested as a workaround.

Good point!

[Michael Heidemann]

Code:

A file storage convention (e.g. a new LDraw/Items folder) would impact tools that don't have the capability to extend the search path through a configuration file.

I do not think that there are many of those applications in use.

To solve this issue by file storage is the best solution in my eyes. Depending on the application we also do not need to care about existing models that are build with itemID parts.

The idea of a prefix is not my favorite. If I have the booklet from TLG I am searching for that number that is written there. We should not make it more complex than necessary. If we have a different storage place it should be possible to handle that smoothly.

[Joshua Delahunty]

Code:

A file storage convention (e.g. a new LDraw/Items folder) would impact tools that don't have the capability to extend the search path through a configuration file.

I do not think that there are many of those applications in use.

To solve this issue by file storage is the best solution in my eyes. Depending on the application we also do not need to care about existing models that are build with itemID parts.

The idea of a prefix is not my favorite. If I have the booklet from TLG I am searching for that number that is written there. We should not make it more complex than necessary. If we have a different storage place it should be possible to handle that smoothly.

The software could handle the naming convention for file access separately from a user interface presentation, so using a prefix would not necessarily present a bad user experience, and it has the advantage of working with existing software (albeit without as nice a user interface).

[Joshua Delahunty]

As I understand it the conflict only occurs in 7nnnn numbers.

A quick query shows 1445 conflicts. Removing decals/labels (which don't make sense to have as color-16 part files anyway), shows 1361 conflicts. About 650 of those are 70000 range.

Those numbers are low, too. I noticed the 6000 range motors conflicting with (later-issued) 6000 range primitives didn't appear in the results.

I assume that all 6-digit numbers [4-digit DesignID+2-digit LEGO colour code] and all 7-digit numbers (4nnnnnn) are itemIDs.

There are 7-digit item numbers (not of the range 4000000) from 5-digit design+2-digit color and 4-digit design+3-digit color, and 8-digit item numbers with 5-digit designs + 3-digit colors. [These are generally corner cases]

Also 70000 range and 80000 range, plus 7000 and 9000 parts (we just went through a 9000 series part in part review). [70000, 80000, 9000, we see in BOMs still]

[Joshua Delahunty]

one that can't be solved by a "simple" database text file of associations of color + design, which has been suggested as a workaround.

Good point!

Here is an example of the most egregious assembly I could think of. This simply can't be represented by a 1-1 correspondence text file. Note that assembly descriptions themselves reference other item IDs, either pattern item IDs or primitive item IDs.

I picked this one out of the TECHNIC figures because a) the design has been modeled in LDRAW (without TEXMAP required), and b) all the item IDs are fully known.

This is just an example, it's obviously not useable as-is (one would need the other item files referenced). Most of the primitives should be inferable from the numbering.

This is Peeron 2698c01px21 (bricklink tech021)

-- joshua

Code:

0 TECHNIC fig. no. 14 (Bright Blue)
0 Name: 4105230.dat
0 Author: BrickOracle element generator
0 // TLG item ASSEMBLY

0 unofficial part
0 CATEGORY Figure, Midi and TECHNIC

0 // This file has the TLG item number, name, and color for the given element.
0 // It also lists the approximate year range this number was active.

0 // This file is compatible with LCAD tools, but it is NOT subject to
0 // the LDRAW Contributor Agreement, which means your rights are restricted.

0 // Permission is granted to use this file for any purpose ONLY if it is left unmodified.

0 // 4jj

1 16  0 -96 0  1 0 0  0 1 0  0 0 1  items/270826.dat
1 16  0 -54 0  1 0 0  0 1 0  0 0 1  items/81945.dat
1 16  0 0 0  1 0 0  0 1 0  0 0 1  items/82534.dat
1 16  26.2 -46 0  0 0 -1  -1 0 0  0 1 0  items/270123.dat
1 16  26.2 -46 0  0 0 -1  -1 0 0  0 1 0  items/270523.dat
1 16  26.2 -46 0  .7071 0 -.7071  -.7071 0 -.7071  0 1 0  items/270023.dat
1 16  48 -24 0  .7071 0 -.7071  -.7071 0 -.7071  0 1 0  items/270123.dat
1 16  48 -24 0  -0 0 -1  -1 0 0  0 1 0  items/270523.dat
1 16  48 -24 0  1 0 0  0 0 -1  0 1 0  items/270023.dat
1 16  48 10.5 0  -1 0 0  0 0 -1  0 -1 0  items/270224.dat
1 16  -26.2 -46 0  0 0 1  -1 0 0  0 -1 0  items/270123.dat
1 16  -26.2 -46 0  0 0 1  -1 0 0  0 -1 0  items/270523.dat
1 16  -26.2 -46 0  -.7071 0 .7071  -.7071 0 -.7071  0 -1 0  items/270023.dat
1 16  -48 -24 0  -.7071 0 .7071  -.7071 0 -.7071  0 -1 0  items/270123.dat
1 16  -48 -24 0  -0 0 -1  -1 0 0  0 1 0  items/270523.dat
1 16  -48 -24 0  -1 0 0  0 0 -1  0 -1 0  items/270023.dat
1 16  -48 10.5 0  1 0 0  0 0 -1  0 1 0  items/270224.dat
1 16  0 0 0  1 0 0  0 1 0  0 0 1  items/269923.dat
1 16  0 0 0  1 0 0  0 1 0  0 0 1  items/271023.dat
1 16  15 17 0  1 0 0  0 1 0  0 0 1  items/4105237.dat
1 16  10 58 0  1 0 0  0 1 0  0 0 1  items/270423.dat
1 16  10 98 0  1 0 0  0 1 0  0 0 1  items/270626.dat
1 16  -15 17 0  1 0 0  0 1 0  0 0 1  items/4105233.dat
1 16  -10 58 0  1 0 0  0 1 0  0 0 1  items/270423.dat
1 16  -10 98 0  1 0 0  0 1 0  0 0 1  items/270626.dat

0
0 // end TECHNIC fig. no. 14 (Bright Blue)
0

[Joshua Delahunty]

I wish I'd known this was so easy to do when I posted previously. This is the full figure that's (partially) described by the code above.

[img]www.brickoracle.com/Billund/medier/4105230.gif[/img]