Subject:
|
Re: LDraw part library structure
|
Newsgroups:
|
lugnet.cad.dev
|
Date:
|
Thu, 15 Apr 1999 07:49:39 GMT
|
Viewed:
|
815 times
|
| |
|
|
On Thu, 15 Apr 1999 03:11:25 GMT, Joshua Delahunty
<dulcaoin@alumni.cse.ucsc.edu> wrote:
> Terry K wrote:
>
> > Anyway, thanks to Joshua Delahunty and his solution for the file-naming of
> > composite elements, the general plan of organization of categories and naming
> > of parts has been finalized.
>
> You're welcome, Terry. A labor of love, it was.
> <big snip>
>
> > ---- xxxxCyy.dat ----
> > This is the new one.
> > Parts named using this system will be "Composite" parts using the #16
> > color-code. "Composite" being two or more parts normally joined together in
> > real life.
> > These are also for intended for modeling. We need these because most composite
> > elements do not have their "official" number molded on. And on those that do
> > have a molded number, that number refers to the subpart into which it is
> > molded, not the entire assembly.
> > The idea is to use that molded-in number that is most visible, BUT also add the
> > additional "Cyy" to the end. This will be somewhat more intuitive that using a
> > completely random number. And at the same time *clearly* denote that the part
> > is a #16 color composite.
> >
> > But what if the composite element has no number molded into it at all?
> > Simple. We assign a 3-digit number using the xxxCyy.dat format.
> > Of course, we try to limit that as much as possible.
>
> Don't even worry about this, Terry. Either we're going to have a
> 5-digit code for the entire assembly that we can use, or we're going to
> know the 4-digit codes even if they're not molded in. It would be a
> very very rare case where nothing in the element wasn't known.
Most likely true. Just trying to be cautious.
> > This, essentially, is the same thing as the Patterned parts using xxxxPyy.dat.
> > Using this system will give modelers the flexibility of using #16 color
> > composite parts, even if they don't actually exist in real life.
>
> I want to point out here -- to stress -- the beauty of this solution:
>
> So many didn't like the idea of not using the most "visible" and -- to
> them -- obvious code: that stamped somewhere on an element, but this
> system allows for that. 30086P01 is going to be sitting right next to
> 30086 in the list, and will be usable in any color the modeller chooses,
> while at the same time marking very plainly the element as an unofficial
> code: a code that James might very well have chosen himself (GRHS).
Good clarification. Thanks for pointing that out.
> <big snip>
>
> > Whew! My "summaries" are started to resemble Todd's. :-)
>
> That's a good thing, Terry. :)
Only if they are as concise, well-ordered and logical as Todd's.
Mine always seem to be a rambling monologue. :-/
> > But seriously, I would like to express my thanks to Joshua Delahunty for all
> > his brainstorming and hard work on formulating these standards. His ideas for
> > using underscore categories and the xxxxCyy formatting for composites was
> > pivotal. Although initially, I had my doubts.
>
> Initially, ha! (I had to hit him with a wiffle bat repeatedly, folks)
> <g>
And those virtual wiffle bats are HARD! See? Reach out here and feel this
lump. :-)
> > Ultimately, Joshua was right of course, and I thank him for being so patient
> > when I was so adamantly dense.
>
> Back atcha, Terry. The most elegant parts of the solution only came
> because of your hard stance on the issues. The solutions here are
> designed to (mostly) please everyone from every camp, and at the same
> time -- most importantly to me -- adhere to the standards and tradition
> (if you will) that James established from the beginning.
Yeah....... I adopted the, um, hard stance on those issues specifically to
force you and Steve to carefully weigh all the alternatives.
Yeah, that's the ticket.
> > And I would also like to thank Steve Bliss for his opinions and inputs through
> > all this. Steve and Joshua were pretty much at polar opposites on just about
> > every subject in this debate. But somehow we all managed to finally give a
> > little here and there and compromise out a solution. Pretty tough going at
> > times, with me in the middle, vacillating between sides.
>
> Steve was very tough, and we each made the other think very hard about
> this. I'm glad he was there to balance the issues. It was really his
> stance on visible part elements that pushed me to produce the rather
> elegant (and orthogonal) xxxxCxx solution.
>
> <snip>
Now to put it into practice. Ugh. More stuff to keep track of.
Joshua, limber up your bat arm, I foresee a lot of whacks needed ahead to jar
my memory. :-)
-- Terry K --
|
|
Message has 1 Reply:
Message is in Reply To:
 | | Re: LDraw part library structure
|
| (...) You're welcome, Terry. A labor of love, it was. <big snip> (...) Don't even worry about this, Terry. Either we're going to have a 5-digit code for the entire assembly that we can use, or we're going to know the 4-digit codes even if they're (...) (25 years ago, 15-Apr-99, to lugnet.cad.dev)
|
10 Messages in This Thread:
   
- Entire Thread on One Page:
- Nested:
All | Brief | Compact | Dots
Linear:
All | Brief | Compact
This Message and its Replies on One Page:
- Nested:
All | Brief | Compact | Dots
Linear:
All | Brief | Compact
|
|
|
|
