Increased Attachment Functionality Needed

I think attachments are pretty droll.
Right now about the only things they can do are change their own texture, push, and rez.

We need more dynamic attachments!

Perhaps things like:

1. Attachments that are solid,
   
2. Attachments that can move on their own (like link children),
   
3. Attachments that can rotate (like link children),
   
4. Attachments that can link to non-attachments,
   
5. Attachments that can change their attachment points,
   
6. Attachments that can drop off/delink
   
7. Attachments that can be viewed in mouselook,
   
8. Attachments that can be detected (by llSensor())
   [/list=1]
   Now who's with me!
   (Feel free to add your own to the list if you want)
   
   ==Chris

I'd personally like to see Elbow and Knee attatchment points. Then again, maybe I'm a moron and just missed em.

I totally agree, we ned this

I'd be happy with more attachment points on the AV.

Excelent list! Any or all would be wonderful!

Multiple attachments on one point would be nice.

Physical attachments could get very ugly.

We badly need the ability to rotate/move attachment parts.

I don't even mean solid or physics.. just the ability to use a script to change the position of attachments.

There are a lot of us out there that want to make various attachments move.. like my blinking eyes, and lots of people have moving wings and tails.

The problem is this is all done with texture animations, which means lots of extra objects and tons of texture swappong, all which is very bad for rendering time.

It would make many people happy, and decrease the server and client load.

What could be wrong with that?

I've noticed llSetScale DOES work on attachments. In fact, it works better than it does on link children in the world. There's an update problem there that the constant updating for animations the avatars have fixes. I'm planning on doing a lot of tests along these lines this week.

Wow this thread is old! I still feel that it needs a bump, since attachments' functionality hasn't changed at least since beta.



I personally want 2 and 3 at least, since attachments can already change scale, what's the problem with giving them the freedom to move and rotate?

EDIT: Added quote for clarity.

I hadn't thought about this till seeing this old thread you brought back Christopher, but more attatchment points would be great! If you want to go Rollerblading and put on knee pads and elbow pads, now you have to either have them built into your clothes or have some weird long phantom part attatched far away that stretches to your knees and elbows.

Never saw this Chris Lord knows I agree! I don't really need more attach points...

...I just need attachments to work like everything else!!!!

Please lindens let us play with our attachments...

pretty please rotation & movement at least?

I endorse these features/ideas.

really have nothing to add other than that at this point.

I'm all for the list. Having them drop when they detach would be cool.

Adding attachment points would require changing the skeleton, mesh, & the animations.

This is no easy task.

Want an idea of the work?

avatar_lad.xml
handles av size, meshs, animations that manipulate the meshes, and attachment points.

avatar_skeleton.xml
governs the general skeleton.

121 animation files.


While it would be very nice to have extra attachment points i would love to see llSetPrimativeParams re-enabled for attachments first.

While attaching multiple objects to a single point sounds like a nice idea it screams for abuse. It should be limited to 255 prims per attachment point, the same as a single linked object. Script commands would be needed for detecting the number of attached objects per locations.

I would like to add to the list

9. Attach object via script from the users inventory by UUID. llAttachUserInventoryObject(key uuid, integer attachment)
(this should probably be a client side functions so that the server doesn't go into deep think with large inventories. IE the server asks your client if the object is in your inventory before attaching it.)

10. Script commands for identifying attachments.

Yeah attachements now are a weee bit limited.

bump*

plz plz PLEASE!!!!

But if you didn't change the skeleton to add new attachment points, then the animations wouldn't need changing and the only file that would need changing would be avatar_lad.xml, the game core & script interface. Wouldn't be so bad

I support all of this. And multiple attachments per point. And more attachment points (neck, elbows, knees, each fingertip, eyebrows, forehead, each cheek (yes, those cheeks too), tongue, teeth, left right and middle nose).

Good, good...more attachment functionality == good.

And this completes my pwnage (spam-age) of the feature suggestions forum for today. Have a nice day.

add me to the list of people who think this would be good

I heartily endorse this product and/or service.

*tailwag*

wow i was noob when i last posted on this topic and guess what? we still need these.

Requests for specifically located and named attachment points would be a never-ending saga for LL unless this issue is generalized.

All they need to do is to provide a single deterministic traversal algorithm for their av meshes (it might as well be in LSL), so that "vertex N" can have only one meaning both for them and for us.

Then, give us just one function taking as argument a list of attachments plus a vertex number N, which refreshes the state of attachments on that vertex. We can then hand it a null list to strip all attachments from any vertex, or add any number of layers.

Hey presto, dead easy for us to configure whatever we like, within whatever constraints they might wish to impose on the process in terms of list length and in terms of total number of attachments per av. The order of items in the list should reflect the order in which attachments are put on, in the expected way, for control of visibility.

Personally, I wouldn't mind even if the constraints were greater than we have currently, because this solution is more flexible than what we have currently. However, since the old scheme must continue for backwards compatiibility, the constraints they'd have to impose would have to be very tight. That's fine with me.

Give people generic interfaces and the requests for change won't come in so frequently.