Original Grey Technic motor from 1977: 6216a

[Jens Bauer]

-I've noticed that LDView has different preference sets - can these be used for having for instance two different part locations ?

No. The LDraw Directory setting is global (i.e., not connected to a preference set). If you look at the last paragraph of the "Specifying Preferences" section of LDView's help, you will see an explanation of what the "Global?" column in the preference sets list immediately following means. And if you look at the LDrawDir setting in that list, you will see that it is global.

Of course - this makes sense; it would be silly if switching 'view preferences' and the parts were changed.

[Jens Bauer]

One static, complete housing (without the axle) + one user adaptable axle.
motor = body (complete (casing+core)) + axle (complete (steel axle + plastic axle))

Though I earlier mentioned that this was a good idea, a thought just came to me...

Wouldn't it be good to have (likely in addition to the above), a completely assembled motor of each variant, so that ...
1: Those who do not need to rotate the axle, can just grab the motor and go.
2: When listing on for instance BrickLink, all the valid variants will be available and the motor will be shown as a complete unit.

[Steffen]

the assembly you want is already present:

http://www.ldraw.org/cgi-bin/ptdetail.cg.../6216a.dat

similar ones for the variants should be created analogously

[Jens Bauer]

the assembly you want is already present:

http://www.ldraw.org/cgi-bin/ptdetail.cg.../6216a.dat

similar ones for the variants should be created analogously

I created 6216a - it was actually my first submission...

The reason I posted the above, was that Magnus suggested we separated the axles from the main body, so we'd see a complete motor housing without the axle. This has the advantage that you can rotate the axle in any position you wish (to make teeth of gears fit nicely).

... But I think I understand what you're saying ... eg. having a fully assembled motor of each variant.
These motors use the "body assemblies" (which Magnus suggest being the main housing + the back) and then you can pick which axle you want to use, plus you can rotate the axle as you wish.
Most axle/body combinations would be valid anyway.

[Magnus Forsberg]

One static, complete housing (without the axle) + one user adaptable axle.
motor = body (complete (casing+core)) + axle (complete (steel axle + plastic axle))

Now that we have renumbered the parts, I can maybe be more clear.

6216m is the old complete assembly.
u9372c01 is a file with all the static parts. It should contain a body(u9372), a back(u9373) and all other parts we want to create.
u9374c01 is a file with all the rotating parts. It should contain a steel axle(u9374), a plastic axle(u9375), and maybe the rotor from inside the electric motor.
6216m.dat should only contain u9372c01.dat and u9374c01.dat

6216a is your new complete assembly
u9372c02 should contain the same body(u9372), and the new back(u9376) and all other parts you want to create.
u9374c02 should contain the same steel axle(u9374) and the new plastic axle(u9377), and maybe the rotor from inside the electric motor.
6216a.dat should only contain u9372c02.dat and u9374c02.dat, since it is visually different from 6216m

6228a is Steffens 12V motor.
It today contains the same files as 6216m, u9372c01.dat and u9374c01.dat. Is that correct? Isn't there any visual difference between them? Then it is correct.

[Steffen]

I think what Magnus wanted was to make the hierarchy of combined parts easily usable:

topmost of course is a complete motor assembly.
it should be composed of 2 things:
- a complete motor housing
- an axle combination of metal+plastic axle portion

the complete motor housing then again would be composed of
- the front
- the back

and the axle combination mentioned above of course of
- the metal portion
- the plastic portion

This will make this part most useful for animators etc.
and at the same time allow to use the complete motor easily in inventories etc.

[Magnus Forsberg]

Yes.
That's correct

[Jens Bauer]

I think what Magnus wanted was to make the hierarchy of combined parts easily usable:

OK, I wasn't completely sure earlier - but from reading the latest post from Magnus it's much more clear to me and I definitely agree.
-That's the right way to go.

I intend to find all the different variants of the motor I can.
The plan here, is to make a table that shows valid combinations of axles, back and "4V" text on the back.
This means I'll need to purchase a few more (I know there are at least two variants of the 12V motor, one has the "1977 axle" and two prong holes and no middle pin hole, while another has the newer "1982" axle - but I do not yet know if it has the middle pin hole.
I do not know either if an 'arrow variant' exists of the 12V motor.

Thus the only visual difference between the 12V and the 4.5V motor would probably be the color.

[Jens Bauer]

Now that we have renumbered the parts, I can maybe be more clear.

I follow you completely now, yes - and I definitely agree.

6228a is Steffens 12V motor.
{snip} ... Isn't there any visual difference between them?

I think that the 12V motor has the same physical shape as the 4.5V motor (except from the "4V" text on some variants of the back).
Thus I think it'd be possible to leave the colour 'user configurable' and then just choose the motor's shape.
But I can also see why it would be desirable to make a 'harcoded' colour in the final 12V and the final 4.5V motor, since that would give the particular part the correct look.
(If someone would like to have a yellow motor, it's still possible to use the 'uncolored assembly' for that).

[Steffen]

> Thus I think it'd be possible to leave the colour 'user configurable'
> But I can also see why it would be desirable to make a 'harcoded' colour in the final 12V and the final 4.5V motor, since that would give the particular part the correct look.

No. The color 16 is one of the key elements of our library.
Usually all our elements use that color.
So the 4V and the 12V motor should both go onto the PT with color 16 and not hardcoded grey or black.

Opposed to that, there is something called a "physical color shortcut":
if we know that a specific part number refers to a specific part in a specific color only (!)
then we can add an additional file which hardcodes the color (and of course, inside uses the color 16 part).
Such a file is called "physical color shortcut".
Only those files have a hardcoded color.

See for example this one
http://www.ldraw.org/cgi-bin/ptdetail.cg...109601.dat

Physical color shortcuts do have
- usually the color in the part title at the end in square brackets, for example "[Green]"
- have their title start with an underscore "_" to easily recognize them
- carry a specific part type in their header, either "0 !LDRAW_ORG Unofficial_Part Physical_Colour" (when it is a single part) or "0 !LDRAW_ORG Unofficial_Shortcut Physical_Colour" (when it is an assemby of parts)

If you _really_ want to create such physical color shortcuts for the 4v and 12v motors, go ahead,
but usually that is not really helpful, because the color 16 versions normally suffice and are more versatile.
Physical color shortcuts or parts only make sense when you know the exact LEGO number for them.
Then they have a right to exist (for example for creating part inventories). Otherwise the color 16 elements completely suffice.
Color 16 is the key and core element of our library, making it as versatile as it is.
Our library does _not_ aim to hardcode colors for parts to make them "realistic".
Instead: Our library aims to offer every part in every possible color. That is only possible by using color 16.
It is an invention by James Jessiman, carried over up to today.

[Steffen]

I have created a new Wiki article

https://wiki.ldraw.org/wiki/Physical_Color_Part

[Jens Bauer]

I have created a new Wiki article

https://wiki.ldraw.org/wiki/Physical_Color_Part

Actually that was what I had in mind - eg. only hardcoding at the very 'top' level.
-So that 's the job of a Physical Color Part.

I wish I knew how BrickLink make their inventory, because I think it would be possible to "suggest" a color or a list of colors.
This could be done by adding an optional extension.
Thus it would not be necessary to add support for this in any existing applications, and it would not be necessary to have multiple files.
-Does that sound completely off ?

[Steffen]

Files already allow to specify a default "suggested color".
The syntax for that is (historically....):

0 !CMDLINE -c0

The number after the "-c" is the color number suggested.

For the black 12V motor that would be black (as above).
For the 4.5V motor that would be classic light grey, i.e.

0 !CMDLINE -c7

This is standard LDRAW syntax.

Bricklink just would need to understand/parse that...

[Jens Bauer]

Files already allow to specify a default "suggested color".

Bricklink just would need to understand/parse that...

That's great! I think it would be best to use that; I think this would cover all the needs.
Is it possible to specify more than one colour, in case a part comes in only - say red, black and yellow ?
(or perhaps by using multiple lines ?)

[Jens Bauer]

I've spent some time on a 4V badge. It's not completely ready yet and before I submit it, I'd like to ask what kind of file I should submit it as.

The badge is made so it can be added "on top of" u9373 or u9376.

  4v-badge.png (Size: 2.83 KB / Downloads: 51)

The badge does not (yet) use any file-references.
There are no T-junctions.
I've taken care to use quads whenever possible, thus instead of using two triangles, I've used one quad.
As far as I remember, this results in only a single triangle.

There's a slight difference in the badge's position, depending on which back is used.

  6216c.png (Size: 3.71 KB / Downloads: 51)
  6216d.png (Size: 4.09 KB / Downloads: 51)

Note: On the real-world motor, the edge of the badge is slightly modified by the hole.
I've made cond-lines on the outer edges, but not yet inside the two letters.


My question is:
Should the badge be a primitive, subpart or a part starting with u937x (like u9378) ?

[Steffen]

I think in this case a subpart is the way to go.
Subparts can be shared between different parts, although here I do not see that this one will be re-used somewhere.

[Magnus Forsberg]

Yes,
this is a subpart, and the name could be s\u9373s02.dat

[Jens Bauer]

Yes,
this is a subpart, and the name could be s\u9373s02.dat

Thank you both Steffen and Magnus. I'll name of this part as you mention.
Today I just received my first 12V motor - and this one has a 12V badge, so I'll be making a 12V badge too.
I'd then expect that to be named s\u9373s03.dat, right ?