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!!

When I copied the LSC Summary to the new site I didn't care much about the content. Preparing the LSC summary for 2011/2012 I came across the list at the bottom:

* Updating category list
* Updating the policies for part votes
* Reference parser for LDraw 1.0 spec files
* An XML version of the specs
* Number that has to be used for Sticker
* Define rules for second Author

Would you agree that Reference parser for LDraw 1.0 spec files and Number that has to be used for Sticker can now be deleted?

w.

Hi folks,

Once more we are rather late with the nominations/election process...

The LDraw.org Standards Committee (LSC) is responsible for maintaining semi-regular internal discussions on pending file format issues, the overall progress of the LDraw file format and new or proposed developments made by different LDraw-based software authors. They adopt new official standards by voting on them, and publish documentation on LDraw.org following such a decision. The LSC has documented and will document past, current and future LDraw File Formats.

With revision 1.5 of the LSC Charter the number of seats is restricted to 4 since one seat is reserved for a current LDraw Library Administrator.

To be eligible for LSC membership, per the LSC Charter you must fulfil at least one of the following:

* Authored at least two LDraw parts subsequently released in an Official LDraw.org Parts Update
* Served as a reviewer on the Parts Tracker through at least 2 official parts updates, and posted at least 5 reviews in at least two updates since their initial participation
* Authored a software program that is compliant with either the LDraw 1.0.2 specs or another spec published by the LSC
* Petition for nomination as an LSC candidate approved by 2 current LSC members
* Petition for nomination as an LSC candidate made to the LSC by at least 5 others eligible to be LSC candidates

People can either self-nominate or nominate someone else. When nominating, please reference the person’s eligibility from the list above. For the LSC there is non need that another member of the community seconds the nomination.

Nominations MUST be posted in direct reply to this post to be counted, and must be online by 12:00 PM GMT October 14.

Voting for the elections will begin October 17, and end October 31. The LSC will officially change over on November 15th, giving time to transition newly elected members into the committee.

Only LDraw organization members are permitted to vote in this poll. Since the list of the LDraw organization members vanished into thin air when the old Postnuke CMS went down we will figure out how to handle the election.

Willy Tschager
On behalf of the LDraw.org Steering Committee