I have a strange problem. I have LDview installed on my work computer and it poping up with the C++ error, long after the program was closed. Last week it suddenly popped up without opening any related files. I restarted my computer and it still came up after the reboot. After closing it in Task manager it stayed away until this monday.
After loged in on the computer, it suddenly popped up with the C++ error. I found it running with 50% usage. After the second popup it was gone. First time it happen i thinked that i accsedental had clicked a lego file but not the second time.

Hello,

I'm at my wits end trying to figure out what is going on. I'm having errors with the latest 2013_1 partslist file update. I've gone as far as uninstalling EVERY ldraw file, part, and AI and reinstalled from scratch...same problem. I've exported the file from MLCad to POVRay via LDView with LGEO .xml reference. If I don't allow primitive substitution, it doesn't error, but this makes for much grainier surfaces too.

The error I get is in "LDX_s_slash_86500s01_dot_dat_in_part" definition, and specifically, it is complaining about an undefined "LDX_48_slash_1_dash_12ri38_dot_dat_in_part". If I comment this out to see if that is all, it seems there are MULTIPLE issues with the *ri.dat includes???

Help!?!?

i noticed that part s\55706s01 is on the PT for quite some time.
last entry: At Tue Jun 30 21:20:02 2009, the following review was posted:

if its alright with (mikeheide) i could do the remodelling.
i have looked it over and there are more then 60 gaps.
give or take about a month of work. ;-)

As some of you may have seen, I recently added some underside stud fillet primitives (Here is one such file, where discussion has occurred). Some are wondering whether these parts should exist, and if so, where they should be located (P or S). Here is the thread I promised with my arguments.

The Problem (As I See It):
There are a number of parts in our library which have underside fillets. I recently uploaded some new 4xM and 8xM parts, but more exist. There are more as well. However, there is actually a bit of variety to them. Some are 2 ldu in width, while others (like the ones I worked on) are 3 ldu in width. There are also some medium height ones as well as ones which are full length except at the edges where they are medium height. Some are detailed while others are pretty basic.

Here's a picture which shows some of that variety:


However, there is currently no system for naming or re-using these parts. In fact, most of relevent parts are located in the S directory, and I found no less than 3 sets of these, two of which could probably be combined:
- 6161.dat and 6162.dat use s/6161s01.dat and s/6161s02.dat
- 30072.dat uses s/30072s01.dat and s/30072s02.dat
- 47116.dat uses s/47116s02-05.dat (4 files)

And the question becomes, the next time LEGO releases a new large Brick, will the person who creates the part be able to find and use the correct subparts/primitives for this? Will they simply create another set for their given part? How is one expected to know these parts even exist when there is no mention of them on the primitive reference page?

Why not just put these parts in the S folder?
Because it makes re-using them harder, especially for newer authors who may not know they exist. Really, the S folder should be for part specific subparts which don't and probably never will have any use elsewhere. The P folder is for primitives which either can be used for many parts, or have the potential to be used by many parts.

The Solution (As I See It):
I believe we need to create a new set primitives for underside fillets. When I created mine, I used stud naming convention based on an assumption that later proved to be false. And as Chris has pointed out, these are much more than studs. As such, I believe a new name should be used, and I'm currently favoring "Fillet" although I'm open to suggestions on this. However, assuming we used "Fillet", the naming scheme would proceed as such:

FilletS[h][d]-[optional-identifier].dat
where
S is the width of fillets in ldu. Currently both 2 and 3 ldu width fillets exist, and it leaves the option for further sizes should they come along.
h is used for half-height fillets (I believe 33230.dat on the PT could use these).
d is used for detailed parts (like the ones I currently have on the PT).
optional-identifiers can be used for different variants based on wall collisions. A meaningful naming convention is preferred.


So that's it. I don't think I'm that far out of line on this, but you can let me know what you think.

I've enable the use of user avatars. You can upload a 100px by 100px image of your choices at Control Center -> Avatars. As always, avatars must conform to the usage guidelines (i.e. be in good taste). You can also turn off the viewing of avatars at the same location list above.

Side notes:
- I think 100 by 100 might be to big for my taste but I go with it for now.
- Don't ask me to enable gif images. I turned them off on purpose to preclude animated images.

Hello,
Does someone know, if it's possible, how to display an MLCad arrow only in one step and to hide it in the following steps ?

Thanks in advance for your help,
Fabrice

Hi,

I just noticed that old articles are no longer properly found when searching for keywords in them.
In my case, I was looking for the old "which color to use for silver" thread.

Reason was that the default of the search function currently adds a constraint
"only search posts which are not older than 1 year".

I find this silent default addition confusing and would like to ask to drop it.

A user wanting to add a time constraint can still do that in the "advanced search" function.

- Steffen

The LDraw Parts Tracker has been updated to allow up to 200 characters in the line 1 part description.

There may be some knock-on impact on the display of the Parts List and Activity pages and I'll deal with those if they become a problem. If anyone sees any other problems, please let me know by posting here.

I think I'm misunderstanding something about the transform matrix for line type 1. Long story short, I've written a program to convert LDRAW files into something that threejs (3D library for JavaScript) can use, but I'm getting surfaces with the wrong normals, and it's not obvious what's going on.

So take a look at this line in p/stud.dat:

http://www.ldraw.org/article/512.html

' Wrote:Currently, all official parts are issued with upper-case only names.