Elimination of Physical_Colour parts from the library

[Willy Tschager]

Hi,

the LDraw SteerCo has unanimously decided to eliminate the current Physical_Colour parts from the official LDraw Parts Library via fasttrack. Physical_Colour parts are parts with hard coded colours, an unique part number and an underscore in front of the description. LEGO calls these "Element numbers". Following a few part numbers from the current library for comparison:

4277932.dat
4277933.dat
300321.dat
4116604.dat
...

But before they get "obsolated" by the Library Admin, we seek feedback and input from the community. Have your word.

Willy Tschager
on behalf of the LDraw Steering  Committee

[Gerald Lasser]

Hi Willy,

In honestly never understood, why those parts are in the library anyway. I could not think of a reason to have them.

Actually I wanted to post this question since some time, so it is good you ask for opinions.

The only reason, is backwards compatibility of models in the wild...
But I think the colour hard coded parts are against the spirit of LDraw.

Gerald

[Orion Pobursky]

The only reason, is backwards compatibility of models in the wild...
But I think the colour hard coded parts are against the spirit of LDraw.

This is my issue right now. I support the notion of removal but what are we going to do about models that use them

[Orion Pobursky]

Aside from the concern I posted above I have one other thing I'd like discussed:

How are we going to allow cross reference between the hard coded color parts numbers and the actual part numbers? One suggestion is some sort of file that editors can reference to provide this data. If we choose this route we could expand it to include a Bricklink -> LDraw cross reference as well.

[Willy Tschager]

The only reason, is backwards compatibility of models in the wild...
But I think the colour hard coded parts are against the spirit of LDraw.

It's not that we actually delete them from the library but HIDE them for the casual user like this:

http://www.ldraw.org/cgi-bin/ptdetail.cg...26bs01.dat

w.

[Willy Tschager]

How are we going to allow cross reference between the hard coded color parts numbers and the actual part numbers? One suggestion is some sort of file that editors can reference to provide this data. If we choose this route we could expand it to include a Bricklink -> LDraw cross reference as well.

This was also my idea. I would be thankful for some suggestion from the code-people how to tackle this.

w.

[Roland Melkert]

I would propose a generic index file structure in an existing format like json or xml.

And then include files for specific goals e.g. "LDraw2brickLink.json" or "LDraw2Lego.json" etc.

[Gerald Lasser]

It's not that we actually delete them from the library but HIDE them for the casual user like this:

http://www.ldraw.org/cgi-bin/ptdetail.cg...26bs01.dat

w.

Agreed, that's a good approach, hiding them. How many of those parts are actually in the library?

[Jaco van der Molen]

Aside from the concern I posted above I have one other thing I'd like discussed:

How are we going to allow cross reference between the hard coded color parts numbers and the actual part numbers? One suggestion is some sort of file that editors can reference to provide this data. If we choose this route we could expand it to include a Bricklink -> LDraw cross reference as well.

That would make importing an LDraw file in an indexer like Brickstock (which uses the Bricklink database?) a lot easier too.
The most common problem here is all the variants with XXXa.dat, b, c...
We could tackle that too then.

[Chris Dee]

This is my issue right now. I support the notion of removal but what are we going to do about models that use them

With a distrubtion as a zip archive it is not possible to delete files that users have already installed - unzip can't do that. Only option is to hide from the parts list. Fresh installs (with the AIOI) could supress them, but I don't like the idea of different install methods producing different libraries.

[Chris Dee]

Hi Willy,

In honestly never understood, why those parts are in the library anyway. I could not think of a reason to have them.

Actually I wanted to post this question since some time, so it is good you ask for opinions.

The only reason, is backwards compatibility of models in the wild...
But I think the colour hard coded parts are against the spirit of LDraw.

Gerald

They were introduced when LEGO started printing part number in the instructions to try to prevent too many 'why isn't this part number in LDraw' questions. But the concept never really got much traction.

[Chris Dee]

I would propose a generic index file structure in an existing format like json or xml.

And then include files for specific goals e.g. "LDraw2brickLink.json" or "LDraw2Lego.json" etc.

That would create a massive maintenance task. The translations would need to be managed at the granularity of the individual part number, with a mechanism to regenerate the json or xml (both of which would be quite byte-hungry for a simple translation file). Maybe something to build into Parts Tracker v2?

The authoring tools would need to support this new file, whereas the existing methods of hard-coded colour part files is automatiocally supported.

[Franklin W. Cain]

How are we going to allow cross reference between the hard coded color parts numbers and the actual part numbers? 

Well, what I would do is simply read the DAT file of the obsolete part, to see which DAT file is to be used in its place.  (If I correctly understand your question.)  

Thanks, 
Franklin

[Orion Pobursky]

Well, what I would do is simply read the DAT file of the obsolete part, to see which DAT file is to be used in its place.  (If I correctly understand your question.)  

Thanks, 
Franklin

I meant in the future. For the current parts, presumably an editor can update the reference much like a ~MovedTo but changing the color as well as the file.

[Willy Tschager]

While I'm working my way through the Physical_Color parts I'd like to know if we have a some sort of replacement, a list, anything ... editors can work with or I can add to the AIOI so that results pop up when people hit in a casual Physical_Color number into the search.

We started with this: https://forums.ldraw.org/thread-23337-po...l#pid31489

But I still don't see any outcome.

w.

[Orion Pobursky]

While I'm working my way through the Physical_Color parts I'd like to know if we have a some sort of replacement, a list, anything ... editors can work with or I can add to the AIOI so that results pop up when people hit in a casual Physical_Color number into the search.

We started with this: https://forums.ldraw.org/thread-23337-po...l#pid31489

But I still don't see any outcome.

w.

Yah. Because Brickset and Rebrickable have already solved this problem. You just search the number in the BIs and it spits you out the correct brick with an LDraw, Bricklink, Brickowl, etc ID.

[Willy Tschager]

Yah. Because Brickset and Rebrickable have already solved this problem. You just search the number in the BIs and it spits you out the correct brick with an LDraw, Bricklink, Brickowl, etc ID.

This means that I have to be online and use another prog. I was more thinking to offer a some sort of chart such as the LDConfig.ldr which progs use to do a search. Hitting into 123456 points you directly to our 1234.dat in main color.

w.

[Orion Pobursky]

This means that I have to be online and use another prog. I was more thinking to offer a some sort of chart such as the LDConfig.ldr which progs use to do a search. Hitting into 123456 points you directly to our 1234.dat in main color.

w.

I don't see a good way to do this with being online. There are literally thousands (probably 10,000s) of physical color numbers and no easily accessible central list of them. A user will have to type the BI number into a search engine to find out what LDraw number corresponds. Providing a master file would be huge sizewise and almost immediately out of date.