I think it would be really nice to have a meta command to indicate the end of the official part header information (especially) but also headers in general. Just something simple like:

Hi Y'all,

Sorry for a whole pile of stupid spec q's, but...

Is there a requirement for official parts that all edges of a part be 'coated' with a line or conditional line?

I read that some programs use the presence or absence of lines to determine which mesh vertices should be smoothed across triangles, but I didn't see anything in the part authoring spec about the requirement that lines be present.

Is having lines on the edges something so basic and obvious to everyone that it didn't need to be stated? :-)

Thanks!!!
Ben

I have created an MPD file and can't import it into MLCAD. Changing the extension to LDR doesn't seem to help.

My basic problem is that I have sub-assemblies that depend on other sub-assemblies (3 levels of nesting; the main model .LDR at the top level needs to include a .MPD file which itself is composed of two LDR files). As soon as I do "Multipart->Import model" it won't let me save as LDR. :-( I have to save that sub-assembly as MPD.

I need to save as LDR so that I can import the created LDR into the main model! Hope it's clear.

Thanks for any tips, Rog.

Hi All,

For a long time I've wanted there to be an .xml version of parts.lst containing not only the part and description, but also additional meta data. When Michael posted his fine looking LDFind today I had my final motivation to do something about it. Because a good Parts.xml would make searching so much easier.

As such LDMakeList 1.0 will make Parts.lst in the usual way, but will also make Parts.xml with a very simple format. I'd like some ideas of what should and shouldn't go into this format. Right now I'm wavering on 'License' for example.

So far each entry is as follows

Attached Files

  parts.xml.ldr (Size: 1.23 MB / Downloads: 0)

I like to announce the first release of LDFind. It will be this weekend.



As Philo reported some behaviour that i could not find on my machine I need feedback how it works on your systems.

Download from website

I have just scanned our current library (approx. 10% of it )

I have found some parts that needs to be shifted to use correct BFC.

Maybe there is someone out there who has the mood to do that.

Attached Files

  NeedBFC.txt (Size: 29.47 KB / Downloads: 0)

Hi, I've resurrected an old model I designed on MLCAD and when I load it now, I find that it's massively zoomed out. I have to zoom in for ages until it appears. Would anyone be able to give me a hand in fixing the LDR file so that it is visible?

I attach the LDR file in question.

Many thanks. Rog.

Attached Files

  front_carriage.ldr (Size: 13.08 KB / Downloads: 0)

Hi Y'all,

Some official parts have origins that favor easy rotation along their hinge but make them (relatively) difficult to place. For example:

3853 (window 1x4x3) and its shutters/panes (3854, 3856)
60596 (door frame 1x4x6) and its doors (e.g. 60623, 30178c01).

I saw that one author had written a help comment into a proposed part that stated the relative offset ot place the part in its parent. Unfortunately, the comment is not machine-readable. So my idea is to make a table of relative placements that would describe where to place the child part (e.g. the door) relative to the parent (its frame) to align the hinge mechanism. Since the parts are official, it's too late to change origins (and in some cases an origin that favors assembly would have other problems) but the table could allow a 3-d editor to insert the part directly.

A few questions:

- Has anyone already done this/is there an existing system that could be leveraged? I am sure i'm not the first person to consider this.
- Would such meta data better be stashed in the part itself or kept in a side table?
- Is there interest from other app developers in having access to relative placement table?
- How to handle parts that can be connected in multiple ways (e.g. the shutter can go to the left or right of the window)?
- Does this come too close to a "connections database"?

On that last point, my view is that even if such a scheme were stop-gap in the bigger picture, it would still be useful and could be replaced with something more thorough later. "Placement" info is simple enough that it could be done now, and it's useful even for 'fixing' a small number of part placements.

Thoughts?

Hi all,

I'm thinking about supporting zipped ldraw files in LDCad without the need for users to unzip them first. This idea comes mainly from the fact my new deform functionality tends to create quite large files. These files can be compressed extremely well (1.5MB becomes a couple of K etc).

It would be almost trivial for me to implement an unzip before parsing and a zip before saving files in my editor. But I was thinking maybe other software authors would like to provide the same support.

So a semi serious public discussion about how to name/handle compressed LDRaw files might be in order. That way we could all use this.

I was thinking about using zlib (other authors could use any other zip supporting library) and simply prefixing "gz-" to the file extension, so e.g. "someBigModel.mpd" becomes "someBigModel.gz-mpd". The contents of the mpd itself stay unchanged.

Toughts?

The LDraw All-In-One-Installer 2012-03, in short AIOI, has been released.

The AIOI supports Windows XP (Home and Pro), Windows Vista (all versions) and Windows 7 (all versions). On 64-Bit Operating Systems it will install in the "Program files (x86)" folder. The Installer will NOT run on Windows 95, 98, ME, NT Ver 4, 2000, or XP below SP2.

There are currently some issues with the installation of PovRay and the registration of a file needed by Sticker Generator when installing on Windows 8.

You can download the AIOI from:

Home > Help > Get Started > LDraw All-In-One-Installer

Willy Tschager
(LDraw.org Content Manager)