LDraw.org Discussion Forums

Full Version: design-id vs item-id
You're currently viewing a stripped down version of our content. View the full version with proper formatting.
Pages: 1 2
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.
I have an idea, you're not gone like it though Smile

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.
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"?
Michael Heidemann Wrote: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
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.
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
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
Quote: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!
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.
Michael Heidemann Wrote:
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).
Pages: 1 2