[sldev] Proposal for Extending the number of attachments perattachment point.

Boroondas Gupte sllists at boroon.dasgupta.ch
Tue Jan 20 04:13:09 PST 2009


Rob Lanphier schrieb:
> [...], and given that associating bits with objects is
> involved, is going to be a tough sell.  It could just be that the
> proposal writeup is more complicated than the actual feature.
The think main idea of the proposed feature is relatively simple (as a
UI concept, not talking about implementation here):
Up to now an item replaces another one iff 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 iff 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".)

The whole bit mask stuff would be a (back-end/internal representation)
implementation detail the user wouldn't have to bother with, if I've
understood Carlo correctly. (Please correct me if I'm wrong)

Boroondas



More information about the SLDev mailing list