While testing links in the new LDraw File Format Standards section of the web site, I noticed that every time I click on one of the links in the table of contents, it apparently reloads the page. (It definitely communicates with the site, and that communication introduces an extremely noticable delay). The same thing happens every time I hit the back button immediately after having navigated one of these in-document links.

Doing a little digging, I discovered that this is caused by the main site menu URL for the document being blahblahblah/218.html, while the table of contents links are all blahblahblah/218/#yadayada. If I point my browser directly at blahblahblah/218/, instead of blahblahblah/218.html, the problem goes away. Is there any way to use the blahblahblah/218/ version of the URL as the one from the menu, and make that the official URL, instead of the blahblahblah/218.html one?

Hi,

all articles belonging to the LDraw.org File Format Standards section have been transferred to the new CMS.

I would appreciate if someone could browse the articles under:

Home > Documentation > LDraw.org File Format Standards

and check if there are broken links (internal and external).

Many thx,

w.
(LDraw.org Content Manager)

Hi again,
another version has just been released and is available from http://sr3dbuilder.altervista.org/

No significant improvement this time, just some fixes, most around the UI.
Here is a list of changes.
Enjoy!

Sergio
________________________
Fixed
- Some issue in the standard user interface introduced with last version
- Some issues in the new experimental UI
- Selecting a brick connected to a hidden one can cause application crash or image corruption
- Some useless connections were added on some rounded parts
- Preferences about Seams and AntiAliasing quality were not saved

Changed
- Image quality should be a bit better with a little high contrast between lighted and shadowed zones
- Some changes in determining face lighting

Added
- U key shortcut to switch UI mode

well, not MY own creation, but Megx's:

http://www.themarysue.com/lego-bridge-in-germany/

There seems to be something wrong with ether 32068 or 32069 (i'm using them in set 5533), they won't fit together (latest lib).

The beam seems to be 4 units to small.

The header of 32068.dat states "reduce size 20 to 18 LDU" so that might be the cause of the problem (reduction instead of inc) ?

I've recently obtained a new computer and therefore reinstalled all my LDraw programs and library from scratch. It is a good thing to clean house now and then. However, I've run into a serious problem caused by progress. I'm very happy to see that so many unofficial parts have finally been moved to official in the many recent library updates. However, many parts have changed part numbers over the course of many updates. I have hundreds and hundreds of LDraw models archived on my computer, and I find that a great many of them are now broken. I don't mind updating them, the problem is that there is no easy way to find out what happened to an old part. When an old part doesn't load, it doesn't show up in the parts tracker and it doesn't show up in the official library either. I am left scouring the Internet trying to find out what 30039.dat was (for example) so that I can replace it with the current part. Is there any kind of database which tracks old part nnumbers when they change? This would be really useful. I've got my own table now with about 30 parts in it.

Hello all,

I was playing around (testing) in my dev versionof LDCad this weeked when I noticed this:



(You can look through the IR receiver)

In the header of 58123 BFC is enabled, so are the subparts, but then I noticed the comments in some of the subfiles ("Needs Work: inner side not modelled").

This made me think, my rendering loop is correct after all, but when I open the above little test ldr in LDView 58123 seems to be rendered without culling.

Am I missing something here? In short what's the (by authors) expected correct behavior here.

Hello everyone,

my name is David and i want to design an educational model with 9686 set (http://www.bricklink.com/catalogItem.asp?S=9686-1).

I don't be able to find any of the figures in bb278 sheet.

here it is a link to BrickLink for this sheet:  http://www.bricklink.com/catalogItem.asp?P=bb278

Anyone can help me? Any idea where can I find them?

Thanks in advance.

David

I just wanted to mention that something simply great is happening on the PT this year:
A major breakthrough in bringing down the huge backlog of parts to get out has been achieved:
the first big flush of parts happened around Christmas last year. It brought many, many parts out officially.
Then, quite quickly following, again over 1000 files were released with the next release.
And now, despite all the server problems etc., again over 800 files are Admin-certified:
http://www.ldraw.org/cgi-bin/tracker/activity.cgi
This will again bring a huge parts release with the next coming update.
The - for me - most interesting fact is that the parts waiting for Admin-certify are down to just 2 files right now
(not counting subfiles, ~ files and primitives) - see here:
http://www.ldraw.org/cgi-bin/ptlist.cgi
This can also be seen by the now dramatically shrinked portion of todos for Chris in this graph (blue portion):
http://www.ldraw.org/cgi-bin/pthist2.cgi?h=10&i=15
What I find so important about this is that I in the past found the queue of parts waiting for an Admin review
to be the bottleneck of parts releases. This no longer is true now. In fact, we as reviewers are not even able
to bring up so many parts for Admin cert as Chris "consumes" them. So the bottleneck is finally gone,
thanks to Chris' permanent and close-tracked reviews.

The sequence of the upcoming parts release together with its 2 recent predecessors marks
a true milestone in our library.

My hope is that at some point in the future, the parts tracker will only contain a handful of parts,
leading to the effect that a newly submitted part will have a much faster way through it than in the last years,
where it took eons for it to get through. With not so many old parts waiting anymore, "younger" parts
will have a better chance being seen.

Just wanted to share these thoughts with you.

I copy here a discussion between Travis and myself about sphere primitive. Question is - should we change this primitive?

Travis Cobbs Wrote:I don't think it would have mattered in this case, but please be aware that LDView's sphere primitive substitution produces a sphere with geometry significantly different from the LDraw sphere file's internal geometry. (Enable and disable primitive substitution with this file loaded and wireframe mode enabled to see what I mean.) The three "edges" of the eighth sphere that is the basic sphere primitive sub-unit are the same in LDView's version and LDraw's version, but the geometry between the edges is very different, so will produce different results when viewed with primitive substitution on vs. off if geometry is intersecting the middle of the sphere. (Note that the 48/ version of the sphere was actually produced by me using LDView's algorithm, so that one exactly matches LDView's substitution when the substitution is kicked up two notches.)

Philippe Hurbain Wrote:About sphe primitive - wouldn't it be best to change primitive to match LDView primitive substitution version? I have always been annoyed by the warped quads in present primitive. Granted, a few parts would get weird edge lines at junctions with other elements, but at least it would no longer change with primitive substitution (16x resoluton at least).