 | | Re: Black seems wrong in ldconfig.ldr
|
|
(...) We're working on it. Give us another 24 hours to have something to present. Not a final 'done deal', but at least a decent writeup. Steve (21 years ago, 16-Jan-04, to lugnet.cad.dev)
|
| |
| | Re: [Parts Tracker] Security Change underway
|
|
(...) Hopefully not too much longer - I'm working on the last script now. Steve (21 years ago, 15-Jan-04, to lugnet.cad.dev)
|
| |
| | Re: [Parts Tracker] Security Change underway
|
|
(...) hi steve, could you please keep us updated how long we will need to log in twice? many thx, willy (21 years ago, 14-Jan-04, to lugnet.cad.dev)
|
| |
| | Re: Black seems wrong in ldconfig.ldr
|
|
(...) Where else would you put it? What if you break the material settings up into two parts? 1) a material tag on the COLOURDEF line: 0 COLOURDEF 334 ChromeGold 15 0xFFC40026 MATERIAL metallic 2) a MATERIALDEF line added to the end of the file that (...) (21 years ago, 14-Jan-04, to lugnet.cad.dev)
|
| |
| | Re: Inline POV code in official parts?
|
|
(...) That's a very heavy argument against EmbPOV. It would be a great thing if we could just have a very few basic features, say clipped by, pattern wrap and maybe one or two other and make it a generic syntax for alternative code. (...) Despite (...) (21 years ago, 13-Jan-04, to lugnet.cad.dev)
|
| |
| | Re: Black seems wrong in ldconfig.ldr
|
|
(...) I agree that something of that sort would be a good idea, but in the case of my metallic colors, I actually hand-tweaked the settings for each metallic color. They aren't all the same. This was done partially to differentiate between chrome (...) (21 years ago, 13-Jan-04, to lugnet.cad.dev)
|
| |
| | Re: Black seems wrong in ldconfig.ldr
|
|
(...) Why not use the optional MATERIAL bits from this old discussion (URL) come up with a modified ldconfig.ldr? Then implement some code in LDVIEW to enable your metallic lighting goodies when ldconfig.ldr contains the proper MATERIAL settings. (...) (21 years ago, 13-Jan-04, to lugnet.cad.dev)
|
| |
| | Re: Black seems wrong in ldconfig.ldr
|
|
(...) Given that ldconfig.ldr is part of the LDraw parts library, I was referring to the color reference on the LDraw.org site (noted in another message). However, it might make sense to use the colors above, since they came directly from Lego, and (...) (21 years ago, 13-Jan-04, to lugnet.cad.dev)
|
| |
| | Re: Black seems wrong in ldconfig.ldr
|
|
(I switched to FTX due to an unusually long link.) (...) I was referring to the one at ldraw.org (URL) (LDraw definitions at the bottom). I believe that the LDraw color definitions there came from some version of the LDraw FAQ. When I said (...) (21 years ago, 13-Jan-04, to lugnet.cad.dev, FTX)
|
| |
| | Re: Black seems wrong in ldconfig.ldr
|
|
(...) In fact the official LEGO colour chart mentioned here (URL) uses 27, 42, 52 for black. ROSCO (21 years ago, 13-Jan-04, to lugnet.cad.dev)
|
| |
| | Re: Black seems wrong in ldconfig.ldr
|
|
(...) (er, which official color chart?) (...) Uh, Travis, it's *black*. It's *supposed* to be dark. People have questioned/complained that it's not 'true black' (ie, 0,0,0). You might be right about the origin of the 33 value, but I believe I was (...) (21 years ago, 13-Jan-04, to lugnet.cad.dev)
|
| |
| | Re: Black seems wrong in ldconfig.ldr
|
|
Sorry to immediately post a follow-up to my own post, but I just noticed that RubberBlack is defined with the same 33,33,33 color (not surprisingly), and I feel it needs to be updated as well. --Travis Cobbs (21 years ago, 12-Jan-04, to lugnet.cad.dev)
|
| |
| | Black seems wrong in ldconfig.ldr
|
|
The ldconfig.ldr file currently being distributed with the parts library seems to have the wrong definition for black. It uses 33,33,33 as the RGB color, when the official color chart uses 51,51,51. Two things to note. First, 33,33,33 comes out (...) (21 years ago, 12-Jan-04, to lugnet.cad.dev)
|
| |
| | Friction pins no friction?
|
|
It struck me as odd that the 3673 Technic Pin (no friction) and the 4459 Technic Pin with Friction looked identical. Why are they the same? Where is that friction? I feel there should be a line of connect primitives that clearly show this friction. (...) (21 years ago, 12-Jan-04, to lugnet.cad.dev)
|
| |
| | Re: Need partnumbers and some partnames
|
|
(...) I think putting Motor Cutout in the keywords would work, if we can't reasonably fit it in the part title. (...) OK, I think Stop and Proceed are OK for the names. (...) So the light bulb can be physically removed from the complete part? But (...) (21 years ago, 8-Jan-04, to lugnet.cad.dev)
|
| |
| | Re: primer/tutorial on BFC?
|
|
(...) [snip] (...) I just wanted to add one more post in an attempt to clear up any confusion that may have been caused in this thread. What Andy says above is correct, and my earlier post indicating otherwise was incorrect. The two dimensional (...) (21 years ago, 4-Jan-04, to lugnet.cad.dev)
|
| |
| | Re: primer/tutorial on BFC?
|
|
(...) Hmmm, very good point. I don't like treating specific object specially, but I don't see any way around it. I played around with the stud and with a 'solid' cylinder object, I couldn't find a way to get L3Lab's BFC handling to fail. Steve (21 years ago, 4-Jan-04, to lugnet.cad.dev)
|
| |
| | Re: primer/tutorial on BFC?
|
|
(...) Actually, I *think* it's the new ATA controller card I installed, and LDView was just an innocent bystander. However, since LDView doesn't do BFC, I guess I didn't miss anything. (...) Yes, you could use INVERTNEXT, but that introduces (...) (21 years ago, 4-Jan-04, to lugnet.cad.dev)
|
| |
| | Proposed changes to MOTM Submission guidelines
|
|
After formal running the MOTM contest for a month, I've becomed concerned with the fairness of the contest. In response to my concerns, I'd like to make the following changes to the rules for MOTM in order to level the playing field. - All (...) (21 years ago, 4-Jan-04, to lugnet.cad, lugnet.cad.dev, lugnet.cad.dev.org.ldraw)
|
| |
| | Re: primer/tutorial on BFC?
|
|
(...) You're right; I'm wrong. I'm still having a hard time visualizing it, but your stud example below convinced me that negating the one value in the matrix will indeed flip a 2D primitive like a disk, and this is the expected behavior. In fact, (...) (21 years ago, 3-Jan-04, to lugnet.cad.dev)
|
