[opensource-dev] Removal of the "MultipleAttachments" debug settings ?
aleric.inglewood at gmail.com
Fri Aug 27 05:11:11 PDT 2010
The following has been proposed before:
* Add new bits to each object (all existing objects should act as if
all bits are set).
* Give the bits a default meaning (read: human readable word, which
can be different per attachment point),
but allow each user to override those descriptions locally.
* Allow users to change the bits for each of their objects, even no-modify ones.
* If a user 'wears' (or adds, which becomes redundant) a new
attachment, then remove those attachments that have
one or more of the same bits set. In other words, at any time one
can only have one object attached at a given
position with any given bit set.
Suppose you think that 8 bits are enough, then the following holds:
* 11111111 = old 'wear' behavior: replaces everything else.
* 00000000 = 'add' behavior: is added, replaces nothing.
* 00000001 = (for example): assign default meaning 'jacket' for chest
attachments (jacket collars and hoodies).
* 00000010 = (for example): assign default meaning 'shirt' for chest
attachments (shirt collars).
* 00000100 = (for example): assign default meaning 'necklace' for
and so on.
This allows users to make groups of attachments that are mutually exclusive,
but having up till 8 classes that can be worn at the same time on the same
Personally I think that those bits also should be added to normal wearables,
so that it is possible to have attachments being removed when you wear
a new shirt (ie, a shirt without a collar should remove all existing
or wearing a penis could automatically remove underwear and pants and
visa versa, Linden shoes could remove prim shoes, etc, all user customizable
for his/her own attachments; the default naming would be just a hint to
make things work reasonable after just having bought it).
I'm not sure, but I think that having eight classes per attachment points
should be enough, so adding a single byte to every object should be
On Thu, Aug 26, 2010 at 10:43 PM, Nyx Linden <nyx at lindenlab.com> wrote:
> however, so if you have suggestions for better ways of exposing the
> functionality, please do let us know!
More information about the opensource-dev