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
and use something like
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_ColourCode:
0 !LDRAW_ORG Item
Chris (LDraw Parts Library Admin)