Subject:
|
Re: Request for more stringent naming of (Complete|Shortcut) parts
|
Newsgroups:
|
lugnet.cad
|
Date:
|
Thu, 18 Sep 2008 01:23:37 GMT
|
Viewed:
|
5663 times
|
| |
|
|
In lugnet.cad, Travis Cobbs wrote:
> In lugnet.cad, Kevin L. Clague wrote:
> > In lugnet.cad, Travis Cobbs wrote:
> > > 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.
> >
> > Fair enough. I didn't know they were always shipped disassembled.
>
> Well, it's not shipped completely disassembled (arms and hands are pre-attached
> to the torso, and legs are attached to hips). However, I have certainly never
> seen them shipped completely assembled as a minifig (except for the glued
> keychains, which probably don't count here).
>
>
> > > 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.
> >
> > The only files that LPub opens and analyzes are model and submodel files. All
> > other opening and analyzing of part files is done by LDView and LDGLite.
>
> That confuses me. I don't understand how 680.dat, 681.dat and 682.dat can show
> up in your BOMs if the model uses 4107488.dat, and LPub doesn't parse
> 4107488.dat itself. I can see how they would show up if the model used them
> directly to get the desired shape, but it sounds like lsynth would normally be
> used for this, and LPub already recognizes that. So how is it that when a user
> uses 4107488.dat, 680.dat, 681.dat, and 682.dat show up in the BOM (which I
> believe is the problem you want to solve)?
The point is that the model does *not* use 4107488.dat because that is not the
right shape for the model...... If everyone only ever used 4107488.dat, I would
not have brought it up.
>
>
>
> > Lets try a few other examples:
> >
> > a) technic turntable tops and bottoms can have a phase difference from 0 to
> > 359 degrees. If your design needs a phase difference other than what the
> > "complete" version does, you add your technic turntable as two pieces.
> >
> > b) same thing with motors.... the shaft can be at any angle WRT the body. To
> > make this work, you would use a complete motor sans shaft, and a shaft.
>
> These are good examples of your problem, but I'm not sure how an update to the
> spec for official parts will help you. Maybe I misinterpreted your whole
> request, but having some pre-set format for part names for composite parts won't
> help here. Furthermore, if LPub isn't parsing the parts themselves anyway, then
> I don't see how changes inside the part library would have any effect on the end
> result in LPub.
Chris has told me how to recognize the complete parts. What I am considering is
LPub scans the library for a list the "complete" parts. I would add new code
to open up and examine the complete parts, and try to compress the list of
sub-pieces in the PLI into complete parts.
>
>
> > These two cases are the same thing, but in both cases you have to use two parts
> > (or subparts directly used in your model file), but you want the complete
> > version to show up in the part list images. LEGO ships turntables and motors
> > completely assembled.
>
> I agree that there needs to be a way for LPub to recognize this case, but I
> don't think the solution belongs in the spec, and I also don't see how the
> solution would impact official parts. My suggestion would be another LPub
> begin/end meta pair to say "all lines between this begin and end should be
> treated as a single part in the BOM". Note: since it seems that I'm
> fundamentally misunderstanding something about what is going on, I could easily
> change my mind about this. I'm not dead set against updating the spec, I just
> don't see how the behavior you've described would warrant it, based on my
> understanding of what you have described.
We have that already.
>
>
> > > 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.
> >
> > I didn't know the *always* part was a given. If so, then there is no issue for
> > minifigs.
>
> I can't recall having ever seen a set that contained minifigs that didn't have
> the minifig building steps at the very beginning of the set's instructions.
> Having said that, the arms, legs and hands can all be at arbitrary angles if the
> figure is placed into the model in the instructions, so it's still theoretically
> possible that it would be good to have a fully built minifig show up in a BOM.
> I still think this would better be served by LPub-specific meta-commands in the
> model itself, though, since the user obviously couldn't put their custom-posed
> minifig in the official library.
Obviously I don't buy sets with minifigs....... :^)
>
> --Travis
Kevin
|
|
Message has 1 Reply:
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
|
|
|
|
