ldconfig.ldr chrome colors and parts tracker.

[Don Heyse]

I'm not quite sure how you sneaky guys on the LSC got this one by me.

Apparently while I was sleeping somebody managed to define a few chrome colors in the ldconfig.ldr file in positions 60-63, which have been reserved for almost forever by ldlite as transparent colors in the range 32 to 63. Now, ldglite inherits the colors from the ldlite code so these display as transparent instead of chrome, and will do so on the parts tracker if you're still using ldglite to render the parts. It's not a big deal to change the ldglite code, but if you want to fix these chrome colors on parts tracker you're gonna need a recompile of ldglite, or else switch to ldview. Or you could redefine the chrome colors in ldconfig.ldr to occur above color 63. Chrome_black, gold, and silver are defined above 63, so they're ok already.

Any thoughts on this?

[Steffen]

this thread should be relocated to "Parts and Standards" IMHO
http://forums.ldraw.org/list.php?21

[Steffen]

apart from the topic you brought up,
can you change ldglite to read and use ldconfig.ldr ?
or does it already?

I remember that Chris had to jump through some hoops on the Parts Tracker
to get ldconfig.ldr converted into something that ldglite understands.
As ldconfig.ldr seem to me now be a standard of LDRAW, every program should move towards the direction of using it IMHO

I should have posted this below
http://forums.ldraw.org/index.php?7
, but found no really suitable group there.
As stated already here http://forums.ldraw.org/showthread.php?t...333#pid333 ,
I feel ldglite not properly represented in this forum currently.

[Orion Pobursky]

Done!

[Don Heyse]

I think there are already too many forum categories. Any list that goes off the bottom of the screen is too many. I'd much prefer to see some of the wasted vertical space squeezed out of the recent messages view (showing all categories) over creating more subforums.

As for ldconfig.ldr support, I think all the current released ldglite executables look for it in the parts search paths so copying it into the ldraw/models directory should work. The Parts Tracker executable is a custom offscreen rendering only build for BSD made long ago when I had a login account on the ldraw.org server. It predates the ldconfig.ldr code, and uses the older ldliterc.dat file and format instead.

I've recently updated the code to look in the main ldraw directory first, but I'd really like to see that location codified in an official standard before I put in the effort required to create a bunch of executable releases. However, if the account with the parts tracker code still exists, it probably wouldn't require too much effort to recompile it with the latest code.

[Steffen]

Wow, this is good news.

Chris, I'll send you a link to this thread, so we can maybe improve the PT rendering.

If I can be of any help, let me know anybody.

[Steffen]

I just tried to file a request to LSC to officially document the location of ldconfig.ldr:
http://forums.ldraw.org/showthread.php?t...348#pid348

Well, maybe that's not even necessary, because the recent parts updates
included that file in LDRAW's root folder,
so that's a de-facto standard already now.
Would that be enough reason to modify ldglite accordingly?

[Steffen]

... here http://forums.ldraw.org/showthread.php?t...272#pid272

[Roland Melkert]

I started a LSC topic on this.

http://forums.ldraw.org/showthread.php?tid=352,352

[Travis Cobbs]

Don Heyse Wrote:
-------------------------------------------------------
> I'm not quite sure how you sneaky guys on the LSC
> got this one by me.

The LSC does not control the contents of LDConfig.ldr. This was discussed internally in the LSC at some point in the past, and we did not want control over the file.

[Steffen]

yikes, that seems to be something bad to me.

the file currently is delivered officially with the parts updates,
so it is a de facto standard now.

the LSC should control all files that get delivered by official updates IMHO,
except for those which are delivered as a "giveaway", like an MLCad.ini (which currently isn't, but could in future).

the ldconfig.ldr file in the meantime has become very central in the LDRAW library
that IMHO being not revised/controlled by the LSC seems being a Bad Idea ™ to me...

[Tim Gould]

The bylaws do allow for delegation of authority (eg. the webmasters and Parts Admin) so adding Scott as a Colourmaster is not so different. Chris has ultimate control over the parts, Scott has ultimate control over the colours.

I do see your point but I think it's an acceptable compromise rather than having it all decided by the LSC. They can overrule bad decisions.

Tim

[Scott Wardlaw]

Although I am currently responsible for this file, I want to assure you that it has and still is a team effort. There are at least 4 or 5 people that have spent more than 20 hours working on it and providing feedback (probably over 80 hours myself). Whenever updates are to be made, I send direct emails to people that I trust for their opinions, and for major changes, I solicit opinions from posts to LUGNET and Flickr (now here as well). I encourage anyone to email me with new information, opinions on color values, etc. I can't promise to make everyone happy (including myself), but I do promise to work hard in trying.

I share your opinion that color codes 32-63 should be reserved for transparent colors, but I was not directly involved with this file at the time when the non-transparent colors were placed there....I think they have been there for nearly two years.

As always, if you have any new information or have a strong opinion about anything related to LDConfig, please send me an email.

Thanks,
Scott

[Travis Cobbs]

As a member of the LSC for many years, it is my belief that if this file was controlled by the LSC, hardly any new colors would ever make it in. Additionally, the decisions would be more poor than the current process, due to the fact that LSC members are there due to an interest in the LDraw standard, while people working on the colors have a passion for colors. I know I personally am not a good person to be making decisions about colors, and my general lack of interest is counter-productive to keeping the file up-to-date.

[Willy Tschager]

The SteerCo started discussion on how to handle this.

w.

[Chris Dee]

I think we should differentiate between structure and content. I agree that the LSC should define the structure and syntax of the config file, just like they do for parts files. But we don't expect the LSC to review/control the content of every part file, so why the config files.

I see the maintenance of ldconfig.ldr as an authoring exercise, although unlike parts files, we only really need one author - and Scott is doing a good job in that respect. I don't see a problem with Scott handling the review process independently of the Parts Tracker with those known to have a strong interest in this area.

The current release process is to post updated versions on the server for individual download, and incorporate the updated version into the subsequent parts update.

[Steffen]

Just to clarify what I wanted to say:

I of course think that Scott is doing a very good job on that file,
but previously I even did not know that he does :-( :
I must have missed documentation on this on ldraw.org.
Maybe just the folks taking care of this file should be mentioned somewhere at
http://www.ldraw.org/library/tracker/ref/

By my suggestion above, I just had wanted to make sure 2 things:
(a) no arbitrary syntax extensions should slip in -
syntax should be defined the same way as for *.dat / *.ldr / *.mpd files IMHO
(b) no color set mistakes should slip in - Don's post above had let me fear that

When on ldraw.org a central page is present where the maintainers / color experts
are listed, so they can get contacted, I'm fine with the current method of maintaining the file.
I appreciate all work that has gone into it already.

My main problem currently is the resolving of this question:
http://forums.ldraw.org/showthread.php?t...214#pid214
- Scott, I think I really need your help in that issue.
Whatever is decided there, the decision will affect some official and unofficial parts,
because in the past a real mess had been created regarding the metal colors,
due to misunderstandings and a lack of systematics.
Please see that thread.