I've noticed that similar discussions are appearing in multiple subforums and that it can be quite hard to work out where a discussion should go (I've got this wrong and I had some say on the initial forum structure). This suggests to me that we may have fallen into the trap of overcategorisation that catches so many new forums.

I can't help but feel that in this case less may be more. I count 18 public forums which does seem a little like overkill to me.

This begs the following questions:

Are there too many forums and should we have fewer?

If so how many is enough?

And what should they be?

I'd like to open this one up to everyone so please have your say.

Tim

Don Heyse and Steffen asked us to discuss the location of LDConfig.ldr, and add it to the standard(s) somewhere, see:

http://forums.ldraw.org/showthread.php?tid=272,272
and
http://forums.ldraw.org/showthread.php?t...349#pid349

Also it appears to me the general search order is documented poorly, or I'm I missing something?

All current standard docs are about file formats and such, we might need a separate one for the file/directory structures.

Hi,

I just wondered why I was not able to file a request/idea in forum
http://forums.ldraw.org/list.php?5
to the LSC.

Why is that door closed?
Should not everybody be able to file a suggestion there?

The issue I wanted to file there is:
an official location for ldconfig.ldr has not yet been rolled out officially,
see this post: http://forums.ldraw.org/showthread.php?t...346#pid346

However, the recent parts library updates issued it officially,
so it is a de facto standard now that ldconfig.ldr sits in the root LDRAW folder
(which is a Good Place ™ IMHO)

My request would simply be to add this to the standards documentation.
Or does that already exist somewhere?

Travis, in case you read this, could you move this thread to the LSC forum?
Or anybody else?

please see this thread:
http://forums.ldraw.org/showthread.php?t...338#pid338

I'm cross-posting it here

3 LEGO minifigs made out of alloy will take a long ride into the universe:

http://news.discovery.com/space/lego-fig...10804.html

http://www.crazyengineers.com/nasa-juno-...board-747/




So the minifigs decided against using their all time classic!

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.