This would also make SL more friendly to those with less innate building ability. Example: If you want your avatar to have a face full of piercings, but are not good with the edit functions, you will currently be in a lot of trouble when trying to adjust the fit of a large set of piercings. From a design standpoint, breaking the jewellery up into smaller sets (1 nose ring, 2 separate earrings, 2 separate eyebrow rings, 3 separate lip rings, 1 nose bar, 1 ear industrial, etc.) makes more sense, and is much more user friendly. The problem is the user runs out of attachment points too quickly. Something that increases attachments will please designers and users alike.

This way we have the same overall limit, but no restriction on where we can put things.

A piece that angles to be between the two would be INCREDIBLY useful for creating prim stomachs for a full-prim avatar =(

I would love to be able to wear nails AND a ring or two AND pick up and hold something.

This sort of thing is realistically unlikely to happen unless a group of devs had the time and resources to commit to it and took it, as well as related avatar enhancements, under an "umbrella" as a project to work on. The same sort of thing applies for other "big wishes" on the Issue Tracker, so feel free to action them similarly.

So "Needs More Info" here refers to being more specific about a proposed design that the majority of you can hopefully agree on. "I want more attachments per point!" is a lovely idea, but to make it realistic and actionable, we have to collectively figure out how we'd want to make this happen... then the appropriate Lindens can take a look and reply in kind. Thanks.

If there is a continued interest in this, I can help with the design process. Just IM me.

Here is a link to the wiki

http://wiki.secondlife.com

Additional attachment points:

1. Tail: an attachment point pivoted at the pelvis, but with the same angle as the spine.
2. Neck: an attachment point pivoting in the neck.
3. Belly or Lower Back: pivoting in the lower body, angled between the hip and the spine.
4. Fingers: like Hand, but pivoting as the hand is open and closed.

You can very easily see all worn items by entering "(WORN" in the white search text area at the top.

Still, a body inventory tab could be very handy.

My only concern with this request is that I like the fact that wearing an item that attaches at point X replaces the current attachment. A possible way around that is to change the right-click menu for inventory objects and folders from having simply "wear" to both "wear" and "wear also".

"wear" would work the same way it does now. Any attachments at the given point would be replaced. Any instructions for wearable products would continue to be meaningful.

"wear also" would add the new item to the attachments at that point.

This poses the question, what should happen when we use "attach to" – should we also have "attach also to"? I think that's more complexity than necessary, and "attach to" could have either behavior by default (the current 'replace', or changed to 'add') and it would be fine, since we only use this when setting up a new object.

Instead of one attachment per point, we can have any number we want per point, but a limit to how many attachments we can have in total. I don't think that part is hard.
The other part of the suggestion is quite simply a set of folders in a special tab that shows what you're wearing and where on your body it is attached, making it much easier to view and manage attachments.

I'm re-opening this because dev-time or not it's a big request and I see no reason to shove it to one side when the solutions are relatively simple.

Yes please, more attachments. SL's economy will soon come to a grinding hault if I have to stop shopping.

I'm gonna resolve this again as "need more info".

The actual feature request (a very popular one) is having more attachment points or attachments per-point, as seen by the number of votes this issue is very popular and as such should be left open so it can be seen by anyone wanting to add their votes to it.

It is in no-way resolved or in suitable need of closing.

Thanks for creating the sub-task though.

As for actual implementation, as far as I understand it, each attachment point on an avatar has an entry in the avatar's data-object, these then store a key identifying what is attached to these points.

A much better system would be to simply have a list of finite size which lists all attached objects with a constant identifying where on the avatar they are. e.g:
Key: 12345
Location: NOSE

This allows for much more flexibility in where items can go as there is no limitation, and it would only require a single list opposed to one for every attachment point. It would even make it easier to handle attachments as you only have to go through the list of items that are actually present, rather than looking at each attachment point to see if there is anything there.

If the current system even vaguely resembles that already then it shouldn't be difficult to adapt to allow for multiple attachments, and with the UI as shown it wouldn't be especially hard to use (and default behaviour can remain as is with the attachment replace dialogue asking if you want to add, replace or cancel an action.

I'm not sure I like the idea of making a special-case new inventory tab just for this. I'd rather see a new window specifically for attachments and clothing currently worn. Dragging a folder into this window could trigger wearing the items in it. There already IS a window for clothing in the debug menu, although it's rather rudimentary.

But I figured a simple hierarchical folder structure would be easier to do to start with, and would hopefully open things up a bit for any budding Open Source UI coder to play around with to create such a design.

Multiple attachement point would also be greatly cheered by the furries, who due to the way their avatars function, have even LESS roon to add attachments.

The idea that I came up with is this:

Allow multiple attachments per attachment point. I thought 5 (we have 5 fingers - 1 ring for each).

The Edit -> Detach Object -> <location> menu would open another menu (this code already exists) for which attachment in that particular location.

Take Off -> Detach -> <Location> would open another pie menu (code already exists) for which attachment in that location.

New attachments at a location would just drop into the first available slot.

This would give full backwards compatibility with attachments already created.

Except for allowing 5 times the attachments as previous, this should be quite workable. With the advent of sculptie prims, prim counts for each attachment should be dropping though (I am in the process of building a sculptie cat avatar - head is only 3 prims).

1. "12345-1234-123145-12313" AVATAR_HEAD
2. "31231-1231-156373-12313" AVATAR_LEFT_LEG

Currently I imagine what we have is that each location (head, left-leg etc.) has a 'slot' and whatever key in that slot is what will appear there. This is not very good as expanding it requires more slots to be added that may or may not contain anything. If we had a simple list then all the viewer has to do is go through each entry pulling out the key, looking at the integer constant and placing it in the correct location. The overhead of doing this should be little or no more intensive than we have currently.

To avoid ridiculous sizes of attachment lists we just put a limit on how many you can have, of 31 (the current maximum).

@Tofu Linden
As noted, extra attachment points isn't ideal in the slightest. We already have the space in our unused attachment slots, they just need re-organised into a more useful and flexible data format to make multiple attachments per-location perfectly feasible.

More than absolubtly ANYTHING, we need multiple spots on the hands.
A hard limit sounds like a good idea, but as we currently have 29, I'm stronly opposed to the reduction to 20 that lex proposed.

if it's feasible, 36 would be a nice number.
I also agree with the notion that a hard prim limit would be a bad thing, and lead to lower quality work. although it shouldn't be too much of an issue with sculpted prims.

We also should have "attachment point objects" which are inventory objects that have the X, Y, Z, and orientation data of an attachment (so we can have an easy way to attach different things in the exact same way)

One other one that I still haven't had a chance to mock-up yet is one in which the view changes to that of the appearance menu, however at the same time all other UI windows are hidden, your inventory window appears on the right (showing only objects and clothes) and a number of small windows appear next to attachment points, allowing you to see which point has what even more quickly (and more visually). May require some attachment points that are basically the same (pelvis and stomach for example) to be combined into a single mini-window.
This one would however be in addition to the full-overview attachments tab since that does not require the avatar to stop moving to tweak attachments.

I'd like to point out that there is that with the technical notes I've mentioned there is zero technical reason why a limit of 3 per point would be desirable, especially if the interface can support unlimited without too much trouble.
Yes, an overall limit is needed to prevent ridiculous avatars with a kazillion primitives on them (and to reduce the payload of avatar data), but increasing a limit that isn't necessary means it's still around to cause problems =(

The Wiki entry is here:
http://wiki.secondlife.com/wiki/Bug_triage/2007-10-09

Femina. more attach points is a seperate issue. As I understand, it's fairly trivial to add, though. ANd Havok 4 has nothing to do with attachments. It won't make the slightests difference in that regard.

Secondly i was referring to the ability of havok 4 to deal with the physics of increased prims and complexity on an avatar, not to deal with the actual attach points.

So thank you for giving me the opportunity to show all women are not as stupid as some men seem t think they are.

@Femina
You're right in a sense, but this issue is more specifically about adding multiple attachments to the existing attachment points. This /COULD/ be done by adding duplicate attachment points (Chest 2, Stomach 2 etc.) but this issue is aimed at achieving more attachment points without the memory/transfer overhead of doing that.
i.e. - this issue proposes that I should be able to have two or more attachments on attachment point "Chest", while you propose that we have more attachment points for the same location. VWR-1065 is the major issue for additional attachment points.

We'll keep it open; if any Open Source contributors want to make headway on this, you're most welcome to.

Personally, I'd be just fine with something like this:

(1) Allow two objects per attachment point. Yeah, I know some people would prefer three or five – but like you said, performance issues. (Maybe someday when we all have 8-way multiprocessors with 64Gb of RAM, graphics cards capable of rendering a trillion polygons at 60FPS, and 10-gigabit optical fiber directly to everyone's house... 'Til then, you've gotta draw a line someplace.)

(2) Implement Haravikk's suggestion, above, about what should happen if a scripted object tries to replace items on an attachment point, to try to keep from breaking existing items. (Obviously won't be 100% successful, but what is?)

(3) The user interface for attaching things could simply add a submenu to each attachment point, so that when you select an object, the sequence would become Attach To -> [body part] -> [primary / secondary]. (Or "[1st 2nd]", "[Alpha / Beta]", "[Attach A / Attach B]", or whatever other name strikes your fancy. The point being, each existing attachment point effectively becomes two points, while still keeping the menu reasonably sane and nonintimidating for newer users.)

I can't help but think that this would cover most situations easily enough. Yes, I know some would prefer a more flexible and arbitrary system of "X objects, attachable anywhere", but that does seem, to my admittedly limited understanding of how SL's internals work, to present serious implementation issues on a number of fronts. A simple "two-per" system would seem to be something that could be implemented relatively easily without having to rip out large sections of existing code or tie yourselves into knots figuring out how to make it backwards-compatible with existing scripts and objects.

More information or a transcript of the internal discussion would be very useful.

So, for example... You right click an attachment and simply press "Attach" and then do "Place on: ..." and choose a body point. Then we can just have a fixed attachment limit (I propose something like 50), allowing multiple attachments in the same place.

If you can attach to an arbitrary location on your avatar then that becomes more difficult, the UI also would be a lot more complex.

Also a note; attachments are irrelevant to the physics engine, they are treated as phantom extensions to your avatar. Only your avatar itself can collide with things.

When I said "(and physically attach to like they do now, so that physics still work)", that is what I meant in relation to the skeletal locations. Doing "Place on" will make the attachment act just like it would if it was attached to that location (so it will point in the right direction).

When I said "physics" I didn't mean actual physics - I meant what you said. Sorry for not being clear, I couldn't think of the right terminology at the time.

As for an arbitary location, I intended for that to simply 'follow' a point on your avatar, such as your hand. Could be any, it doesn't matter. By that I mean for invisible attachments you just simply use for their functions. This isn't important if you can place things on the same attachment point. I could just simply stick lots of these invisible attachments onto my Left Upper Arm for example.

I would like to see moveable mount points for things such as rotating weapons, juggling, throwing, etc.

VWR-1925 proposes a folder structure that represents your avatar and its attachment points, allowing you to drag attachments to and from the relevant folders in order to attach them, or remove them.
VWR-4063 is similar to the folder idea, except that it presents the user with a view similar to the appearance view, giving you floater windows corresponding to body locations, with an inventory window of attachable/wearable items for you to choose from.
VWR-6057 is a different take on the folder-mannequin idea that presents individual attachments with 'bubbles' pointing to the attachment. These allow attachments to be quickly removed, while the inventory window can easily add attachments.

As always, alternative ideas are welcomed. If someone has an idea for a user-interface for multiple attachments then please feel free to add a sub-task and give us a quick summary as a comment here!

• left brow (prim eyelashes, eyebrow rings, alternative location to wear sunglasses if you're wearing a nosering)
• right brow (ditto above)
• forehead (for tiaras, headbands, hats, whatever)
• NECK (! I do not know why this isn't in already, necklaces are a very common thing!)
• left breast (for nipple rings, prim bras/bikinis, etc.. i'm sure guys could wear armor and other things here too)
• right breast (ditto above)
• tail (for furries, nekos, etc.. this would basically be a central hip attachment point)
• left knee (knee pads, good for armor sets or sports sets)
• right knee (ditto above)

Those 9 points would already help dramatically, even if we cannot have multiple attachments per point. However, if you can add a secondary set, that'd be very nice as well! However, just simply adding more points sounds easier in a technical standpoint.

1. Objects that have script/effects we want, like a flight ring/band, but have to trade with something else, since we already "have" an attachment at that point.

2. The need, for non-humans, or just for descent looking humans, to use some of those attach points to "fix" themselves, so they don't look dorky.

3. Its not terribly convenient to move some items to a new location to "fix" them.

Issue #1 - Could be resolved by having "hidden" attach points on the prims themselves. If someone wants to make an ear that has an "attach point", then you could attach an item there, as though the ear slot was free (no recursion though, just on level), but the "prim" and any effects that depend in its shape would "not" be displayed. Something like a multi-tool, which attaches at that point wouldn't "need" to be visible to operate. It wouldn't need to be adjusted, changed, etc. either. It could show up as a "hidden prim" when viewing those, but not be editable unless you detached and rezzed it normally.

Issue #2 - We badly need either better baseline characters, or some baseline "options", which can be adjusted the same way the existing one can, but lend themselves to making something different than humans. You might not need to many. Most non-humans are going to have legs that bend differently than people, most will have muzzles, etc. It may be possible to morph canids and cats between those extremes, lengthening or shortening the muzzles. Things like how the hands and feet appear would be as simple. You would probably only need humans, feline-canid, lizard-alien?... Not many at all really. By having decent start models, in a small set of types to pick from, you reduce the number of people drastically changing themselves with attachments (most of which only kind of, sort of, work anyway).

Issue #3 - This is just simple math people. If you know what the "normal" angle(s) and position(s) for an object "should be" at an attachment point you do the equivalent of:

revert_object_to_origin(prim)
rotate_to_attachment_angle(prim)
translate_to_attachment(prim)

This is done all the time in programs like POV-Ray for inverse kinematics, where you need to "temporarily" revert an object to the origin, so you can rotate/position it around center, before placing it back where it needs to be. Though, in the case of POV-Ray, you would actually be doing something like:

rotate_at_origin(object)

Since you don't actually want to move it any place, just adjust it as though it was still on its own "center". In SL, you actually need to revert it entirely, then reorient it to the new attachment location. Even if it was off a little, it would save "a lot" of time trying to fix it.

Please LL, make this happen. Fix your more critical problems first... like, say, the asset server. But this should certainly be up there in your ranks of priorities.

As far as I can gather the simulator isn't the issue, it supports multiple attachments per point already. The only issue therefore is that there is no obvious way to represent this new feature to the user so that they can take advantage of it. To this end we have three sub-tasks presenting different ideas, please do view them and vote for ones you like or leave comments, or add more yourself if you have another idea how it could be done!
LL seem happy to give us an interface re-skin that we don't want, but not a new interface option that we DO want =/

And re: the priority change and a general explanation for why, please see https://jira.secondlife.com/browse/WEB-659

Many multifunction HUDs (Omicron, Psitec) have incompatible APIs for building plug-ins to mix-n-match functionality, which is needed because the number of HUD attach points is in limited supply just like the body attach points.

If you could have more than one HUD attach per point each function might be able to live on its own. Folks already attach HUDs and then displace them visually far from where they are nominally attached, but end up filling them all.

People REALLY want this feature, and as stated it seems not to be such a truly difficult thing to implement. For this reason serious discussion is now needed on how to present this feature to the user (which seems to be the only missing link), not on whether or not it will be implemented. Indecision on LL's part is not an excuse, residents have already decided for you, it's your jobs now to figure out what implementation is best technically, and balance this with one that is easy for people to use.

Otherwise we might as well close down the JIRA if voting is to be just ignored like this.

the issue of performance isnt apparent on first glance, but I believe it is a valid one, but I do have a solution for this too. the following system was suggested:

• as many attachments per spot as one likes
• to balance, the number of total attached objects may not exceed the number of base attachment points, allowing you to still just attach the same amount of prims to you as before

the issue with the above solution:

• by thus making "popular" attachment points more useless, people will attach more things they didnt wear before hand, for lack of space on the relevant spot. this will increase the overall load of attachments to a degree

solution or at least partial solution:

• the attachments arent also capped by 31 total attachments, but also may not exceed 255 prims per attachment point

this should ease some of the performance issue i would hope, and give especially us furries an easier time in equipping our avatars, and im sure many others will also feel the relief.
what is still to be decided are special use cases, as presented here:

• the user wears a dress with a prim skirt
• they want to replace their dress with another, also featuring a prim skirt, thus select a different folder and choose "add to outfit" to replace redundant parts
• this may lead to them wearing dual prim skirts. is this behaviour to be assumed as default then, so that switching outfits should exclusively be done by using "take off items" first and then adding? the inconvenience is mild, but I thin it is worth discussing this issue at least

I'd like to know the details of the performance issues. Without this, we don't know whether the issue is the number of attached prims or the number of attached objects, or even if there really would be any performance hit from allowing, say, 64 total attachments. I would be surprised if calculating the motion of a rigid body attached to the avatar skeleton really is that expensive compared to what else the client is doing.

@Nue Broome:
I'm not sure we need additional attributes to deal with this. The add versus replace issue is more of a user-interface challenge I think, as the user will know which they want. It's not really for developers to say to users that they can only wear one skirt, or that they can't wear any other attachments with theirs. Who knows, someone might aim to achieve a particular effect by wearing multiple skirts to create a layered effect.

So long as it is obvious to the user what will happen then it shouldn't be much of an issue either, provided they have the controls they need to get what they want. So really we need in the menus:

For a simple item:

• Attach/Add -> <location>; simply attaches the item to the desired location in addition to anything else there.
• Replace -> <location> -> <item>; lists only occupied locations, providing options to replace a single attachment, or all attachments at that location.

For multiple items/a folder:

• Add to outfit; adds items at their default locations, in addition to anything already there
• Replace attachment(s); adds items to outfit, if any of the locations are taken then all items there are replaced
• Replace attachments; removes all existing attachments, adding the new ones on

This should provide us with a good mix of options; along with a good interface (please see the sub-tasks on this issue for ideas) this can allow straightforward manipulations. The main question though is what to do with the default behaviour of "Wear". My thoughts are to have it as an option somewhere, whereby you can either leave it set to "Replace" (replaces all attachments on that point by default, existing behaviour) or change it to "Attach/Add".

It show a sample picture of the body with a box/button where each attachment can be placed. When you click on the button, a list of objects on that attachment is shown on a listbox below the picture. Where you can choose to add/remove it as you wish.

I'd say... I agree with the attachment limit, since we don't want people using it in the wrong way to lag us all... but I think... we should use a few more attachment limit than what we have...
I guess... maybe 5 attachments per point... and instead of 30 maxium attachments, put a limit to... for example... 40 or 45 (not counting huds, huds affect only to our own performance, not anybody's else), which is not that high and wouldn't limit us that hard, then if we have reached the limit and we want to wear something more, get a message box saying "You have reached the limit of possible simultaneous attachments. Detach something else".

I think it would be a good idea, and people wouldn't be limited without killing performance. Maybe we don't need a limit of attachment per points, since we are already using a maxium number of simultaneous attachments...

Well, you get the idea.

Also I'd like to hopefully see things like mouth1/mouth2 which attach to the same base point, but would allow me... say, to have a sucker in my mouth and also have large fangs poking out (due to the sucker not being a full time attachment). Think this would save the trouble of people needing to copy objects just to link them to whatever (and in effect would reduce some inventory clutter.)

...but actually I guess the best idea is still being able to add more than one object per attachment point... would be the less restrictive way.

There are however some new attachment points that would be useful, such as a proper neck attachment point, or an /actual/ stomach attachment point that corresponds to the stomach "joint" on the avatar. The current attachment point named "stomach" is actually just a copy of the pelvis attachment point, which, while useful for tails etc., isn't great if you want a stomach section for a full-prim avatar =(

Multiple attachments are so very much needed. Ever tried to wear a gauntlet and a sword at the same time? How about two rings on the same hand? How about wearing a belt, armor and a tail at the same time? Unless the items are modifyable, can't be done.

Linden Lab, if you want to please your customers, it would be good to consider issues like this... issues that have received massive votes... and see what you can do about accomodation.

I am always the first person to point out the need to fix bugs rather than adding new features. But this feature has been requested for so long (far longer than the year this JIRA post has existed) and there are so many people who want this feature, it might be well to consider. Someone once suggested having 5 attachment points per body part. That would be just about right.

There are so many things that are needed on this system... such as an internal sculpty creator/painter... a tool for measuring script overhead on individual objects (that would really help in reducing sim lag)... the ability to upload full songs and have them play on one's land parcel (stored in-world and played from inventory rather than streaming from an external computer-- see Kaneva.com)... the list goes on and on. If you're going to have two dev teams... one for bugs and one for new features... myself, I'd like to see some features more useful and valuable than eye candy.

Multiple attachments per attachment point. That's one of the useful ones. ; )

Has my vote.

I would love to see multiple attachment points introduced, I have a number of items I want to attach to my avatar, but I can't because some of them use the same slot, eventhough they appear in different places. I also hate that when ever I try to use an object in my hands/paws one of the paws is replaced by the object. When I'm finished using it, I have to detach that object the re-attach my paw, I know it doesn't sound like much, but it is a pain after a while and would be resolved if multiple attachment points were introduced.

Quoting Torley Linden:
----------
Haravikk, thanks for emailing me about this. I don't currently check PJIRA much as I mainly work on video tutorials and Second Life skills education, so I appreciate the heads-up. Aye, this continues to be a wanted issue; I noticed that internally, we marked that we're not working on it currently and don't have foreseeable plans to. I'll ask our Resident Experience Team if there's any other info we can share, too.
----------

There's a few things that are proving to be the real hangup, at least from a developer's point of view. A) There's not a consensus as to how to actually implement it (the comments keep going back and forth and it's obvious that some people aren't reading what came before) and B) regardless of implementation, it would take potentially a very long time to implement due to heavy code changes.

So, here's my attempt to submit a proposal that will work.

Before I begin, a bit of definition:

ATTACHMENT POINTS are only potential places where something could be attached to. In essence, it is the list of available areas that could be used for attachments.
ATTACHMENT SLOTS are what actually tracks what items go where; it is this which tells you how many total objects you can have "equipped" at any one time. Attachment slots don't care what attachment point they get assigned to, either.

More attachment points are desirable because there are quite a few places that would be handy to have as attachment points - e.g. individual fingers, wrist, left/right nipple, neck, left/right eyebrow, upper/lower lip, left/right nose, a true stomach point, pelvis point, waist point and so on. All this means is defining additional places things could be attached, not necessarily adding slots.

The next part is actually allowing for more total attachments. Currently, there are 30 slots in total, and each attachment point receives one slot. I would propose taking that 30-slot limit and doubling it to 60, and allow for any number of slots to be "spent" on whatever points the user deems necessary. So, for example, if an avatar has 5 attachment slots available, they could distribute them across five different points or use them all on one point or any combination in between.

Both are necessary because there are problems putting together complete avatar sets that work with the "one slot per attachment point" system we have now. Objects become conflicted. For example, I have no way of wearing a necklace or a set of prim breasts at the same time unless one object or the other has been edited heavily to work, and even then it may look odd when I try to walk or move. The new attachment points allow everyone to work on things that can go different places; while the raised attachment limit allows you to basically have more things on you, which would ultimately fix the problem, I think.

After that it's just a case of getting the viewer to handle the change in attachment format (again I think it supports receiving multiple attachments for a single point, they just don't persist if you teleport atm). Then we change the attach/detach menus to have a further sub-menu listing all of the items on a particular point.

Then we add in a UI to make the whole thing simpler for everyone, with the possibility of scripted support in the future (for now the behaviour of scripts would be maintained for compatibility's sake). There are now several sub-tasks showing possible UI ideas, all of which are mine so far, if others do have an idea then PLEASE post it!

It's hardly a mammoth undertaking for such a widely demanded feature; the technical aspect of it is neither demanding or complex. The biggest hurdle is just in presenting it to the user in an intuitive way so that we don't end up with newbies wearing their entire inventory and unable to take it off. I for one would be happy with any of the sub-tasks presented, though currently favour the "Bubble mannequin" one.

The thing that galls me most is that Windlight got a whole team to it but wasn't really wanted, yet all this feature needs is a short design phase and one or two developers. This is a case where Linden Labs really needs to look at the proposed ideas and decide for themselves which is the ideal solution to the problem; everyone posting here may prefer a slightly different solution, the Lindens just have to get a few people with the right experience together and pick one.

I mean, this issue predates the damned JIRA! This proposal alone has been here for over a year.

The slot should be chosen as "the first one avaible, the one that I decide to attach", automatically, because if it was about fixed slots, then the rotations/positions would be lost, objects would still replace others without us noticing it, and would be frustrating having to re-rotate everything...

My idea, as I posted before, would be a unlimited slot list... and a maxium of 40~45 simultaneous attachments... then, when something is going to attach to a part that is already used by another attachment, it is still attached, just in a different slot...

...Although, now that I think about it, I don't know what would be easier for developers... but if the changes are going to be the same, I'd rather having the idea I posted... but still I could live by rotating/positioning everything (is still better than having just 1 slot per point). I'd just choose an special slot for "Hand objects" or "Hat/Random head crap"

Honest, we do need more attach points...or the ability to attach more independent objects.

Also, if possible, permitting object rezzing for only one of the attachments on a specific bodypart at a time. That would be helpful too. It could also allow for the use of more than one weapon with a toggle, as long as both scripts aren't active at the same time.

As it is, 31 guns in one hand is possible: One per attach point, moved and rotated to overlap in that one hand.

This is something the lindens really need to implement anyway, some avatar types and even general attachments, tools, clothing and the like are getting heavier and heavier on the attachment points.

Solar, Iexo,

Guns can be pointing backwards they'll still shoot fowards, it doesnt care where they're attached, they even work attached to HUDs as far as I remeber.

31 guns in one hand is not possible, unless the animation was static and didn't move/change, or if all the guns were linked together (what can only be done with the correct permitions).

So lexo, whats the fuss? It doesn't matter if you can attach multiple griefing tools, if X or Y was smart enough they'd bundle all the scripts and projectiles of however amount of weapons into one object, attach it to their HUD and cause chaos.

However, I'm not saying this is a bad idea, I'm merely advising caution, and that provisions should be made to prevent greifing. Perhaps a maximum of two or three attachments per point, or a way to turn off object rezzing from all but one attachment, so that the only way to wear more than one functional weapon on the same hand is to toggle them, sling one and draw the other.

I know this can be done, object rezzing is turned off on no-build sims, and anything but vehicle scripts are disabled in no-script zones, so clearly the ability to stop rezzing specifically, or halt certain scripts and not others exsists in SL. Applying it to certain attachments could take an extra bit of work, but it should be doable, and would be well worth the effort.

Don't cripple good uses just cause the game developers are lazy, if there is any game where you're concerned about it, talk with the developers and ask them to adapt the api for the meters and such so they can detect how many guns avatars got on etc

Second, let's recognize that limiting attach points does nothing at all to prevent RP combat cheating. "It's quite simple".

If you think your GMs can find out what capabilities an avatar has by inspecting the avi in their viewers, you're deluding yourself. As has been pointed out, it's not at all difficult to build a God-mode weapon that uses only one attach point. And is invisible. And is displaced to some difficult to find location.

SL isn't WoW...and let's not turn SL into WoW, OK? My opinion is: if you don't trust someone not to cheat on your combat system, don't play with them. Winning an RP combat by cheating is a special case of the "winning an argument on the internet" meme...and the outcome is the same.

For another, I'm not suggesting they limit attachment points to one, merely use caution. Just because it can be done other ways doesn't mean we should add yet another, especially coinsidering that all of those ways require a little bit of doing, this would not. This is something that any Ahern n00bizard could do just by wearing one weapon over and over again.

Basically, it's just to remove yet one more avenue of dishonesty. Just because people can kill their computers by downloading spyware-ridden software from shady download sites, and visiting sleazy sites they saw in popups hasn't stopped Microsoft from patching holes in Windows when they can. Likewise just because people can cheat in other ways doesn't mean we should just let them cheat this way as well.

As I said, I'm not trashing the idea. I voted for it, after all, I'm simply saying that some manner of safeguard should be incorporated into it. We all saw what happened the last time LL made a big change without a safeguard, when they allowed unverified accounts. Suddenly everyone had 15 alts, and trash alts were crashing sims en masse every day. There always have to be safeguards, or there are problems.

That's at least my opinion. I don't want any kind of limitation on this.

Oh, and just to correct something I stated above:
There are really 3 attachment points at the moment, but it's 30 at the body and 8 at the HUD (not 31 and 7 as I stated)... I just counted them again.

I'll repeat, don't cripple good uses just cause the developers of the particular game you're interested in are lazy/unskilled/dumb/naive/whatever

The same applies to "RPers who consider combat system cheating to be griefing".

You can claim to "consider" anything to be anything else you like, but words have meanings. Having many more attach points is not a vulnerability by any serious measure. 32 total per avi has been suggested. Also 32 per attach point. We'd like more group slots too, shall we claim that limitation is a "spam protection"?

IMHO the biggest hazard to many more attach points is the UI considerations; it needs to be easier for the user to manager their attach points.

Handling combat exploits is therefore already the burden of the combat-systems and Linden damage-model, this issue will not make it any worse.

@ Maggie: If you're speeding and kill someone, it IS considered Vehicular Manslaughter.

why do I have to keep repeating myself? complain with the crappy combat game makers about this, don't cripple good uses

However, if multiple attachment points are allowed with no restrictions, cheating would be as easy as making 20 copies of a weapon, and wearing them all. Any newbie could do it. It's so easy, it could even be done by accident. Moreover, it wouldn't be immediately apparent. Projectiles would rez in the same line, the weapons would perfectly overlap, and there would be no visible clue that multiple weapons are being worn, except that the wearer would have an unfair advantage, and one that would be impossible to spot. This would make RP combat in SL pointless, everyone would use 20 guns at least on the same hand. SW, Ordo, and all the military groups that rely on combat systems of any kind would be crippled, and sims would be crashed.

Whether or not you view this as a threat, it's a good chance LL will, and it's a good chance that, unaddressed, this threat would kill any plans they had for going ahead with this feature. Instead, I'm offering a suggestion on how to deal with this problem. A suggestion that would not only make this feature practical, but would also hopefully make it more palettable to LL.

Nor does adding additional requirements to a feature does not improve how attractive it is to an implementer.

Maybe you should look into the Restricted Life viewer...

(I can actually tell the difference between speeding and vehicular manslaughter. One is a summary offense and the other a felony, and for good reason. Isn't it nice that one can't be turned into another by sloppy thinking?

"You teach yourselves the law. I train your minds. You come in here with a skull full of mush, and if you survive, you'll leave thinking like a lawyer." --Professor Charles W. Kingsfield Jr.)

Please answer this question. Am I wrong by assuming you're not nagging the gun/meter/system makers of your favorite combat systems to be sure people can't use more guns they're allowed to, anywhere nearly as much as you are us?

@Tigro: This feature doesn't exsist yet, it's still on the drawing boards, but tens of thousands of weapons and hundreds of combat systems do. It's difficult to cheat with these RP systems. It requires effort, and it's usually identifyable. It would be so easy with this feature, if a safeguard isn't implimented, that it could be done by accident. Moreover, I am not nagging you, I'm offering a suggestion to the Lindens that may be looking this over, as to how it could be made more attractive. (And yes, Maggie, LL DOES care about whether or not a feature can be used for greifing, one of the reasons we don't have mega prims, alpha as skin textures, and other things.)

You two arguing my suggestion does not help this issue, your case, or SL in general. All it does is adds controversy that may only serve to scare Lindens away from the subject. After all, you know how much Lindens LOVE to get involved with personal drama. So, do us all a favor and leave my suggestion be. I have my opinion and I've expressed it. You have your opinion and you've expressed it. Let it go, and get on with your lives.

this "griefing" concern of yours, it would be easilly fixed by the people that make the games you're talking about.

If the system is using no-mod weapons, one of the many easy ways to deal wtih this would be a script kinda like:

//written straight into the comment box on jira, haven't tested yet, I might have let minor details slip
default
{
state_entry()

attach(key id)
{
if(id != NULL_KEY)

}
listen(integer chan, string name, key id, string msg)
{
if(llGetOwnerKey(id) == llGetOwner())
{
if(msg == "attached")

}
}
}

if you test it, let me know if I let any detail slip, though I'm pretty sure the idea behind the script is clear enough

@Iexo: And as I said, if the combat system accepts every kind of bullet for damage (not only "licensed"), it basically is already gamed. There even is already a HUD that specifically targets combat meters.

And even without that HUD... I could wear 8 guns (Or rifles, or rocket launchers) on my HUD, and NO ONE would ever notice, even through they'd be fully functional. They'd be invisible to everything. Add a ninth in my hand, and it looks as if I'd shoot normally, while I was in fact shooting nine bullets at once. And this is even without editing... If they're mod weapons, I could resize them and move them into my body - Again, unnoticeable, even for "Highlight Transparency".

Those tricks are basic stuff, and anyone even remotely interested in cheating in an RP probably knows this. So, the only ones stopped by your suggestion are new ones, while something which might actually be used by others for constructive things gets blocked.

(Yes, I'm mostly repeating what others said before, but mostly because it seemingly got ignored/wasn't noticed...)

In discussing the question, he used to liken the case to that of the boy who, when asked how many legs his calf would have if he called its tail a leg, replied, " Five," to which the prompt response was made that calling the tail a leg would not make it a leg. – "Reminiscences of Abraham Lincoln"

Like people said before, that "cheating" can be done already even without modify rights. You can simply attach a huge arsenal of weapons to your HUD, move them away of it and you are a perfect serial killer, and there goes your cheating without multiple attachments per point...

@Maggie: Cheating at RP is considered greifing to RPers. Just because it isn't for you, doesn't mean it isn't for them, and it also doesn't mean that it doesn't concern LL.

@Everyone: What is the problem with having a script error when two attachments specifically on the same attachment point try to rez things at the same time? If you're working on something constructive, surely you can devise a way to make the same prim, or at least different prims in the same object, rez things simultaniously. Why is it so necessary to have TWO attachments on the same attachment point that rez things at the same time? What purpose could that possibly serve BESIDES cheating?

Two or more objects, by different creators. No way to sync them up. And I wouldn't want to permanently switch rezz permissions between several objects, just because their creators destined them for the same attachment spot.

Those who'd be stopped by this would loose interest in RP anyway, even through cheating. They wouldn't stay for long, and would be by far the minority of "griefers".

If a user wants to attach multiple weapons, then they can already do so, it's ridiculously easy, it's a completely invalid concern. Whether the guns are attached all over your body or concentrated on your left-nipple is IRRELEVANT. If the combat system can't throttle damage in a meaningful way, then it is fundamentally flawed and USELESS. Get a better one. It is NOT HARD for a combat HUD to track the source of damage, and throttle it to X amount of damage-per-second, or better yet, completely ignore (and undo) damage from a player who is causing a suspiciously high amount of damage.

This feature will not add griefing to your precious RPG combat systems that they aren't already open to right now. Any newbie can go out, buy a few small weapons and hide them inside larger attachments, most weapons fire from generic locations anyway so no-one would be the wiser. If a combat system can't handle cheating, then it's just asking for people to exploit it, this feature won't make that any worse. Hell, it adds more to RPG simulators then it could ever possible detract from them; we'll finally be able to have proper sculpted non-human Jedi in Star Wars sims, werewolves with weapons in fantasy sims etc. etc.

Please drop this discussion about RPG simulators; it is not a valid concern for this issue! Hell, any scripted system that doesn't try to consider possible future issues, or provide a way that it can be updated if issues do arise, is again fundamentally flawed. We cannot halt progress just because someone's badly scripted device might break!

If not, I hereby "consider" the act of "referring to RP cheating as 'griefing'" to itself be griefing, so you have to stop now.

In fact, everything I don't like is now officially griefing, so everybody knock it off.

@ Haravikk: The idea isn't to completely prevent them from attaching multiple weapons, but to prevent them from using two weapons simultaniously that are attached to the same attachment point. That way, some Ahern n00bizard fresh from help island can't take a gun, make 20 copies of it and attach it to the same spot, and thus make an undetectable, invincible superweapon in less than 30 seconds. They'd have to work at it to cheat, like they do now.

@Maggie: I consider your open and vocal contempt for my opinions, and subsiquent attempts to stifle them with insults and condescension to be greifing. You must stop now.

@Everyone: For the third time, my suggestion (and that's what it is, nothing more) is not a crusade to stop greifing or cheating, nor to change anyone's mind on which this issue pertains to, as Maggie seems to think it is. The purpose of my suggestion is to prevent this PARTICULAR feature from making cheating alot faster, easier, and less detectable than it is now.

After all, just because law enforcement can't stop ALL the crime in the country doesn't mean we should fire all the police and do without. Likewise just because we wouldn't be stopping cheating all together doesn't mean we shouldn't bother making sure new features can't make it easier.

Given the plethora of combat systems and their widely varying notions of what constitutes "cheating", I find it to be bad software design to reify one small use-case by nerfing otherwise useful avatar capabilities.

Don't expect the SL platform to enforce your metagaming rules for you. That's not what it's for.

It's hardly enough to warrant crippling some functionality.

http://nwn.blogs.com/nwn/2009/02/the-ultimate-combat-avatar.html

Second, I would like to state that this would not prevent cheating or greifing, nor would it enforce any rules. All it would do is make the exsisting rules easier to enforce. This is important because LL is always concerned about the potential for cheating or greifing. It's the reason for the grey goo fence, and our lack of megaprims. However useful this might be, whoever it may or may not effect, it would likely make the feature more attractive to LL.

And really, come on. What use could there POSSIBLY be for multiple objects rezzing things from the same attachment point, EXCEPT cheating with no-mod weapons? Any legitimate use for multiple rezzing could easily be fulfilled by making multiple prims in the same object rez the different items. After all, you'd be building the item. The ONLY possible use this ability could ever have is allowing people to easily and undetectably cheat with no-mod weapons, and they wouldn't even need to be an hour old in SL to figure it out.

(And a side note to Icon Allen: This isn't to deal with the obvious gun greifers, but rather help with identifying not so obvious instances of stacking multiple no-mod weapons on the same attachment point. A problem with a similar effect, but that would not be as apparent to an observer, or a GM, yet would be considerably easier than alternatives.)

And lastly, I'd like to reiterate, this is MY opinion. I am free to it without harassment, as are you. Flaming me or my opinion can only hurt this cause. Now that both our opinions have been stated, just let it go, and move on with your life. After all, in the end, this issue and it's developmental pursuit aren't your decision or mine, it's all up to LL. Whether they like your idea or mine, we have no say beyond stating our opinions and allowing them to read them. Any further argument is moot.

Do feel free to wander off now, Iexo. We don't need this feature nerfed, thanks.

Second, it should be of note that you started this ...debate... And mind you, I use the term loosely. You have been hardly civil about it, despite multiple requests. If this issue is nerfed, it won't be by my doing.

In short, after you.

Yes, LL is concerned about griefing, when it comes to actual sim stability or grid stability. Hence the grey goo fence.
Free megaprim creation is locked til code is in place that keeps prim edges from overlapping into other parcels, if they are no-rez / no-enter.
Basically, to prevent random newbies from creating huuuge prims everywhere. Unintentional or intentional distruption of the maingrid.

However, LL does not do any kind of enforcement of user-made rules, combat systems or the like. They never did, they probably never will. They haven't even fixed their own combat system, where, after months and months and months, one still can instantly become undefeatable by sitting on a phantom prim. So much for that.

So, your analogy that LL tends to stop cheating of any system is quite flawed. They care about sim stability and public peace, and that's mostly it. Not somebody cheating at some random user-made combat system. Once they start doing that, it'll open up a huge can of worms where every system creator might come running to LL, asking them to put mechanisms in place to prevent cheating X or Y for their new best thing.

Here's hoping for implimentation, though, lotsa neat stuffs we could do with this, from wearing paws with weapons to wearing multiple weapons that can be switched out on the fly by command, to adding weapons or addons to exsisting avatars on points already occupied.

P.S. A side note to LL's combat system: It sucks. Call the Nobel prize comittee, that last revalation was an earth shaker. xþ

From what I understand of the technical side (no help from the Lindens at all), the original proposal here would work just fine, there are several perfectly usable UI ideas added as sub-tasks and we've covered ways to handle compatibility with current scripts, and changes to the menu. All the information as I see it is already here, and covered to death. If the Lindens can't make a workable feature from the ideas and insights here then what the hell /can/ they do? This issue has hundreds of votes, it couldn't be more obvious that there is demand for it yet it is being ignored without any good reasoning for doing so!

In your approximate to this folder "C:\Program Files\SecondLife\character", find a file called avatar_lad.xml.

Guess what it defines attachment points, but hold on its not that simple. While its true you can clone an attachment this way fairly easily, there is a problem in the client doing it this way... if you do add a custom one you will need a new custom id number for it (for LSL I am guessing). All things considered.. should make it 40 or greater (technically 29, but 40 sounds better).

Say we add the following
<attachment_point
id="40"
group="6"
pie_slice="6"
name="Pelvis 2"
joint="mPelvis"
position="0 0 -0.15"
rotation="0 0 0"
visible_in_first_person="true" />

Not to bad, it looks right to us on our viewer, for me it even looks right on another viewer on my same computer, I don't know if it looks right on another system however. Yes it was this EASY to do. it works in the RC for me... LL might of been planning to surprise us and drop this on us with a gotcha.

I cannot be sure the ID is unique though. Since id="40" is also something called "Male_Head" and it may cause conflicts, my avatar is female so I am not sure if that matters for me.

Now before the LL secret police come to take me out (or delete this comment), use this at your risk, I cannot be certain it always works for everything in every viewer for every avatar etc. I just found it silly to have the attachment points defined in a file and not be able to clone an existing one if I gave it a unique ID.

the avatar_lad.xml way works fine with the viewers that use this modified file, however AFAIK all other viewers by other people will not show those additional attachments.

So it seems the technical side is all there, and actually has been for a while now, I think an earlier comment here may even have mentioned it, but the real issue is how do you give users access to it? Designing a good interface for managing these things isn't trivial, but a number of good ideas have been provided already.

@ Anastasia: That's also a great idea. From rings to actual MOVABLE paws to ...well, any number of things, finger attachments would be a really good idea. I'm surprised noone's mentioned it before, thank you.

Edit-
@ Iexo: I see what you mean with that. I suppose the alternative would be more points? either or. but I would have to say that cheating is not only reason for having more points. there are a considerable number of people (I included) that have custom avatars that use attachments to define the characters looks. being able to maintain that look while attaching say a backpack. or a purse or lets even say scuba gear, becomes an issue. lol I personally would feel awkward going around with only half of my avatar just so to scuba dive. Takes away from the fun. =p

so whether it's by allowing for 2 attachments per point, or adding more points or maybe even adding more points only in certain places. I dunno. But this is a big issue that LL really should get heavy research into.

edit edit -
I just looked in that Avatar_lad file and every single head attachment is on the same joint "mhead" o_o. I could be looking at this absolutely wrong bust this looks like it's so easy to change. Not unless there are a mess of bones with the exact same name?

edit edit edit (lol) -
ok so I tried that snippet and it does indeed work at least in my RC version. other viewers don't see it true. but being as how it does in fact seem possible, may be we could address this in pieces? my thought is this. perhaps decide on what points can be safely duplicated without major issue hands and forearms may be off limits for now being that those are usually what holds weapons but what about every where else? could the chest, spine, stomach, and pelvis be given duplicate points to start? just thoughts.

PS: All of this is only in RC 1.23 that I'm using.

I still think the most practical idea would be having an infinite amount of possible attachments per point, that means, no limit if you for example want an entire avatar in a single slot, and just limiting the max number of simultaneous attachments, let's say, for example , count all attachments we can wear now +7, for example.

However, if you right click the "attached" prim you will be presented with the option to detach it, as well as pull up avatar info, gestures, appearance, and edit like any other attached prim. The only difference being that it's not moving with you. This of course I attribute to the hacked attach information not being there. The client and server knows it's there, but just doesn't know where to put it.

@Shakeno-
That would be a cool Idea, but we're seeing a system that is already in place and is merely just a desicion left to be made on the part of LL. I'd say let's go with what is already there so LL doesn't have to do that much more work.

tested on: Second Life 1.23.3 (122255) May 30 2009 13:13:41 (Second Life Release Candidate)

and what happens if you create a new HUD attachment? without the hud attachment point present would the attachment get rendered in world?

Quite honestly, I seriously think this can be eeeeeeeeasily done and LL is just sitting back smiling with a cup of coffee and waiting for us to settle on something before they just press "enter" and publish it lololol.

i already made my avatar, and hers, have TWO chest attach points "chest" and "chest 2" by giving them slot id 39. I plan to make all attachment points have 2 sub-slots, (chest,chest2,chest3)and release the XML file to the public with instructions to install it.

the only drawback is that since it's a user-side mod, everyone else sees it wrong.

they see the attachments on your hip or so, but if you give them the file to install, and they relog, it fixes it, and your attachments work fine for them.

the only downside i can see here is that some (few) attachments have a script that detaches them if they aren't on the right attach point (left_hand).

and unlike what someone said earlier, the attachments are moving fine. Her newly hack-attached collar is going everywhere she goes, and not having any displacement issues.

but then, i have the same patch file she has.

Cross-posted from VWR-1065, posted by Ray McKeenan:

This is taken from a Readme that is in a Zip file called attachments and it says that it gives114 attach points. The link is here <link removed, obsolete, see bottom of post> I have it and I love it.

this is simple to explain, but if you