Subject:
|
Re: Request for more stringent naming of (Complete|Shortcut) parts
|
Newsgroups:
|
lugnet.cad
|
Date:
|
Wed, 17 Sep 2008 20:19:40 GMT
|
Viewed:
|
5163 times
|
| |
|
|
In lugnet.cad, Kevin L. Clague wrote:
> As thorough as this document is, it is incomplete or ambiguous in the area of
> describing "compound parts". For example 4107488.dat, "Technic Tread (Complete
> Shortcut)" is actually composed of multiple of 681.dat, 680.dat, and 682.dat
> instances.
Shouldn't 680.dat, 681.dat, and 682.dat all be in the parts/s directory? They
don't represent real pieces of plastic (or rubber in this case), so I don't
understand why they are modeled as such. Or do synthesized sub-parts get
treated differently?
> Without guidance, LPub happily shows N 680.dats, M 681.dats, and O 682.dats,
> which make absolutely no sense to LDraw novices. Sure, the version of LSynth
> that our dear friend Willy uses, automatically solves this problem.......
> but.....
>
> Where possible I'd like LPub to automatically know that N 680's, M 681's and O
> 682's means one 4107488.dat in the part list image. Think of a more simple
> case: Minifigs...... as dear as they are, the are compound parts.
>
> I'd like LPub to see N instances of battle droid head, battle droid torso, two
> battledroid arms, and two battledroid legs and realize that they are a
> battledroid.
I think the minifig/battle droid case is fundamentally different from the
technic tread case, and care should be taken not to confuse the two. The
technic tread is a single piece of flexible rubber that has a shortcut part that
represents one popular shape that it is used in. The minifig is something that
is constructed from multiple real life pieces. I understand that what you want
is something that can be used for both cases, and be recognized by LPub, but
care definitely needs to be taken.
On a side note, LDView automatically considers any sub-files of a "part" to not
be a part (for the purposes of scaling for seams). It seems to me that LPub
should probably do the same, which would solve your problem with 4107488.dat.
After all, if someone has declared something to be a part (either via a header
comment or by putting it in the parts directory), then it seems safe to assume
that it really is a part, even if it is composed of other parts.
> How will it know this? Look at all examples of "compound parts" in all the
> official and unofficial parts directories and know what they are composed of.
>
> I've come up with simple rules for detecting "compound parts".....
>
> grep "Compound" * > foo
> grep "Shortcut" * >> foo
>
> but this is a heuristic, not a perfect algorithm. If we could come up with a
> more precise "complete shortcut" description, it could be much more computable.
I'm not sure why this is necessary. If you treat sub-files of parts as not
being parts, then you get this automatically. Since there's already an official
way to specify that something is a part (header comment), I don't see why a new
"official compound part" definition is needed. Or do you feel that having
sub-files of parts not be parts will lead to combining of parts into one single
part when they shouldn't be?
On a side note, remember that LEGO instructions always give instructions for how
to assemble mini-figs, battle droids, Martians, etc. So I'm not even really
sure how those would fit into this discussion at all, since they would be built
from multiple parts in the instructions. The only edge case I see is the
minifig hands and arms, which come pre-connected to the torso.
--Travis
|
|
Message has 2 Replies:
Message is in Reply To:
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
|
|
|
|
