Has anyone worked out the part number(s) for the new PFS motor x1688a? I've got a good working mockup with everything in the right place but no number to call it.

Tim

Discussion here has encouraged me to [re]start reviewing parts in the tracker. If you're interested in doing the same, you may not be sure how to start, so I thought I'd share some helpful links and ideas.

Neils Bugge has written a pretty nice comprehensive tutorial about reviewing LDraw parts. He describes what to look for and some good tools to use.

I find it helpful to have a list of specific things to check every time I go through a process like this. Following Neils' example, I think there are two basic types of tests: using various programs to help check for technical errors, and inspecting the part visually to look for more subtle or subjective issues. Here's my checklist:

- Does it look like the physical part? Right type of studs, clips, etc.? Are the dimensions right? (Bricksmith will report real-world dimensions. Other programs will give the bounding box in LDraw units, too.)

- Is the origin and orientation of the part sensible and consistent with similar parts? (Using the "Show Axes" option in LDView or L3Lab is useful for this comparison.)

- Does LDView report any errors or warnings?

- Does L3P report any errors? ("l3p -check PARTFILENAME.dat" )

- Does Planarcheck report any problems? ("planarcheck PARTFILENAME.dat" )

- Inspect with BFC color coding in LDView or L3Lab - are any back (red) surfaces visible?

- Check for proper stud orientation by rendering with L3P or enabling stud logos in LDView.

- Check for appropriate coordinate precision and number format (leading/trailing zeros, etc. See spec.)

- Does the part make use of relevant primitives (stud groups, boxes, clips, pins, etc.)? (Note my opinion that if everything else listed above checks out, it should be OK to certify a part even if could still be refactored for better efficiency or performance. As Willy points out in reply, this is what the "needs work" label is for. I think it's important to utilize this option to get new parts out to users promptly.)

I encourage more experienced part reviewers to chime in with additional advice. Note that I've only included Mac-compatible software in my list - as Neils' tutorial mentions, Windows users will want to employ MLCad and LDDP.

Last but not least, to review parts you need to get reviewer privileges for your LDraw.org account. Hopefully someone can explain that process as well - it seems a bit like a "you need to know somebody who knows somebody" process, if I recall correctly.

Hi all,

I noticed in e.g. 4019.dat lines, like:

0 BFC CERTIFY INVERTNEXT

when investigating a render glitch in my editor, it doesn't expect the CERTIFY token because I was under the impression it's not permitted in this case, confirming:

http://www.ldraw.org/Article415.html

I will loosen the parser, but the library reviewers might want to correct this for the next release.

I would like to stick this post here
so we can start a collection of LEGO color comparison charts here.

There's frequently confusion about slight variations of the color codes,
and sometimes it is good to have different sources.

If you know a good comparison chart, preferably including part photos for examples,
reply to this message.

(Please put a clear, meaningful title to your post, to make it show up usefully in this list of posts.)

Please read:

http://forums.ldraw.org/showthread.php?t...176#pid176

This rises two questions:

* Shall there be a list of priorities to what gets released?
* Has the certification process to be streamlined? (I guess this discussion is a old as the library itself).

Please read also:

http://www.ldraw.org/Article512.html
http://www.ldraw.org/Article398.html
(If the part is good enough for public use, but has some deficiencies that need to be addressed, the text " (needs work)" (without the quotation marks) can be added to the end of the description. Please note that the full description including " (needs work)" is limited to 64 characters, so this decreases the usable portion of the description to 51 characters. If the description includes " (needs work)", a comment must be added to the file immediately following the official header describing the work that needs to be done.)
http://news.lugnet.com/announce/?n=3442

w.

As a followup to this post
http://forums.ldraw.org/showthread.php?t...250#pid250
, I'd like to recommend a thing which proves quite valuable for me during parts (and even model) authoring:
using a source code revision control software (SCM tool) for the LDRAW folder.

Such tools are for example:
* Perforce
* git
* hg
* svn
* cvs
(see http://en.wikipedia.org/wiki/Source_Code_Management for more information)

I personally use and like Perforce;
note that for private use you are allowed to install a local server and client for yourself.

I put my LDRAW folder into that system the following way:

- install initial set of parts
- checkin into SCM
- install 1st update
- checkin into SCM
- install 2nd update
- checkin into SCM
...
- install update 2011-01
- checkin into SCM

Doing it this way gives you a full history of parts: For each and every file,
you can easily see by which update it has been touched, and which changes happened in it.

As I am also keeping all unofficial stuff in the MODELS folder (because the "real" contents of that folder
is not important for me), I'm also checking in that MODELS folder into the SCM tool.
(I'm using the MODELS folder and not UNOFFICIAL or similar, because older tools like L3P only work that way).

This allows me to go forward and backward with the changes which I do in the files.

So I this way got rid of having to keep manual backup files etc.:
the SCM tool does everything for me.

I'm just dropping this idea here in case somebody else also needs or likes it.

Play well -
Steffen

I didn't know where to write this note, so I've decide to do it here.

I´ve found that I can´t enter the wiki of Ldraw:

www.ldraw.org/wiki/index.php/Main_Page

Do anybody know what's the problem?

Thank you.

Hi All,

Sometimes I find it hard to keep track of all the little programs for part authoring: things like 'inliner' and Philo's myriad of tricky tools. Could we keep a master list of them in this thread?

It also allows me (and others) to share scripts that we wouldn't upload to the master software list. As I will do in a few seconds.

Tim

As a follow-up to this thread, I decided to create a list of parts I think are important and would like to see released officially. I intend to update this over time, removing parts that are released and adding new parts as need/want arises. I'd like to encourage others to add their own lists as well, as I'm bound to miss/forget parts and it's always good to add other perspectives to the discussion.

As a side note to the question, "Why don't you build/perfect/review them yourself?" I lack the tools and technical know-how to do this myself. I know, given enough time, I could probably figure it out, but, for me, time is always an issue. In the time it would take me to become proficient enough to be of any real use, these parts could probably have been developed, from scratch, 10 times over. It's not that I wouldn't like to contribute to the community, it's just I don't think I'll be doing it in the area of parts development.

Is there a documented official standard location or search strategy for the ldconfig.ldr file? I just skimmed the specs and couldn't find this written down anywhere. There's plenty of documentation on the contents of the file though.

I'm asking because I just updated ldglite to look for it in the ldraw directory, which is not normally in the search path for part files, so I want to be absolutely sure this is correct before I build any release executables.

Thanks,

Don