LDraw.org Discussion Forums

Full Version: Alias parts PHP script
You're currently viewing a stripped down version of our content. View the full version with proper formatting.
Pages: 1 2
I response to complaints about my (inadvertent) use of alias parts, I wrote a PHP script that updates a model file to not use them. This could easily be extended to also handle MovedTo and Physical Colour parts. Is there any interest in this being hosted on the LDraw.org servers?
Has any official decision been made about marking Alias parts? I am eagerly awaiting so I can exclude them from the default part library I display; that would probably make the script unnecessary.

Orion, could you attach the script to your forum post?


Note that it pings the official library every time it runs. This is so I could test it on my local machine. This isn't an issue if it were hosted on the LDraw.org servers since it would be a local file operation but outside of that I think it wouldn't be appropriate to put it out in the wild since it'll draw bandwidth from LDraw.org.

Also note that I only check official files.
Is it too much overhead to read the !LDRAW_ORG metadata? It should always be line 4 and Alias parts will be labelled
0 !LDRAW_ORG Part Alias

I'd really like to move away from the use of an arbitrary character in the title to identify the file type.

The main discussion is in this thread.
That's what my script does
Chris Dee Wrote:Is it too much overhead to read the !LDRAW_ORG metadata?

That should be fine. I just needed to know that an official decision had been reached.

I don't think I really matters since Bricksmith doesn't use parts.lst. In fact parts.lst is mostly obsolete.
I just want to note that no script should rely on that any of the header lines occurs in a certain line number.
"It is always on line 4" is something we should avoid.
Of course, we should stick to adopting some "normal" default order in the header when publishing parts,
but all tools should be capable of reading a file where 1 or more of the header lines is not present,
or where they are in a different order.
The header lines should more be treated like "key = value" assignments:
they convey the information
  • type is xyz
  • license is xyz
In which _order_ this information is communicated to a tool should be of irrelevance.

Just wanted to mention this,
applying the general principle 3.9 from here http://www.faqs.org/rfcs/rfc1958.html :
"3.9 Be strict when sending and tolerant when receiving."
Implemented and checked in.

Thanks, Chris.
Pages: 1 2