Is there a naming convention for a "complete" Motor, i.e. with cable and plug?

LEGO shows PF-motors in their building instructions complete with cables. What would be the name of such a part? Or do you think it is better to use the PLI Substitution with an custom designed part (motor + LSYNTH cable + Plug)?

Thanks for sharing your thoughts

Gerald

How can I gather the length of a synthisized part? i.e. to use only cables with a fixed length or the flex axles?

Could not find anything in neither Willi's tutorial or any other place

Thanks

Gerald

Hello,

how can i open mpd files ? To be more specific, i added files to ldview, but i only see 1 picture. There supposed to be buildinginstructions with it, but there is only "step 1 (from 1).

Thank you,

Marcello

Hi everybody.

Currently I try to build the set 4473 and now I am missing this propellor.

I have not yet looked into LDD for this part, so maybe someone can extract that part from there.
Just looked into LDD and yes, the part is there. So maybe someone can extract that part from there .

i have search the forum but cannot find the manual to upload a subpart.
when uploading its say:
Error: Invalid Name entry 'subparts01.dat'. Entry should be 's\subparts01.dat'.

how to upload a subpart to the s\ section.

Hi Y'all,

A while ago someone pointed me at the low-detail versions of the stud primitives, which cut the polygon prism side count in half.

I just want to confirm that there is no machine-readable way to determine which files are higher or lower res versions of each other, either via a meta command or a separate index file.

I am interested in coding Bricksmith to dynamically swap between high and low res primitives to improve rendering performance without having to hard code a list of "known swaps".

cheers
Ben

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.