[opensource-dev] Removal of the "MultipleAttachments" debug settings ?
aleric.inglewood at gmail.com
Fri Aug 27 05:48:01 PDT 2010
I fail to see how your example could undermine the bits-proposal.
For a start, the bits *only* add possibilities (254 per object!).
Currently the ONLY existing behavior is as if my bits are already in place, but
set to 11111111 when you 'wear' something, and to 00000000 when you 'add'
something. Adding the bits will just open up a whole scala of control over
how your attachments replace other attachments (and clothing?).
On Fri, Aug 27, 2010 at 2:20 PM, Francesco Rabbi <sythos at gmail.com> wrote:
> You lost quite all good taste of this feature.... Ppl should be free
> to add everything in funny/weird way, and creators cannot be limited
> matching which bit another creator use...
The possibilities only increase, as I just explained. You can
still add anything in every way possible. I specifically said
that each user should be able to change the bits of objects
even if those objects are no modify. You can always just
set all bits to 0, then you can wear anything and everything
at the same time.
> The solution is resident side: outfits folders, may be interesting
> mark boxes or vendors to create automatically outfit folders maybe
Lets look at your example. I added comment on the right.
> -outfit "naked"
> Hair <--- Head attachament
> SHAPE NO bits (or all 0)
> Skin NO bits (or all 0)
> Genitalia <--- Pelvis attachment
> -outfit "sport"
> All above but genitalia
> Jeans <--- covers genitalia
> Shirt collar <--- Chest attachment
> Necklace <--- Chest attachment
> Shoes <--- Feet attachments
Ok, so a user could set the same bit on the Genitalia object
as on the pants. Then they would become mutual exclusive,
which is what you want apparently (and which makes sense
since pants cover genitalia. Pants that don't should just NOT
set that bit).
Assuming that it looks good if you wear the necklace and
the shirt collar at the same time: put them in different classes
so they won't replace each other when worn.
> "replace" outfit should revert from to other, without got creators crazy
"replace outfit" is an entirely different thing than "wear" attachment/clothing.
The usual meaning is that EVERYTHING is removed and then things in
the folder are added.
> If a vendor or box can be enganced with "outfit" (over buy content and buy copy)
I think daily outfit management by the users is more important
than the urge to control how and what the users wear by vendors.
If things bought by users don't work out of the box, then they will have to
manually remove a few things, just like now. But at least they'll be able
to automate that and not have to worry about having the add and remove
attachments/clothing EVERY time, when wearing stuff from inventory.
Any change to wearing a new outfit that is in a just-bought box is
orthogonal to my proposal.
> ( all this marked with a giant IMHO)
> Sent by iPhone
> Il giorno 27/ago/2010, alle ore 14:11, Aleric Inglewood
> <aleric.inglewood at gmail.com> ha scritto:
>> 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
>> chest attachments.
>> 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
>> attachment point.
>> 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!
>> Policies and (un)subscribe information available here:
>> Please read the policies before posting to keep unmoderated posting privileges
More information about the opensource-dev