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.

I trying to create some part pictures with a batch file i found on holly-wood.it
This is my second attept and it got a bit better. First i did not get any result but now i got a few pictures before it poped up with an old friend "Ldview need to close". This on my best computer (12 GB memory 3,2 quad core Intel running win 7 64 bit, ATI radon HD 68xx ) with the setting in Ldview on memory usage to low.
The batch was all parts from 3001.dat to 3089.dat. Since i got the same problem with Ldview need to close on my first attemt also, so i shorted the number off parts it needed to process. When it had processed 3004pt6.dat it stopped with the message and pressing cansel let it go on but did not create any pictures and it poped up on and on.

Hello.
Is anybody working on this part? If not, then i am trying to improve this part.
32489

im just figuring out how to build things and keeping how to build as a guide line.
Just finished a 1*1 block and just showing my first creation. always start something small and simple before going for a complex one. can anyone add comment and know how to get rid of:
0 ROTATION CENTER 0 0 0 1 "Custom"
0 ROTATION CONFIG 0 0

it keeps getting there after i save in MLCad.

Attached Files

  blokje.dat (Size: 569 bytes / Downloads: 0)