Detach HUD on Detaching Attachment

[EnCore Mayne]

the title should say it all, haha. if not, please allow me explain.

i've got a HUD attached using the on_rez() event:

    on_rez(integer rez)
    {
        if ( !llGetAttached() == 0 ) 
        {   
            llOwnerSay("HUD not attached");
        }
        else
        {     
            channel = llGetStartParameter();//from start parameter in garment's llRezObject function
            llOwnerSay("HUD channel = " + (string)channel );
            llRequestPermissions( llGetOwner(), PERMISSION_ATTACH );     
        }
    }

the run_time_permissions is:

    run_time_permissions( integer given )
    {
        if (given & PERMISSION_ATTACH)
        {   
            llAttachToAvatarTemp(ATTACH_HUD_CENTER_1);
            llSetTimerEvent(1.0);
        }
        else 
        {    
            llOwnerSay( "Permission refused" );
            llDie();
        }
    } 

the llSetTimerEvent() is an attempt on my part to follow a similar code for attaching/detaching a HUD when the avatar stands from an animation posestand. as such:

    timer()
    {
        integer iIsSitting = (llGetAnimation(llGetOwner() ) == "Sitting" );
        if ( iIsSitting != iWasSitting )
        {
            if (!iIsSitting && (llGetPermissions() & PERMISSION_ATTACH) )
            {
                llDetachFromAvatar();
            }
        }
        iWasSitting = iIsSitting;
    }

that works a treat, but, on this occasion the avatar's not sitting. is there any way to adapt the timer event to sense when the garment/attachment gets detached?

if not, can someone suggest how (if it's possible) to accomplish this feat?

[Qie Niangao]

Not sure I'm following the details, but to start: once an attachment is detached, there's just one event that will fire, attach(), with a NULL_KEY as its parameter rather than the key of the avatar to which it was attached. In handling that event, there's still time to do some stuff (like signal other attachments to detach, maybe?) but not a lot of time: once an attachment is detached, its scripts don't run anymore. There's no chance a timer() event will fire after the item is detached, until it gets attached again.

But again, I'm not sure this is quite what you're doing. If there are two different attachments involved where attachment A is supposed to detach when attachment B detaches, one way is that messaging from B to A (B can just llRegionSayTo its owner on an obscure channel and all attachments get the message on their listen() handlers), or B could monitor llGetAttachedList() to see if A is still there—which is way less efficient and takes preparation for B to infallibly recognize A, etc., but may be necessary if you can't modify the A object.

If these are attached by llAttachToAvatarTemp() there are further considerations, but maybe that's unnecessary complication at this point.

[EnCore Mayne]

kk, so if i read you right, the timer's a no no.

if you're confused as to what's being done i'll follow your A B scenario.

the avatar wears attachment A which rezzes B (HUD) on the ground using the llRezObject() in A.
B (HUD) pops up a permission to attach dialog.
on accepting that permission it's attached as a HUD.

all that's fine so far but i need some code to detach the HUD when A is detached.

as far as my limited skills go your option attach() seems simple enough for me to bang my head about. i just have to set up a listen in the HUD to sense the attach() going NULL when A is detached?

[Quistess Alpha]

Stripping out all the irrelevant stuff, @Qie Niangao's suggestion is roughly:

//attachment:
gChannel = <some number>; // many different ways of syncing this between the 2 things.

default
{  attach(key ID)
   {  if(ID)
      { // was attached.
      }else
      {  // sending a message to an avatar relays it to all their attachments, 
         //  if you've stored the key of the rezzed HUD, send to that instead.
         llRegionSayTo(llGetOwner(),gChannel,"I'm detached.");
      }
   }
}

// HUD
gChannel = <the same number>; // must be the same between HUD and attachment.

default
{  /// where this goes depends on how you sync gChannel
   llListen(gChannel,"","","I'm detached.");
   ///
   listen(integer channel,string name, key ID,string text)
   {   llRequestPermissions(ID,PERMISSION_ATTACH);
   }
   run_time_permissions(integer perms)
   {  if(perms&PERMISSION_ATTACH) llDetachFromAvatar();
   }
}

Which as he points out,  has a possibility of not working if the region is too laggy.

Another option is to keep the HUD and attachment in a communication loop: (rough sketch)

//attachment:

listen(...)
{   llRegionSayTo(ID,Chan,"Pong");
}

//HUD:
gPonged=FALSE;

listen(...)
{   gPonged=TRUE;
}
timer()
{   if(!gPonged)
    {  // detach.
    }else
    {  llRegionSayTo(ID,Chan,"Ping");
       gPonged=FALSE;
    }
}

 

[EnCore Mayne]

genius!

only change i had to make for the first option was to change the HUD's listen>requestperms to having the llDetachFromAvatar() in it. my runtime already had the attach perms.

thanks again, both to you and Qie. any pose animation you have in mind, it's on the house.

[bobsknief Orsini]

As alternative you can also not use a listener at all and stick to a timer using https://wiki.secondlife.com/wiki/LlGetAttachedList with https://wiki.secondlife.com/wiki/LlGetObjectDetails.
One requirement however would be that you know for example the name of description of object A.

[Quistess Alpha]

6 hours ago, bobsknief Orsini said:

As alternative you can also not use a listener at all and stick to a timer using https://wiki.secondlife.com/wiki/LlGetAttachedList with https://wiki.secondlife.com/wiki/LlGetObjectDetails.
One requirement however would be that you know for example the name of description of object A.

an important caveat is that you can detach the HUD when the object is detached with that method, but not visa-versa: HUDs don't show up in the attach list

[Qie Niangao]

Also, FWIW, an open listener on an obscure channel is way more efficient than using a timer, especially a timer that calls and wades through the results of llGetAttachedList. I only mentioned it before as a way to monitor for detachment of an object that cannot be modified so there'd be no way to make it communicate with the monitoring script.

It must be possible for a detaching script to run out of time before emitting an "I'm detached" message, but I can't say I've ever seen it myself.