> 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.
> 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.