• All submissions to this site are governed by Second Life Project Contribution Agreement. By submitting patches and other information using this site, you acknowledge that you have read, understood, and agreed to those terms.
Issue Details (XML | Word | Printable)

Key: VWR-11644
Type: Sub-task Sub-task
Status: Open Open
Priority: Normal Normal
Assignee: Unassigned
Reporter: Boroondas Gupte
Votes: 5
Watchers: 1
Operations

If you were logged in you would be able to see more operations.
1. Second Life Viewer - VWR
VWR-489

Attachment conflict scheme for multiple attachments per point

Created: 21/Jan/09 06:35 AM   Updated: 03/Feb/09 05:58 PM
Return to search
Component/s: Avatar/Character, Inventory, User Interface
Affects Version/s: None
Fix Version/s: None


 Description  « Hide
Carlo Wood proposed a way to decide which attachments would replace which other at the SLDev mailing list:
[sldev] Proposal for Extending the number of attachments per attachment point.

Here's my try to reformulate his proposal to be shorter and (I hope) easier to gasp:

Up to now an item replaces another one if and only if they are of same "type" (for clothing) or would occupy the same attachment point (for HUDs/attachments). The feature would add (mutually exclusive) "categories" to what we currently have and an attachment/HUD would then only replace another one if and only if they would occupy the same attachment point AND both be of the same category share at least one category (one item can be in multiple categories at once, or none at all). For clothing (as the proposal is now) nothing would change.

Users would be able to change the names of the individual "categories" to reflect their actual usage. Because the usage of the "categories" doesn't actually has to be in the sense of conceptual categories, maybe "slots" would be a better name. (Up to now, each attachment point has a single "slot". With the new feature there would be N "slots" per attachment point. Each slot can hold exactly one worn attachment at a time. Any newly worn attachment "pushes" a previous attachment at the same slot of the same attachment point (if any) "out of the slot".)

Carlo proposes to implement this by the usage of bit-masks



 All   Comments   Change History      Sort Order: Ascending order - Click to sort in descending order
Celierra Darling made changes - 21/Jan/09 03:45 PM
Field Original Value New Value
Summary Handling of which newly attached items replace which previously attached items once multiple attachments per attachment point are possible Attachment conflict (bitmask-based?) scheme for multiple attachments per point
Celierra Darling made changes - 21/Jan/09 03:46 PM
Summary Attachment conflict (bitmask-based?) scheme for multiple attachments per point Attachment conflict scheme for multiple attachments per point
Boroondas Gupte made changes - 23/Jan/09 02:16 AM
Description Carlo Wood proposed a way to decide which attachments would replace which other at the SLDev mailing list:
[\[sldev\] Proposal for Extending the number of attachments per attachment point.|https://lists.secondlife.com/pipermail/sldev/2009-January/012624.html]

Here's my try to reformulate his proposal to be shorter and (I hope) easier to gasp:

Up to now an item replaces another one if and only if they are of same "type" (for clothing) or would occupy the same attachment point (for HUDs/attachments). The feature would add (mutually exclusive) "categories" to what we currently have and an attachment/HUD would then only replace another one if and only if they would occupy the same attachment point AND both be of the same category. For clothing (as the proposal is now) nothing would change.

Users would be able to change the names of the individual "categories" to reflect their actual usage. Because the usage of the "categories" doesn't actually has to be in the sense of conceptual categories, maybe "slots" would be a better name. (Up to now, each attachment point has a single "slot". With the new feature there would be N "slots" per attachment point. Each slot can hold exactly one worn attachment at a time. Any newly worn attachment "pushes" a previous attachment at the same slot of the same attachment point (if any) "out of the slot".)

Carlo [proposes|https://lists.secondlife.com/pipermail/sldev/2009-January/012624.html] to implement this by the usage of bit-masks
Carlo Wood proposed a way to decide which attachments would replace which other at the SLDev mailing list:
[\[sldev\] Proposal for Extending the number of attachments per attachment point.|https://lists.secondlife.com/pipermail/sldev/2009-January/012624.html]

Here's my try to reformulate his proposal to be shorter and (I hope) easier to gasp:

Up to now an item replaces another one if and only if they are of same "type" (for clothing) or would occupy the same attachment point (for HUDs/attachments). The feature would add -(mutually exclusive)- "categories" to what we currently have and an attachment/HUD would then only replace another one if and only if they would occupy the same attachment point AND -both be of the same category- +share at least one category (one item can be in multiple categories at once, or none at all)+. For clothing (as the proposal is now) nothing would change.

-Users would be able to change the names of the individual "categories" to reflect their actual usage. Because the usage of the "categories" doesn't actually has to be in the sense of conceptual categories, maybe "slots" would be a better name. (Up to now, each attachment point has a single "slot". With the new feature there would be N "slots" per attachment point. Each slot can hold exactly one worn attachment at a time. Any newly worn attachment "pushes" a previous attachment at the same slot of the same attachment point (if any) "out of the slot".)-

Carlo [proposes|https://lists.secondlife.com/pipermail/sldev/2009-January/012624.html] to implement this by the usage of bit-masks