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.

Hi,

99009 Technic Turntable Small Top
99010 Technic Turntable Small Base

Above two part didn't release even as unofficial part yet.

Anybody, any able man, please, do something for these part.

KWON

An issue has arisen on the Parts Tracker that I think deserves wider discussion than is possible there.

By convention, we only model the printed colours of patterns and use colour 16 for any unprinted areas. This allows the base part colour to "show through" when rendered. Although this is exactly what would happen if LEGO were to print the pattern on another colour of part, there is an argument that in some cases we are restricting the usability of the LDraw library by doing this.

The Fire Logo Pattern has caused most concern. By leaving the unprinted left-hand flame as colour 16, the LDraw part files that use this can only really be used in red. The second example is the Slope Brick 45 2 x 2 with Gauge Pattern, which is normally printed on black and uses the base part colour to create some of the detail. The potential benefit is shown in this rendering by Magnus Forsberg - left image = "desired" rendering on green; centre image = actual pattern on black"; right image = actual pattern on green.

I can see that the case is clear for the Fire Logo - the left flame was always intended to be red. For other patterns, including the Gauge Pattern, we would need to guess about the intent of the pattern designer. That guesswork makes it very difficult to apply any consistency, and potentially generates more controversy than the current discussion, as the implementation will depend on each person's interpretation of the design intent. The benefit of the current solution is that it is totally unambiguous, but I fear we are applying rules for their own sake and denying rendering opportunities to the users of the LDraw parts library.

For now I have certified these patterns and their parent parts as they now fit with the current convention. However, I would welcome further discussion, opinions and potential solutions.

The forum won't keep me logged in from one session to another on Firefox. It keeps me logged in on both IE and Chrome, but not Firefox. Is anyone else having the same problem? I'm guessing it's something with the configuration of one of my Firefox add-ons (like Adblock Plus or NoScript), but before I spend significant time and effort tracking down the problem, I'd like to verify that other people using Firefox are able to stay logged into the forum from one session to the next. (I already deleted all cookies that matched ldraw as a search string.)

Having recently stuck my nose in the PT again after a long hiatus I've come, partially, to remember certain things about it that concern me a little. Most notably I've spotted examples of what I consider to be incorrect 'hold's on the PT.

From the PT Reviewew FAQ a 'hold' is for "It's getting there, but not yet. There are errors to be corrected before the part can be released. The author has to take care of the errors." Obviously there is some leeway in deciding what is wrong or right, but I've seen more than a few 'hold's that I think were simply imposing of the reviewers views on an iffy issue.

I'm writing this mostly to ask reviewers to give more consideration to whether a 'hold' is really appropriate or if a 'novote' might not be better. Especially if what you are demanding is in a grey area of standards. This isn't to criticise the reviewers or reviews, especially as there are times when I agree with the point but disagree with the 'hold'. Sometimes it's easy to be distracted by semantics and pedantism when you are so deep in something[1].

Remember the goal of the Parts Tracker is to produce releasable parts of high standard for LDraw. Not never released parts of a never-to-be-achieved perfect systemic standard.

Tim

[1] This is coming from a man who will spend days getting all the formatting to look just right in computational physics code while neglecting to do the coding for the intended job. I'm no innocent!

In order to model 32004b I would need a 1-6ring with a 45 inner diameter and a 51.3 outer diameter.

I'm not sure what primitive(s) I would need to do it in a efficient way. Can someone help me please.