 | | | | | |
In lugnet.cad.dat.parts, Tore Eriksson wrote:
| |
In lugnet.cad.dat.parts, Travis Cobbs wrote:
| |
- Explicitly allow “dither” colors in official patterned/sticker parts. Right now, they are used, but we could not find anywhere in any specification where they are even mentioned. This option would essentially officially recognize the current status quo. (I’m not aware of any “dither” colors being used outside of patterns/stickers, but we don’t intend to allow that.)
|
I don’t know if I got that right. Isn’t Maersk Blue one of those part colors
most wrongfully and misleadingly labeled as a “dithered” color?
|
Two things. First of all, is Maersk Blue hard-coded into any part files? I
would expect parts that show up in Maersk Blue to have color 16 encoded in the
file, and the user to select Maersk Blue as the parts’ color when building a
model. Since we are only interested in restrictions on colors for official
parts, this wouldn’t be an issue here.
Secondly, we plan to recommend that LDConfig.ldr contain all “brick” colors,
meaning all colors that LEGO has shipped bricks in (including Maersk Blue). My
original list of options was ambiguous, but as long as a given color shows up in
LDConfig.ldr, we will be allowing it in parts, even if the color code picked
comes from the “dither” range. This will be the case no matter which of the
three options we decide upon. In other words, even if we forbid “dither” colors
from being used, colors in that range that also appear in LDConfig.ldr will
still be allowed.
| |
I repeat my opinion when it comes to defining new part color numbers for the
official LDConfig.ldr, that they should be picked from the blended
(=”dithered”) area as long as there are free numbers to choose. Thus, anyone
who hasn’t the latest LDConfig would get a fair closest existing color blend.
And, of course, no programs that support LDConfig will have any problems
replacing that blended color with the LDConfig entry! It sounds like some
preople believe that picking a number from that area would cause any problem,
but that is of course not true. Or is there something I’m unaware of?
|
What to do in LDConfig.ldr is that other half of our discussion. I can’t
remember the specifics off-hand, but we have pretty much agreed upon what to do
there. We will be releasing rules for LDConfig.ldr at the same time we enact
rules for color usage in official parts. I personally agree that new color
codes should be picked from the “dither” range where possible for maximum
backwards compatibility, but I can’t remember if this is the LSC consensus.
--Travis
| | | | | | | | | | | | | | | |
| |
|
In lugnet.cad.dat.parts, Travis Cobbs wrote:
> In lugnet.cad.dat.parts, Tore Eriksson wrote:
> > I don't know if I got that right. Isn't Maersk Blue one of those part colors
> > most wrongfully and misleadingly labeled as a "dithered" color?
>
> Two things. First of all, is Maersk Blue hard-coded into any part files? I
> would expect parts that show up in Maersk Blue to have color 16 encoded in
> the file, and the user to select Maersk Blue as the parts' color when
> building a model. Since we are only interested in restrictions on colors for
> official parts, this wouldn't be an issue here.
I didn't get it right at all, but now I think I do. It isn't an issue here and,
believe it or not, I'm cool with it. :)
> Secondly, we plan to recommend that LDConfig.ldr contain all "brick" colors,
> meaning all colors that LEGO has shipped bricks in (including Maersk Blue).
> My original list of options was ambiguous, but as long as a given color shows
> up in LDConfig.ldr, we will be allowing it in parts, even if the color code
> picked comes from the "dither" range. This will be the case no matter which
> of the three options we decide upon. In other words, even if we forbid
> "dither" colors from being used, colors in that range that also appear in
> LDConfig.ldr will still be allowed.
Good! :)
>
> What to do in LDConfig.ldr is that other half of our discussion. I can't
> remember the specifics off-hand, but we have pretty much agreed upon what to
> do there. We will be releasing rules for LDConfig.ldr at the same time we
> enact rules for color usage in official parts. I personally agree that new
> color codes should be picked from the "dither" range where possible for
> maximum backwards compatibility, but I can't remember if this is the LSC
> consensus.
>
> --Travis
I'm glad that at least I'm not alone with this opinion. :)
/T
| | | | | | |
