Hi,

This afternoon I've been looking at the cool 'unofficial parts library', they looked good on the website but when I opened them in Bricksmith I cept getting 'Bricksmith couldn't find all of the pieces in this file. The following are missing: s\xxxx.dat, s\xxx.dat', (those filenames are just an example) and realized why this was, it's because all of the file 'scripts' / contents when opened in a text editor have an '\' in them when it should be an '/', replacing all of them allows Bricksmith to find the subparts (located in the 's' directory).

Now, the problem was editing these thousands of files so I found a program called textmate ,when I went back the parts opened fine with no errors and had no changes to the file extention.

Here's how to fix this:

Download the unofficial parts library and extract the 'LDRAWUNF' directory to the bricksmith folder so you have the folders 'LDRAW' and 'LDRAWUNF' (LDRAW should already be there as it comes with bricksmith).

Find the 's' subfolder in 'LDRAWUNF'>'parts' and move it onto the desktop (make sure it is moved not just duplicated).
Download 'Textmate' then after installing. goto 'file', 'open'.
Locate the 'parts' folder in 'LDRAWUNF' and in the parts folder select all of the dat files and hit 'open'. (there should be nothing but .dat files in that folder since we moved the 's' folder).

Goto 'edit' and click 'find', then 'find in project'.

Type in the 'find' bar '\' (with no quotes) and hit 'find'.

In the 'replace' box, type in '/' (no quotes) and hit 'replace all'

Close the box and go to 'file', 'save all'.

Now go ahead and move the 's' folder back into the 'parts' folder in 'LDRAWUNF'

All or most parts should now return no errors when being opened.

***NOTE*** the 'parts' or 'p' folder containing official parts that comes with bricksmith should not be touched for this fix.

Note to mods, Im not sure what category of the Ldraw forum this should be located in.

Please vote on the proposal below. Please modify the Subject to include your name and vote, in addition to giving your vote in the text.

Quote:Each model in the OMR will consist of several files that are packaged together into a single MPD file. For sets that include instructions for multiple models, each model will have its own MPD file. Each MPD for the set will be named in the following manner:

<Set Number> - <Set Name>[ - <Sub Model Name>]

Where:
<Set Number>: The number assigned on the container of the set.
<Set Name>: The name of the set printed on the container in English.
<Sub Model Name>: This is Optional in most cases. This is required for alternate models that are detailed in instructions (e.g. the Creator theme). In this case the naming is left to the discretion of the author but should be descriptive of the model contained in the MPD.

Quote:Each model in the OMR will consist of several files that are packaged together into a single MPD file. For sets that include instructions for multiple models, each model will have its own MPD file. Each MPD for the set will be named in the following manner:

<Set Number>[-<Optional Qualifier>] - <Set Name>[ - <Sub Model Name>]

Where:
<Set Number>: The number assigned on the container of the set.
<Optional Qualifier>: Is a sequential number, starting with 2.
<Set Name>: The name of the set printed on the container in English.
<Sub Model Name>: This is Optional in most cases. This is required for alternate models that are detailed in instructions (e.g. the Creator theme). In this case the naming is left to the discretion of the author but should be descriptive of the model contained in the MPD.

The <Optional Qualifier> is not mandatory and gets added only if there is more than one set that could be assigned the same <Set Number>. The first set using a given number would be understood to never contain the qualifier however numbering should start with the oldest set and some investigation should be done in existing set databases.

Example:
6901 - Mobile Lab.mpd (Produced in 1980)
6901-2 - Space Plane.mpd (Produced in 1998)

Hello, I try the step 1 download for mac. Nothing happens. With the help link (http://www.ldraw.org/article/96), answer "not found". Small temporary outage?

This is a repost of something I just put up on Flickr. Hopefully this image works; if not, the link to Brickshelf should at least be active...



Here is something that has been bugging me for ages, and I was wondering if anyone could shed some light on it.

These images show the POV-Ray output for various rendering conditions. Three colour definitions are used - MLCAD standard, LGEO and Koyan's list. For the standard MLCAD colours, POV-Ray checks the list of pre-defined colours (I am assuming this – please correct me if wrong) and uses those, leaving everything else as “color 7” (lt grey). For example, the reddish brown and lt flesh plates are both lt grey, as these are newer colours and not on the standard list. For the modified “solid” and “24-bit” colours, POV-Ray defines each colour itself, rather than referring to a list, so every colour is included. The down side is that they do not look very realistic in POV-Ray, with the exception of the 24 bit colours (I have been using these recently).

When using LGEO, POV-Ray first checks each colour against LGEO's list and then defines that colour if it is not there. However, having done this, it goes on to associate “color 7” with those parts which have colours not on the MLCAD standard list, even though new definitions are available. Again, this can be seen for the reddish brown and lt flesh plates. The same thing happens if you use the “koyancolours” file – apparently all it does is redefine the colours on the standard list, even though it includes many more. Adding new colours to the list does not work, but reassociating existing colours to ones that are not working (e.g. changing a bizzare purple to lt flesh and calling the bizzare purple colour code) does work – the lt flesh plate is now the right colour. Now for the weird bit – if you go into the POV-Ray file and change the remaining “color 7” tags (Koyan added reddish brown to his list, so this plate is no longer an issue) to colours on the koyancolours list, which were the originally intended ones, they come out fine. The case here is the lt and dk bley, colours 71 and 72 – these do not work in standard MLCAD, LGEO or unmodified POV files for koyancolours.

In short, does anyone know why on earth this is happening, or is this a more general concern for how MLCAD does its thing?

Many thanks,

Chris

This is a proposal for changing the scoping rules for TEXMAP:

Add bolded text:

Quote:This texture will remain in effect until:

• An END is given within the current file
  
• The file in which the START is located ends
  
• A STEP command is reached
  

The texture will remain active when processing an included file unless overridden within that file.

Quote:The END command stops using the current texture and restores the previous texture to current status. This means that nested commands with START will form a stack of textures and the END command will pop those textures. However, END cannot appear in a different file from START. If an END command is given in a sub file without a START having been given in that same file, the END stops the use of a texture specified in a calling file, then that texture will be restored to use when the sub file is exitedhas no effect.

Just for backup, but also for anybody interested, I'm posting here my current MLCad parts tree setup
which I over some years now found convenient to use.
This is especially useful for me still since MLCad doesn't know of the !CATEGORY keyword yet,
and thus will not show parts in their categories initially.

I'm attaching the MLCad.grp file here to this post (rename it from MLCad.grp.txt to MLCad.grp after download),
so you can directly use it to replace your default one if desired.

Here's a textual description of the contents:

Attached Files

  MLCad.grp.txt (Size: 1.15 KB / Downloads: 5)

I first worked with Ldraw several years ago and I am now in a new computer lab and trying to configure Ldraw for my students. In the past, I downloaded a parts packet for NXT parts and copied it into the Ldraw folder. Ldraw is now installed and I am trying to get teh NXT parts to show up for my students. I copied the nxt files into the parts folders and had Ldraw scan for the parts. I found the NXT sensors - but have not found anything else. Is there something I am missing or is it the NXT parts are just scattered and require some searching.

I would love to simplify the search for my students and remove the parts lists not needed but have no idea which lists my students will not need. We have the 9797 educational sets, the NXT supplement packs and the RCX educational set.

How can I remove the trains and other unwanted lists and is there a way to make finding the nxt parts simpler for my students in their first use of Ldraw?

Thanks
Louis

Hello, is there a plant and tree model database or a tree generator?
I'm just not talented enough.

I used to built scale model kits and read a bit about military history, so no wonder these MOCs pop into my radar.

Here's my recent find:
US strategical bomber B-52H Stratofortress

I'd also like to remind about:
WW2 era Japanese battleship Yamato - superlarge!
modern Russian Kamov Ka-50 attack helicopter

Hi there,

I'm using a Mac (OSX 10.5.8) and am having some troubles.

Here's what I have done and have working so far:

1) Downloaded BrickSmith - launched it and was able to use BrickSmith to create the model.
2) Downloaded LPub (v4) - launched it but it is saying that it cannot find the parts.lst file. When I load a model, it cannot render that model "LDView Failed" error.

I checked around and it seems like I need to run mklist.exe to generate the parts.lst file, but I can't do that on a Mac (since it's an .exe file). Any other options?

Also.. I can't find some Lego parts in BrickSmith. For example, I can find the NXT brick, but I can't find any of the NXT motors or sensors (but I can find the old RCX style motors / sensors).

Any help would be GREATLY appreciated!!