Hi folks,

I just updated the MLCad.ini file accordingly to the latest LDraw.org parts
update 2011-02. The .ini file defines (among other things) the parts available
in MLCad's minifigure generator. This is by far the most extensive addition of
minifig parts I remember.

Download the file from my website: http://www.holly-wood.it/mlcad/ini-en.html

A direct download is available at: http://www.holly-wood.it/files/mlcad/MLCad.ini

Bye, w.

Anchor for Technic Series

Traditionally LDraw has always been installed under C:\LDraw on Windows machines.
I never liked the idea of placing it directly under C.. somehow it seemed unorganised and made more sense under Program Files. The AIOI does just that and on my Windows / machine creates the LDraw folder under C:\Program Files (x86)\LDraw. This has 2 drawbacks though.

First of all, the AIOI is used by many people who want a simple, fast out-of-the-box LDraw installation. But when they want to update the parts library they find the proposed installation path given by the executable LDraw.org provides is the traditional C:\LDraw. They are unlikely to remember where the AIOI installed everything and if they simply go ahead and install the update will not show up in their MLCad.

Secondly, if they are clever enough to use LDView to update their library they run into another problem: LDView will throw an error and not install the update. The reason is that LDview has no admin rights to make any changes to the installation folder and so cannot install the update. In order to fix this a user needs to go into C:\Program Files (x86)\LDraw and remove the "read-only" option for that folder and all files and folders included in it.

I have addressed this issue on the HispaBrick Magazine blog.

Neither of these situations is ideal. Granted, LDraw users might be expected to have some computer skills, but ideally LDraw should be accessible to anyone without the need to know these things.

I don't know which location is preferable for LDraw (C:\Program Files (x86)\LDraw or C:\LDraw) but it would make sense to help users as much as possible to avoid any confusion. Maybe the LDraw.org update could include an AIOI option to make sure files are installed at the right location.

At the same time, maybe it is possible for the AIOI to change privileges for the installation folder so as to ensure that LDView can actually carry out a parts update without running into problems.

Neither of these two situations is ideal.

Does anyone of you have an executable of WINDZ available to give me?
It seems to not be downloadable anywhere anymore.
I've been BFCing parts in the past some time, always using the "manual method", i.e.,
looking at the part in LDView, identifying the wrongly oriented faces, coloring them in MLCad,
then changing their winding in LDDP, or inserting INVERTNEXT's.
When I look at parts in red/green BFC checking mode in LDView, I always thought
that the BFCing process - to a certain extent - should be easily automatable;
I think that's what WINDZ also does:
just render the part from various perspectives, and flip all faces that appear "red" during that.
Of course, if a surface gets flipped twice this way, it cannot automatically be oriented correctly,
and manual post-correction is needed. However, for a majority of parts, the described
method should trivially work like a breeze.
Does anyone of you know of software which does that?
I want to speedup my BFCing processing...
Having such a software would allow us to instantly BFC big amounts of our library,
and reduce the remaining manual work to the parts which really require attention.
My best preference would be a tool like edger, command line based,
and simply taking an input file, outputting a result file where all faces are oriented correctly,
and the file otherwise unchanged. Undecidable surfaces should be colored in a user-selected color,
so they can be taken care of manually.

Hi all,

Below is a perl script to take a bunch of angles and convert them to points on the edge of a circle primitve (ie. a 16 or 48 point polygon). The comments up top describe how to use it. It's designed to make generating rims on the bottom of curved parts relatively easy when there's only a few segments required and hand-coding makes more sense than using Philo's wonderful toys.

Tim

Currently, when you change the color of a road baseplate, the road surface changes color as well as the studded area. This is incorrect IMO, and the road surface should remain gray no matter what the color of the studded area.

My 2 cents.

Hi all,
Presently, the certification status of parts that have subparts is very blurry: there is only one yellow color tag. I think that this lack of visibility greately reduce review rate... Would it be possible to have a more detailed view, depending of status of subparts (and subsubparts and so on...)? eg.

• Yellow: at least one subpart in the tree needs more certification vote
  
• Orange: at least one subpart in the tree has a hold vote
  
• Light blue: all subparts in the tree have at least two cert votes
  
• Blue: all subparts are certified
  
• Bright Green: part has at least two cert votes, all subparts in the tree have at least two cert votes.
  
• Green: part and all subparts are certified.
  

I think the topic Chris raised about using color 16 in patterns where it makes the pattern useless for any other brick colors than the original one has had enough feedback from the general populous that we should now decide if the spec should be updated.

My personal opinion is that in cases like the fire logo, where it's clear that a specific color is required, that color should be used in the pattern file. And in cases like the gauge where it's ambiguous, color 16 should be used. Perhaps disagreements over whether or not something is ambiguous could be resolved by the part admin.

Thoughts, everyone else?

I would like to ask here if someone knows more about the status of peeron.com.
What was the last parts update integrated there?
Does anyone happen to know who will push the recent one to their site?

I see changes happen on their site everytime, e.g.
http://www.peeron.com/cgi-bin/invcgis/history
, but no integration of parts updates I can see so far.

For example, look at the famous 7740 train inventory:
http://www.peeron.com/inv/sets/7740-1
where I would hope that the MOVED-TO parts automatically get updated
when integrating a new parts release.

In forum pages like this, what does the Views count represent? Unique users or a cumulative count including repeat views by the same user? Is the count for a higher-level message incremented if you open the whole thread from the last message?

I'd prefer the former to get a feel for how many members are interested in a particular topic, even if they don't respond.