This part is already existing- my question is if there where two version of this part?
http://www.bricklink.com/catalogItem.asp?P=3433

In an old 70s set there is this part combined with 828 Tractor Chassis Excavator Arm, Large (828.DAT) and all fit fine with the Ldraw parts.
http://www.bricklink.com/catalogItemInv.asp?S=378-1

But this part was also combined with 3314 Excavator Arm 2 x 6 x 2 (e.g. see:http://www.bricklink.com/catalogItemInv.asp?S=6630-1) and there 3433.DAT and 3314.DAT have a missfit. To be more precise the connection seems to have a to small radius.

The best is somebody would take a close look on both combination.
Has somebody all of these parts I'm talking about? - The real thin could solve the problem....

i have followed the tutorial on the ldraw page, containing the information on how to add parts to my library! but i seem to have none of my parts taht i have tried to add in my mlcad library!

i would appreciate the help, thanks!

I just downloaded the latest LDConfig.ldr from http://www.ldraw.org/library/official/LDConfig.ldr
Its header reads:
0 !LDRAW_ORG Configuration UPDATE 2011-06-03

But I already have a copy of LDConfig.ldr, and its header reads:
0 !LDRAW_ORG Configuration UPDATE 2010-06-19

This is supposed to be newer, but in the currently official but older(?), there are four more colours compared to the one I already have on my hard drive.

83 Metallic_Black VALUE #1A2831 EDGE #000000 METAL
87 Metallic_Dark_Gray VALUE #6D6E5C EDGE #5D5B53 METAL
321 Dark_Azure VALUE #078BC9 EDGE #088DCD
323 Light_Aqua VALUE #ADC3C0 EDGE #AFC9C2

What is this file dated 2011-06-19? I don't know where it comes from.
And are those four colours official standard? (I guess so since they are there in the ufficial version.)

/Tore

I wouldn't complain so much about every new step in the LDraw format evolution, if it wasn't that I'm 100% depending on good old L3Lab. There is absolutely no viewer or editor that comes remotely close to its speed and its resource economy. Sorry, Roland's new editor included.

But L3Lab doesn't support colours in "the forbidden zone" as I call it. This is a growing problem for me.
And L3Lab doesn't support space characters in file references either.
And almost every change in the LDraw file specs is done without the least consideration to programs like L3Lab.

I would of course compile a fast and frugal renderer myself if only I had the programming skills to do it, but that's impossible. I'm not even close to that.

Apparantly, it seems to me all focus is on nifty details and impressive effects when it comes to viewers made today. But if it was possible eleven years ago to make an LDraw viewer that still is able to produce fast renderings, wouldn't it be possible to make the same today? And support for LDConfig and the latest LDraw file specs shouldn't slow down things noticable, should it?

If somebody could produce such a viewer, I will (most likely) no longer protest against the other LDraw programs and utilities we leave behind as we "develop" (hmm?) the LDraw standard. But like I said, I still see no real alternative to L3Lab when making huge LDraw models.

/Tore

Since yesterday I've seem to gotten moderator privileges in the LSC section, I think this is by mistake cause this wasn't so during the last committee.

Travis Cobbs Wrote:
-------------------------------------------------------
> Michael Heidemann pointed out that the newly created OMR spec requires that filenames contain spaces,
> while the pre-existing LDraw 1.0.0 spec strongly discourages spaces or tabs in filenames.
> He (quite rightly, in my opinion) felt that this was inconsistent.
>
> So, the way I see it, we have three choices:
>
> 1. Ignore the problem.
> 2. Remove the discouragement text from the LDraw standard.
> 3. Change the OMR standard so that the filenames don't include spaces.
>
>
> My vote is to do go with option 2, at least for spaces.

I very strongly disagree. The space character is the way LDraw separates arguments.

Before taking such a giant leap in the LDraw evolution to accept spaces in file names (if so only in OMR MPD's) has anyone ever considered the consequences? How many of our programs and utilities in use will be rendered useless by this reform? Just because maybe noone in the LSC is using them doesn't mean that noone else uses and needs them.

And what if a space character is accidently placed at the end of a type one line, invisible for us humans but how will various softwares handle it? Is "3001.dat " equal to "3001.dat"? And I have this habit of normally add an extra space before the file reference, in order to make it easier to read. Will that lead to a reference to the non-existing " 3001.dat"?

/Tore

I am a guy making LEGO CGI films and every time when i tried my ldraw file to Blender 3D It fails. I've tried every method :

1. Download the LDraw import Python script for Blender from http://web.tiscali.it/ALV/blender/ but It didn't work niether 2.5 and 2.4 version It just have weird dots where the bricks should be.

2. I used leocad to make LDraw files to 3ds file. It worked but LEOCad didn't have that much of an color pallet that MLCad has. All the color that leocad didn't have just turned to black and it was just chaotic to fix every color close to what I anticipated.

3. It turns out that LDview had 3ds export script and I was delighted of it. However when I tried to import in Blender it won't let me do it. Blender stops functioning and responding.

Furious of these bugs and glitches I threw my mouse and it 's broken. Would somebody help me please!!!
By the way Ldraw.org, please put WORKING 3ds export format in MLCad and LDview. Please I beg you!!!!!!!

If anyone has a solution or has simillar problems please answer this message NOW PLEASE!!!!!!!!

It would be nice if any one could take on this one:
http://www.bricklink.com/catalogItem.asp?P=6158

There is a LDD part shape existing.....

Whilst building the Super Star Destroyer, a thought occurred to me: we have no way of specifying what faces of a brick (if any) required the slope texture. I see 2 solutions:

• Use the existing !COLOUR specification to set a new main color for linetypes that need a slope texture. The disadvantage to this being that it would break MLCad. Yet another reason why Micheal should open source the program.
  
• Make a new meta, something like !SLOPE_TEXTURE, that would go before the linetypes that need slope texture.
  

Looking for an LDRAW model for the new 92438: 8x16 plate. Unofficial or in progress is fine. Anyone got one?
Thanks!
-Bill