Talk:LlAttachToAvatar

From Second Life Wiki
Jump to navigation Jump to search

Note that llAttachToAvatar will fail if the avatar is not the owner of the object being attached, even if permission to attach has been granted. --Dilbert Cleanslate 16:00, 23 February 2007 (signature added)

llDie or llDeleteFromInventory or llAttachFromInventory?

There is no functionality that I can find for cleaning up a user's inventory after rezzing an object from a Prim's inventory and attaching it. Repeated use of the object and attachment results in a clutter in the user's inventory of the rezzed/attached object. There seems to be no way for a script to rez the "attachment" from the users inventory or even check to see if it exists, which might allow for the rezzed object to be killed (llDie()) and the one existing in User inventory to be recycled instead.

If there are any workarounds for this it would be greatly appreciated as to how to approach it. --Melany Lunasea 09:49, 11 August 2008 (signature added)

You could make it no-copy, if it's ok for it to be transferable. --Sayrah Parx 14:03, 15 June 2010 (UTC)
there are no solid workarounds for excess attached items from prim inventory gives yet... in some case you can include hidden prims in the originating item and instead of rezzing the item from inventory create it in place with the extra prims.
-- Void (talk|contribs) 05:01, 17 June 2010 (UTC)
Before llSetLinkPrimitiveParams (and Mono) Jesrad Seraph and I worked on a script project that achieved just this. For a while we were working on a 3D web specification. You can find the last published version here: [1]. Due to memory constraints the code was highly optimized and features had to be chosen very carefully. Our uses for the scripts diverged and so development forked, as there just wasn't enough memory in LSO for the script. It's one of only a handful of situations where Recursion made sense. The bytecode cost of using a loop or unwinding was greater than using a recursive global function, furtunately there was enough memory at runtime to temporarily support the stack depth required. It was during this time that the list = (list = []) + list + other; hack was discovered (as it was the only way that I could keep the script from stack-heap'ing). A big problem with that implementation of TLML was that it was so expensive to move an object from one simulator to another; an object may very well contain 100 slave scripts. If I were redoing the project today I would just use llSetLinkPrimitiveParams, llLinkParticleSystem, llSetLinkTextureAnim and only support a limited number of sit targets with a few smart slaves. -- Strife (talk|contribs) 20:29, 19 June 2010 (UTC)