| |
> > That's a great idea! Though, and I might be confused here, wouldn't it
> > be possible to just create a stud.lcd file, and as the stud.dat file in
> > included, the lcd info would automagically be there?
>
> I thought so too, but the format document (way at the bottom) implies
> that this might be undesirable. I'm not sure I understand why, though : (
I do indeed think it would be undesirable. As we all know Stud.dat gets used
every ware. There are a fair few instances were the clicking behaviours of two
bricks would be different even though they are both referencing the same
stud.dat file for geometry.
For example parts 3822 and 3622. A door and a brick respectively. The studs on
the brick snap every 90 degrees but on the door you often want it open to say
45degrees. So there are two different behaviours for stud.dat in this case. If
you inherited clicking information from sub parts of the geometry of a brick,
you would need to keep track of all the different ways that sub part can be
used. This would make things much more complicated.
The use of sub parts and primitives is a very elegant way of representing
geometry for Lego bricks. I think the same solution can be applied to clicks.
I propose that instead of inheriting from sub parts click authors can use a
library of sub clicks. The same way primitives like stud.dat are used for the
geometry of bricks.
To sum up. There would be a stud.lcf but it would not be referenced from
stud.dat.
The latest GLIDE download has a few .lcf files included with it. I recommend
taking a look at these. It shows a bit of file reuse for stud and stud inlet
pairs.
--Dan.
|
|
Message has 1 Reply:
Message is in Reply To:
35 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
|
|
|
|
