Talk:LlAttachToAvatarTemp

From Second Life Wiki
Revision as of 20:45, 28 October 2013 by Strife Onizuka (Talk | contribs)

Jump to: navigation, search

Possible Caveat about need to re-request permissions to detach objects

I've just been playing with this, trying to attach and detach items by script, and I think this may be worth a caveat.

I have made an rezzer that, when touched the first time, rezzes an object that asks for PERMISSION_ATTACH and, if this is granted, attaches to you temporarily. The second time it's touched, it tells the object to detach.

If I own the rezzer, then the temp attached object detaches without needing to request PERMISSION_ATTACH a second time. It simply detaches. That's as I would expect, since there's nothing in the script to remove the permission.

However, when my alt touches it, it has to re-request PERMISSION_ATTACH or the operation silently fails. And it's the same when I gave a copy of the rezzer to my alt. Then it needs to re-request permissions when I use it.

The permissions are silently granted once it's attached, but you do seem to need to ask for them. It took me ages to realise this was why another object I was testing worked for me and no one else.

My two scripts are <lsl> key av; integer toggle; integer avnumber;

/*user function by Kira Komarov http://wiki.secondlife.com/wiki/Key2Number*/ integer Key2Number(key objKey) {

   return ((integer)("0x"+llGetSubString((string)objKey,-8,-1)) & 0x3FFFFFFF) ^ 0x3FFFFFFF;

}


default {

   state_entry()
   {
   }
   touch_start(integer total_number)
   {
       toggle=!toggle;
       if(toggle){
           av = llDetectedKey(0);
           avnumber = Key2Number(av);
           llRezAtRoot(llGetInventoryName(INVENTORY_OBJECT,0),llGetPos()+<0.0,0.0,1.0>,ZERO_VECTOR,llGetRot(),avnumber);
       }
       else{
           llRegionSayTo(av,avnumber,"detach");
       }
   }

} </lsl> and <lsl> integer Key2Number(key objKey) { /*user function by Kira Komarov http://wiki.secondlife.com/wiki/Key2Number */

   return ((integer)("0x"+llGetSubString((string)objKey,-8,-1)) & 0x3FFFFFFF) ^ 0x3FFFFFFF;

} integer avnumber; default {

   on_rez(integer start_param)
   {
       if(start_param){
           llSetPrimitiveParams([PRIM_TEMP_ON_REZ,TRUE]);
           avnumber = start_param;
           llSensor("","",AGENT,20.0,PI);
       }
   }
   sensor(integer total_number)
   {
       integer i;
       while(i<total_number){
           key k = llDetectedKey(i);
           if(Key2Number(k)==avnumber){
               llRequestPermissions(k,PERMISSION_ATTACH);
               return;
           }
           i++;
       }
   }
   run_time_permissions(integer permissions)
   {
       if(permissions & PERMISSION_ATTACH){
           if(llGetAttached()){
               llDetachFromAvatar();
           }
           else{
               llAttachToAvatarTemp(ATTACH_LHAND);
           }
       }
   }
   listen(integer channel, string name, key id, string message)
   {
       if(llGetAttached()){
           if(llGetPermissions()&PERMISSION_ATTACH){
               llOwnerSay("got permissions -- don't need to ask for them again");
               llDetachFromAvatar();
           }
           else{
               llOwnerSay("haven't got permissions -- asking for them again");
               llRequestPermissions(llGetOwner(),PERMISSION_ATTACH);
           }
       }
   }
   attach(key attached)
   {
       if(attached){
           llListen(avnumber,"","","detach");
       }
   }

} </lsl>

Innula Zenovka 11:22, 19 August 2012 (PDT)

Yes, I would say the permission to Attach granted before the ownership change doesn't persist. The 'new owner' has to grant permission even though it was that same owner who already granted before the ownership change. Likely LL flushes this permission (and others) anytime a script changes ownership. This is a unique (and new) case where they are pre-emptively asking for permission before the avatar actually owns it. Could be a bug.

—The preceding unsigned comment was added on 11:51, 21 August 2012 by Darien Caldwell

That's exactly right. I have written an attach-on-rez script for an object with an animation in it. If I request PERMISSION_ATTACH|PERMISSION_TRIGGER_ANIMATION in the on_rez event, I get a script error when the script hits the llStartAnimation command after the object is attached, or if I try to detach the object with a scripted command. To beat that, I have had to put a second llRequestPermissions function call in an attach event and ask for both permissions again. The second time, they are granted silently.

Rolig Loon 19:55, 4 October 2012 (PDT)

Unexpected detaching?

I have made an object - let's call it Demo - that, when touched, attaches itself to the HUD Bottom of the toucher using llAttachToAvatarTemp(). When the toucher then detaches a DIFFERENT attachment (on the body or HUD), Demo detaches and is deleted. I see this in both Firestorm 4.2.2 and LL Viewer 3.5.1.

I cannot find anything that documents this behavior. Is it a bug, or an intentional undocumented feature?

Brattle Resident 10:14, 28 October 2013 (PDT)

Sounds like a bug. You should report it on Jira. In your bug report you should include the source of the scripts that reproduce it. Since you probably don't want to post your scripts (trade secretes etc) as they are, I'd recommend paring them down just what is needed to reproduce the bug. It's good that you are trying different clients but you also need to try regions that run different versions of the SL server software. It maybe that you are seeing a new bug. -- Strife (talk|contribs) 21:45, 28 October 2013 (PDT)

Failing to attach a no-transfer object to self

llAttachToAvatarTemp&diff=1173074&oldid=1171869 sounds like a bug. -- Strife (talk|contribs) 13:19, 5 October 2012 (PDT)

Temporary Attachments can't call llTeleportAgent

In case anyone had the same idea I had, that combining llAttachToAvatarTemp and llTeleportAgent would be a great way to make a teleporter that works between regions:

"Temporary attachments cannot request runtime permissions to teleport"

--Samm Florian 12:29, 17 July 2013 (PDT)

Well that is no fun. -- Strife (talk|contribs) 23:37, 17 July 2013 (PDT)