Following up with the previous topic, I would like to propose that DOS-style CRLF line-endings be officially specified as the standard output format for LDraw editors.

While I personally believe that DOS line endings are the most ridiculous line endings known to man, they're the de facto standard in LDraw and I don't think that should change. I agree with the idea to put them in the specification as a help to any future software author.

As to the input format, I believe software must support DOS line endings, and should support all line endings.

Thoughts?

Allen

Hi,

in prospect of the recent events the LDraw Steering Committee (SteerCo) has elaborated a guideline for those authors who wanna quit their PT authorship:

1. The Part Author (PA) wishing to quit should submit their intention to the Part Tracker Administration (PTAdmin) in writing via email to <parts-AT-ldraw.org>.
   
2. Following this, access rights to the Part Tracker (PT) will be removed in a timely fashion.
   
3. The PTAdmin will keep a record of the signed Contributor Agreement (CA) of the person quitting.
   
4. As the quitting PA's parts (the parts) were submitted under the terms of the CA, and thus the "copyleft" Creative Commons license, all parts submitted up to that point will be left where they are, whether that be as part of the published library, or in some state on the PT.
   
5. No changes will be made to the parts that would undermine the existing terms of the CA and associated license.
   
6. All the parts remaining on the PT will be immediately considered open for editing by anyone, under the usual provisions of the CA and associated license. Any existing reviews will be left as is.
   
7. If the PA wishes to reattain part authorship, they must apply as a new author, including signing a new CA.
   

Rectifier (now verion 1.7) has been updated to manage direct color (code courtesy of Nils Schmidt). This version also prevents creation of quads with too flat angles (see this).

Intersector (now version 1.4) uses dynamic memory allocation to manage bigger files. I corrected a bug that caused triangles to disappear. Unfortunately another bug remains, I have not found the root cause but when this occurs the message "*** problem during retriangulation ***" is displayed. Prescaling may help in this case.

Is somebody working on that? Because I saw a reserved Part Number for this.

If not, I have the template ready and could do it in the next few days.

Hi, first of all, I have to say that I'm not sure if this is the correct place to ask this, but it's the best I've found, so tell me if you think of a better place, please!

I'm trying to make a simulator for the NXT Mindstorms and I'm using the .lxf and .ldr files generated by Lego Digital Designer... but when I use "RIM WIDE W/CROSS 30x20" and export to the .ldr file format it's not present! In fact, if I make a model with only one rim I get this when I export the .ldr file:

test.ldr Wrote:0 test
0 Author: LEGO Digital Designer 4.2

Can some site admin please check if the user rights configuration of the forums is o.k.?:
I just noticed that the "Attach a file..." link only seems to be shown
in public forums, but not when you're replying in a closed forum,
I think that's an error.
For example, when I wrote this post:
http://forums.ldraw.org/showthread.php?t...98#pid3998
I noticed that the link wasn't there.
It also isn't shown when I hit "edit" to edit that post.

Admin - Due to latency problems between the 2 LDraw servers causing extremely page long load times on tag intensive posts, this tag has been disabled until a code revision can be made to account for this.

Format is:
[dat_part <partno> (unofficial|text)]
where:
<partno> is the part number with or without the ".dat". Note the "parts" folder need not be specified but the "p", "s", and "48" do.
"unofficial" forces the PT version if the part is under revision on the PT
"text" forces a text link instead of an image link

If a part image does not exist (i.e. official primitives) then it defaults to a text link.
If the part is neither official or unofficial it returns the part number as plain text.

Official Part:
image link:
[dat_part 3001]
text link:
[dat_part 3001 text]

Unofficial Part:
image link:
[dat_part 92590]
text link:
[dat_part 92590 text]

Part that is both:
official image:
[dat_part 112]
official text:
[dat_part 112 text]
unofficial image:
[dat_part 112 unofficial]
unofficial text:
[dat_part 112 unofficial text]

This part does not exist:
[dat_part 33431333s02]

So. I've got a strange LDView error. I've got a setting group for part reviewing/editing with optional lines set to show control points, and random colours used for surfaces. From the picture below it all looks great on screen. It's part 92590 and subparts.

But the moment I export to PNG you get what is on the right side of the image. And thereafter LDView shows the image like that. At a guess it's showing the optional lines only but I'm not certain about that.

Below are the unusual settings:
Random colors Y
Field of view 0.1

Edge lines Y
Conditional Lines Y
Show control points Y
High quality Y




Weird LDView bug by gambort, on Flickr

Here is a list of parts I want the most, at the moment:

The Scout Trooper Helmet, the Kaadu and the old Gungan Head

Hello all:

When using LPub for a model composed of unofficial elements, I keep getting the following error:

Runtime Error!

Program: C:\Program Files\LDView\LDView.exe

R6025
-pure virtual function call

I have no idea what this means nor any idea of how to compensate for it, but I'll add the following:

The model renders just fine through an earlier version of LPub.
When I pare the model down to a single part and the part down to a single BOX.DAT primitive, the error still occurs.

What I find most baffling/frustrating is that the earlier version handles it so easily, plowing through the apparent error without a hitch. However, that earlier version can't render torus objects in POV-Ray, which I use in inlined code for these unofficial elements.

What's causing this error? Is there a way to correct it?