[sldev] [VWR] VWR-489 Multiple Attachments per Attachment Point.
aleric.inglewood at gmail.com
Thu Aug 13 08:36:52 PDT 2009
indeed-- to an extend it would allow for equivalent manipulations
of attachments if you'd have:
etc attachment points, instead of
Chest + 32bit mask.
But indeed, the former would be equivalent only
with the latter if the latter was restricted to having
a single bit set in the mask; which would void the
need of a mask altogether (you could just use a number).
What I want to make possible is "automatic" removal
of attachments when the user wants that. You cannot
in advance think of when a user wants that because
the possibilities are endless. Hence, we need a system
that allows as much as possible.
An example would be: I can have the following
attachments on my 'chest':
* A tickler (invisible object that makes me laugh when clicked)
* A colar (extension of my coat).
* A necklace
* A hoodie (extension of my shirt)
* A titler (displays a text above my head)
* A hugger (could be attached elsewhere, of course)
* A second necklace (really, a 'military nametag' type of thing).
Most of those should NOT remove any of the others,
but now I find that the colar 'sticks' through the hoodie,
so I (the user) decides that if the hoodie is attached,
the colar has to go.
However, I have another shirt with a different colar,
and that colar is not sticking through the hoodie, so
I don't want to replace that colar when the hoodie
is attached. However, if I change shirts than I want
one colar to replace the other.
This would be possible when using a bitmask,
not when using just a heap of attachment points.
On Thu, Aug 13, 2009 at 3:19 PM, Boroondas
Gupte<sllists at boroon.dasgupta.ch> wrote:
> Aleric Inglewood schrieb:
>> I think that each attachment should have a bit mask for
>> community assignable categories
> If I'm not mistaken, the modified XML is equivalent to the bit mask
> solution. You don't have multiple attachments per attachment points but
> rather more attachment points, some of which happen to have the same
> position* as already existing ones. So there's a bijective mapping from
> (attachment position, set mask bit)-pairs to attachment point IDs from
> the modified XML. What's missing is only the naming of the categories
> and a GUI that represents the bit mask rather than giving different
> names to different IDs.
> * by 'position' I mean the origin of the attachment points' local
> coordinate system, not the attachments' position within that coordinate
> Of course, implementing it in the bit mask way would make it easy to add
> fancy extensions, like e.g. attachments that have more then one bit set.
> (A cyber armor glove with integrated ray gun might replace both other
> gloves and swords when worn.) Then again, when the bit mask
> implementation is chosen, the attachment-manipulating LSL functions
> should probably reflect that too, by a different function signature.
More information about the SLDev