Updated LDConfig.ldr file

[Willy Tschager]

Guys,

as a follow up to:

https://forums.ldraw.org/thread-23341.html
https://forums.ldraw.org/thread-22739.html

here is an update of the color file with a rearrangement of some RGBs, LEGO ID as well as new rubber colors in the 10000 range:


  LDConfig.ldr (Size: 30.94 KB / Downloads: 69)

Have a look and let me know.

w.

[Jaco van der Molen]

Guys,

as a follow up to:

https://forums.ldraw.org/thread-23341.html
https://forums.ldraw.org/thread-22739.html

here is an update of the color file with a rearrangement of some RGBs, LEGO ID as well as new rubber colors in the 10000 range:

Have a look and let me know.

w.

Thanks. Some colors indeed look better!

[Steffen]

Hi, thanks!
I have some questions:

(1)
why is now LDRAW color "0 !COLOUR Fabuland_Brown" associated with LEGO color "4 - Brick Red"? - this seems wrong to me


(2)
Philo/Willy, can you give an example part where the new color "Fabuland_Orange" applies to?
I would like to update the required Fabuland figure assemblies accordingly using the new color

(3)
the CR/LF is missing in the last line of the ldconfig.ldr file posted here

[Steffen]

here is a summary of the differences:

changed RGB codes for the following LDRAW colors:
- Tan (19)
- Magenta (26)
- Flesh (92)
- Earth_Orange (366)
- Fabuland_Brown (450)

newly added LDRAW colors:
- Coral (353)
- Light_Orange_Brown (507)
- Fabuland_Red (508)
- Fabuland_Orange (509)
- Rubber_Green (10002)
- Rubber_Magenta (10026)
- Rubber_Lavender (10031)
- Rubber_Reddish_Brown (10070)
- Rubber_Bright_Light_Yellow (10226)
- Rubber_Dark_Brown (10308)
- Rubber_Dark_Red (10320)
- Rubber_Dark_Azure (10321)
- Rubber_Medium_Azure (10322)
- Rubber_Light_Aqua (10323)
- Rubber_Dark_Orange (10484)

modified associated LEGO Color ID of
- Salmon (12)
- Fabuland_Brown (450) -----------> THIS IS PROBABLY AN ERROR, SEE SEPARTE POST
- Chrome_Gold (334)
- Chrome_Silver (383)
- Metallic_Silver (80)
- Metallic_Green (81)
- Metallic_Gold (82)
- Metallic_Dark_Grey (87)

[Magnus Forsberg]

This post on New Elementary was the reference when we reordered some of the values.

http://www.newelementary.com/2019/05/col...theme.html

I'll take a closer, and more focused, look at the difference at the end of this week. Don't have the time now...

[Philippe Hurbain]

This post on New Elementary was the reference when we reordered some of the values.
http://www.newelementary.com/2019/05/col...theme.html
I'll take a closer, and more focused, look at the difference at the end of this week. Don't have the time now...

A color we are still missing from this chart is 14/Pastel Green (used in Fabuland crocodile, and also several Duplo parts such as a "famous" shower head). Bricklink mixes this colour with lime, though the colour itself is significantly less yellowish. If we don't create a new colour, I propose at least to change "// LEGOID 119 - Bright Yellowish Green" to "// LEGOID 119 / 14 - Bright Yellowish Green / Pastel Green". But the crocodile would clearly benefit from a better color hue...


  lime.jpg (Size: 34.47 KB / Downloads: 771)
Scan of pastel green Duplo part next to lime tiles. Bottom lime is ldconfig lime color. Measured color: #ace35e

[Magnus Forsberg]

But the crocodile would clearly benefit from a better color hue...

Scan of pastel green Duplo part next to lime tiles. Bottom lime is ldconfig lime color. Measured color: #ace35e

Yes, I agree, we should add Pastell Green to the chart. I don't like the yellowish croc....

@Steffen.
Any more comments on the change for Fabuland brown?

Could you create a list of all the shortcuts/files using code 366 and 450 ?
I want to understand how "big" this isuue is.

[Jaco van der Molen]

Guys,

as a follow up to:

https://forums.ldraw.org/thread-23341.html
https://forums.ldraw.org/thread-22739.html

here is an update of the color file with a rearrangement of some RGBs, LEGO ID as well as new rubber colors in the 10000 range:

Have a look and let me know.

w.

I am not happy with color LDraw color 29 Bright Pink - LEGO color 222 Light Purple.
Medium Dark Pink comes visually closer to this IMHO.
Perhaps we can look into this by taking some measurements with a real brick?

[Willy Tschager]

A color we are still missing from this chart is 14/Pastel Green (used in Fabuland crocodile, and also several Duplo parts such as a "famous" shower head). Bricklink mixes this colour with lime, though the colour itself is significantly less yellowish. If we don't create a new colour, I propose at least to change "// LEGOID 119 - Bright Yellowish Green" to "// LEGOID 119 / 14 - Bright Yellowish Green / Pastel Green". But the crocodile would clearly benefit from a better color hue...


Scan of pastel green Duplo part next to lime tiles. Bottom lime is ldconfig lime color. Measured color: #ace35e

So this would become?

0                              // LEGOID  14 - Pastel Green

0 !COLOUR Fabuland_Pastel_Green                                       CODE 510   VALUE #ACE35E   EDGE #333333

w.

[Willy Tschager]

Here's also the picture I took in Billund of all the rubber parts I got my hands on:

   

Please compare with the 10000 range we added (not considering the shades of dark brown as they are to subtle).

w.

[Philippe Hurbain]

So this would become?

0                              // LEGOID  14 - Pastel Green

0 !COLOUR Fabuland_Pastel_Green                                       CODE 510   VALUE #ACE35E   EDGE #333333

w.

Seems fine...

[Philippe Hurbain]

Here's also the picture I took in Billund of all the rubber parts I got my hands on:
Please compare with the 10000 range we added (not considering the shades of dark brown as they are to subtle).

I tried to match every part with existing color. The only that doesn't match is this one, missing a medium lavender rubber color:

[Willy Tschager]

Here's the new file:


  LDConfig.ldr (Size: 31.24 KB / Downloads: 14)

Changes are:

Added Fabuland_Pastel_Green
Added Rubber_Medium_Lavender

Hopefully it comes with a working <CR>

w.

[Willy Tschager]

I am not happy with color LDraw color 29 Bright Pink - LEGO color 222 Light Purple.
Medium Dark Pink comes visually closer to this IMHO.
Perhaps we can look into this by taking some measurements with a real brick?

This is not negotiable as it is tight to BL's color name. What I can do for you is using Ryan Howerter's RGB

w.

[Lasse Deleuran]

Do the new colors in the 10000 range work well with MLCad? It provides a big scrollable page with the colors for selection.

[Orion Pobursky]

Do the new colors in the 10000 range work well with MLCad? It provides a big scrollable page with the colors for selection.

You can manually type in the color if that’s what you’re asking.

[Philippe Hurbain]

Do the new colors in the 10000 range work well with MLCad? It provides a big scrollable page with the colors for selection.

MLCad? what's that???

More seriously, no, it doesn't work with MLCad. Any color > 511 is supposed to be a custom color and appears grey.
LeoCAD and LDView work fine.

There is also a little issue with LDCad: on the color wheel, colors > 1023 are displayed in hex.

[Orion Pobursky]

MLCad? what's that???

More seriously, no, it doesn't work with MLCad. Any color > 511 is supposed to be a custom color and appears grey.
LeoCAD and LDView work fine.

There is also a little issue with LDCad: on the color wheel, colors > 1023 are displayed in hex.

I pulled 10000 out of thin air and Willy used it. We could just as easily use 900+

[Philippe Hurbain]

I pulled 10000 out of thin air and Willy used it.

...and it seemed fine to me too. But...

We could just as easily use 900+

Anything >511 causes problems with MLCad.
Now the question is: is this that important? these rubber colors are fairly uncommon, and we could easily decide that they are not supported in MLCad.

[Magnus Forsberg]

Anything >511 causes problems with MLCad.
Now the question is: is this that important? these rubber colors are fairly uncommon, and we could easily decide that they are not supported in MLCad.

I think we should softly, but firmly, nudge the users into using modern software.
But, if there's a problem in LDCad, we should pick another number.

[Orion Pobursky]

...and it seemed fine to me too. But...

Anything >511 causes problems with MLCad.
Now the question is: is this that important? these rubber colors are fairly uncommon, and we could easily decide that they are not supported in MLCad.

Supporting MLCad quirks is not important to me personally. If Micheal wants his program to continue to be used (and endorsed by LDraw) then he needs to either update it or open source it.

[Philippe Hurbain]

But, if there's a problem in LDCad, we should pick another number.

This is just a minor display problem, that occurs only in color wheel. Displayed color and generated LDraw code are correct, and you can key in decimal color code, so imho it's not really an issue (and it could probably be fixed in 1.6c)

[Jaco van der Molen]

I think we should softly, but firmly, nudge the users into using modern software.

Totally agreed on this!

[Roland Melkert]

There is also a little issue with LDCad: on the color wheel, colors > 1023 are displayed in hex.

I could change it to be >=0x02000000  (rgb coded colors)

Not sure why I chose 1024, maybe to be forwards compatible or something. Guess that backfired

[Steffen]

Sorry, but I disagree.

If there was some fact that forces us to break MLCad
then I would agree.

But here we could easily choose numbers that still work.

So we should choose them.

Is there any reason we cannot?

[Orion Pobursky]

Sorry, but I disagree.

If there was some fact that forces us to break MLCad
then I would agree.

But here we could easily choose numbers that still work.

So we should choose them.

Is there any reason we cannot?

Aside from my feeling expressed in my other post, LEGO already has numbers in the 3-400s. Restricting to 512 increases the chance of overlap.

[Eugen]

Do the new colors in the 10000 range work well with MLCad? It provides a big scrollable page with the colors for selection.

LeoCAD also can't handle LDConfig 2019 colours with ID larger than CODE 512.

• https://github.com/leozide/leocad/issues/349

UPD: Seems like LeoCAD could import new "LDConfig.ldr" placed in "Custom parts library" folder, where LDraw parts stored in un-zipped form.


But LeoCAD CAN'T import "ldconfig.ldr" placed in same folder where ZIP of "Custom parts library" stored.

• https://github.com/leozide/leocad/issues/359

Hope, Leonardo Zide could fix it soon.

[Philippe Hurbain]

LeoCAD also can't handle LDConfig 2019 colours with ID larger than CODE 512.

• https://github.com/leozide/leocad/issues/349
  

Hope, Leonardo Zide could fix it soon.

Mmhhh.... seems to work perfectly here (Windows version 17.07)

[Eugen]

LeoCAD and LDView work fine.

LeoCAD has some issue

• https://forums.ldraw.org/thread-23434-po...l#pid32593

[Eugen]

Mmhhh.... seems to work perfectly here (Windows version 17.07)

Well, could you describe how you add 2019 version of LDConfig.ldr to LeoCAD 17.07 on Windows?

Also, could you reproduce it with latest nightly build of LeoCAD?

• https://github.com/leozide/leocad/releas...continuous
  

FTR, I tested it with LeoCAD nightly build under Linux — and it CAN'T import colors from 2019 version of LDConfig.ldr (I renamed it to ldconfig.ldr according LeoCAD behavior for import 3rd-party LDConfig files):

• https://github.com/leozide/leocad/blob/m...y.cpp#L325
  

[Philippe Hurbain]

Well, could you describe how you add 2019 version of LDConfig.ldr to LeoCAD 17.07 on Windows?

I did nothing, just updated the ldconfig.ldr in my LDraw folder (I use a plain LDraw library, not the zipped one provided with LeoCAD (view -> preference -> custom library)).

Also, could you reproduce it with latest nightly build of LeoCAD?

• https://github.com/leozide/leocad/releas...continuous
  

No I can't install it. It uses a DLL missing from my ageing system (tried to install it in the past, but failed, known problem).

[Eugen]

No I can't install it. It uses a DLL missing from my ageing system (tried to install it in the past, but failed, known problem).

Could you link related issue? Or if this not reported yet, please, create one.

• https://github.com/leozide/leocad/issues

[Philippe Hurbain]

Could you link related issue? Or if this not reported yet, please, create one.

• https://github.com/leozide/leocad/issues
  

Well, technically it's not a problem with LeoCAD but with my system (I do have the same problem when I try to install other programs). The DLL is api-ms-win-crt-runtime-l1-1-0.dll

[Roland Melkert]

Well, technically it's not a problem with LeoCAD but with my system (I do have the same problem when I try to install other programs). The DLL is api-ms-win-crt-runtime-l1-1-0.dll

That's a visual c runtime dll, the leocad installer should include the version that comes with the compiler used.

[Eugen]

That's a visual c runtime dll, the leocad installer should include the version that comes with the compiler used.

Thanks for details! I just reported it LeoCAD devs

• https://github.com/leozide/leocad/issues/358

[Philippe Hurbain]

Thanks for details! I just reported it LeoCAD devs

• https://github.com/leozide/leocad/issues/358
  

Thanks guys. Nonetheless, I should be able to install this DLL through Windows update, but I cant

[Leonardo Zide]

Thanks guys. Nonetheless, I should be able to install this DLL through Windows update, but I cant

You probably need to install the vs redistributable from https://support.microsoft.com/en-us/help...-downloads

I'll add the missing dlls to the installer.

[Philippe Hurbain]

You probably need to install the vs redistributable from https://support.microsoft.com/en-us/help...-downloads

Yes, that's the one that doesn't install (remains forever at "initialization" state) Something broken here...

[Eugen]

I did nothing, just updated the ldconfig.ldr in my LDraw folder (I use a plain LDraw library, not the zipped one provided with LeoCAD (view -> preference -> custom library)).

Thanks for details! Just updated my comment above:

• https://forums.ldraw.org/thread-23434-po...l#pid32593

Think, I found a way to reproduce issue with loading "ldconfig.ldr" placed in same folder where ZIP of "Custom parts library" stored. Here is issue report:

• https://github.com/leozide/leocad/issues/359

[Steffen]

Hej guys,

did you see this?
https://www.newelementary.com/2019/05/co...theme.html

   

It shows all Fabuland colors in 1 image.
Are all of them in our ldconfig.ldr correctly?

[Willy Tschager]

Hej guys,

did you see this?
https://www.newelementary.com/2019/05/co...theme.html

Sure here:

https://forums.ldraw.org/thread-23434-po...l#pid32160

w.

[Steffen]

ah, good. I missed that somehow.

[Willy Tschager]

Here's the new file:



Changes are:

Added Fabuland_Pastel_Green
Added Rubber_Medium_Lavender

Hopefully it comes with a working <CR>

w.

Two things:

• As there are no request for further additions I'm gonna pack this version in the new AIOI
  
• You won't believe it but I newer considered the line break at the end a major problem. What Is the simplest way to check if it is there or not - preferably in a WYSIWYG.
  

w.

[Magnus Forsberg]

Two things:

• As there are no request for further additions I'm gonna pack this version in the new AIOI
  
• You won't believe it but I newer considered the line break at the end a major problem. What Is the simplest way to check if it is there or not - preferably in a WYSIWYG.
  

w.

I don't want you to hold back he AIOI, but there is an issue here, that we need to solve.

Ldraw dark flesh colours

I haven't had time to dig into it yet, but I agree with Vincent, some of the flesh colours are off .

[Steffen]

Aside from my feeling expressed in my other post, LEGO already has numbers in the 3-400s. Restricting to 512 increases the chance of overlap.

well, then we still have numbers 401...512 for our purposes.
that should be plenty.
I still see no necessity to break MLCad when we can avoid that.
I just checked the currently official ldconfig.ldr, and there is plenty of free number space in it.

[Orion Pobursky]

well, then we still have numbers 401...512 for our purposes.
that should be plenty.
I still see no necessity to break MLCad when we can avoid that.
I just checked the currently official ldconfig.ldr, and there is plenty of free number space in it.

I disagree. If Micheal wants to release a new version of MLCad or open source his program I'll reconsider. Until then, I'm not really interested in further official support/promotion of MLCad.

[Travis Cobbs]

Two things:

• As there are no request for further additions I'm gonna pack this version in the new AIOI
  
• You won't believe it but I newer considered the line break at the end a major problem. What Is the simplest way to check if it is there or not - preferably in a WYSIWYG.
  

w.

In most (all?) WYSIWYG text editors, if the very last line in the file is completely empty, it means that there is a line break at the end of the previous line. In other words, it allows the cursor to go down one line below the last line in the file.

[Michael Horvath]

Is there any way we could tag the MILKY colors? In the future they could benefit from sub-surface sampling.

[Steffen]

we already have the following keywords in ldconfig.ldr:

MATERIAL SPECKLE
MATERIAL GLITTER
RUBBER
METAL
CHROME
PEARLESCENT

and for the glow in the dark
LUMINANCE

and additionally for GLITTER and SPECKLE colors the syntax elements
FRACTION
VFRACTION
SIZE
MINSIZE
MAXSIZE

so I see no reason why we should not add
MILKY

to this syntax. on the other hand: isn't MILKY just a partially transparent part,
i.e., wouldn't using ALPHA do what you want?

[Michael Horvath]

to this syntax. on the other hand: isn't MILKY just a partially transparent part,
i.e., wouldn't using ALPHA do what you want?

MILKY should be gradually transparent, no? I mean, thicker and harder to see through in the middle, but more transparent around the edges, like jade stone. That is what subsurface scattering is designed to mimic. And the normal transparent parts are *not* like this.