To LUGNET HomepageTo LUGNET News HomepageTo LUGNET Guide Homepage
 Help on Searching
 
Post new message to lugnet.cad.devOpen lugnet.cad.dev in your NNTP NewsreaderTo LUGNET News Traffic PageSign In (Members)
 CAD / Development / 1380
1379  |  1381
Subject: 
Re: LDraw part library structure
Newsgroups: 
lugnet.cad.dev
Date: 
Thu, 15 Apr 1999 07:49:39 GMT
Viewed: 
1964 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:
  Re: LDraw part library structure
 
In lugnet.cad.dev, Terry Keller writes: (Moved to lugnet.off-topic.fun) (...) Aww... Ya mean I have to switch to AT&T? ;) "Name that Slogan!" Jeff (27 years ago, 15-Apr-99, to lugnet.off-topic.fun)

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 (...) (27 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
    

©2005 LUGNET. All rights reserved. - hosted by steinbruch.info GbR