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.

A while back I posted about a little curiosity I had spotted while modelling a new part. It was not much of an issue there, but today I discovered a part where the problem is much greater.

The problem is summarised as follows:

1) We model studless technic connections (eg. liftarms, pin connectors) at 18LDU wide, which is slightly too small for the real ones

2) We model technic holes at 10LDU from the top of a brick, which is slightly too low (9LDU is closer). This difference is actually large enough that connections from a system brick like 87087 to a technic brick like 6541 are forbidden in official models.

3) When studless technic connections are merged with bricks these two problems combine to make LDraw parts not match flush at the top, while real parts will be flush.

There are more parts appearing like 85943 and it might be worth coming up with a standard workaround for these parts.

In the case of 85943 it was modelled with 20LDU liftarms which I think is not ideal. Better, IMO, would be to slope down over about 5LDU at the join and then leave the rest at the 18LDU diameter.

Thoughts?

Tim

I've realised that there's a few parts that are held up by only minor changes suggested by reviewers. Since we're often open to re-editing by secondary authors link to any of these here and hopefully someone whose vote won't be lost can do something about it. eg. stud41fw.

I've noticed others in the past and made the edits but this way we can keep track of more.

Tim


PS. I'm not sure if this should remain sticky but I think for now it can be.

I would prefer not to mix LDraw and politics, but in this case, a piece of legislation threatens the very thing that holds our community together... the internet.

If SOPA and the PROTECT IP Act are passed, it would allow a third party to accuse LDraw.org of hosting copyrighted material, which would cause the entire site to be "taken down" for American users (the DNS entry for ldraw.org would no-longer resolve to where the site is hosted).

We are particularly susceptible to these bills because we are dealing with a product (LEGO) whose rights do not inherently belong to us. Note that it would not necessarily need to be The Lego Group that would initiate the takedown. Something as simple as posting an image of a MOC made by somebody else would be enough to (under the proposed legislation) warrant a takedown of the entire site!

Imagine Peeron being taken down. Imagine Brickshelf being taken down. Imagine BrickLink being taken down. Imagine Lugnet being taken down. Imagine LDraw being taken down. That is what could and most likely would happen if these bills get passed. We certainly want to avoid that!

At first glance, the bills might seem to be a good thing, claiming to address the issue of piracy and copyright infringement, this is really just the veil under which they attempt to censor the internet in the United States. I am completely morally opposed to piracy, and would support legislation which actually addresses the issue properly, however the side-effects of these bills are much too devastating.

If these bills are passed, they would most certainly have very profound adverse effects on the LDraw community (as well as other AFOL communities), which is why I urge all US citizens to take action against this legislation. If these bills get passed in the United States... similar legislation in Europe (and other places) would not be far away.

The Electronic Frontier Foundation has provided a convenient page which goes into detail about the implications of the bill, as well as provides a very simple way for you to contact your representative with a minimal amount of effort (it takes less than 60 seconds). Please... if you like LDraw, and you want it to continue to exist without any legal interference, take action and oppose this legislation!

Just hilarious - http://www.youtube.com/watch?v=oLnBM_xuRg4

more: http://www.youtube.com/results?search_qu...mini+movie

Great music, too... LEGO has done a good job here.

Happy rendering!

Mike Gallagher has found an awesome technique to create your own roads
when baseplates are not enough.

This opens a universe of possibilities.
Just wanted to share this with you.

Of course he uses LDRAW.

http://gallaghersart.com/forums/viewthread/9/

http://gallaghersart.com/forums/viewthread/11/