Whirly Fizzle commented at 2014-06-21T21:19:28Z

Heya Akaesha,

If you use LLAttachToAvatarTemp objects owned by others, do those also detach?

Please can you give the script you are using the temp attach the demos.

So far I have been unable to reproduce this, testing on Second Life 3.7.9 (290582) Jun 2 2014 18:53:52 (Second Life Release) on all server versions.

The script I used to test was:

default
{
    state_entry()
    {
        
    }
     
     touch_start(integer total_number)
     {
          llRequestPermissions( llGetOwner(), PERMISSION_ATTACH );
     }    
  
    run_time_permissions( integer vBitPermissions )
    {
        if( vBitPermissions & PERMISSION_ATTACH )
        {
            llAttachToAvatarTemp( ATTACH_LHAND );
        }
        else
        {
            llOwnerSay( "Permission to attach denied" );
        }
    }
  
    on_rez(integer rez)
    {
        if(!llGetAttached())
        { //reset the script if it's not attached.
            llResetScript();
        }
    }
  
    attach(key AvatarKey)
    {
        if(AvatarKey)
        {//event is called on both attach and detach, but Key is only valid on attach
            integer test = llGetAttached();
            if (test) {
                llOwnerSay( "The object is attached" );
            } else {
                llOwnerSay( "The object is not attached");
            }
        }
    }
}

Maestro Linden commented at 2014-06-23T17:41:39Z

I also can't reproduce this issue when I use Whirly's simple script. Akaesha, can you please provide the source of a simple repro script which demonstrates this issue?

Akaesha Revnik commented at 2014-06-24T16:32:33Z

thanks for the responses. This seems to be happening when the object is rezzed in real time via a rezzer to attach to a resident on demand. I am investigating this issue in detail as well. I suspect that this could be relevant to the object rezzing another object issue. It has worked for the last year and it still works for anyone except the owner as of last week or so. The object is attached to the owner and then removed automatically.

I will reply back with more information soon.

Akaesha Revnik commented at 2014-06-24T17:36:10Z, updated at 2014-06-24T17:37:17Z

ok I found the problem, after I attach the object I call a remove inventory " llRemoveInventory(llGetScriptName()); " to remove the script inside to minimize lag. But when the inventory remove call is made it also removes the attached object, but only for the owner (this behavior is new).

Here is the part of the script that causes the problem:

run_time_permissions( integer vBitPermissions )
{

    if( vBitPermissions & PERMISSION_ATTACH )
    {

        llAttachToAvatarTemp( attachPoint );
        llListenRemove(handle);
        llSetTimerEvent(0.0);

        //make the object visible
        //visible();


        llRemoveInventory(llGetScriptName());  //when this call is made to remove the script inside, it removes the attached object for the owner
    }
    else
    {
        //llWhisper( 0, "Permission to attach the HUD DENIED by "+llKey2Name(avatar) );
        llDie();
    }
}

Maestro Linden commented at 2014-06-24T18:01:32Z, updated at 2014-06-24T18:05:00Z

Okay, so the claim is that after an object attaches itself to the owner via llAttachToAvatarTemp(), a call to llRemoveInventory(llGetScriptName()) also causes the attachment to detach?

I can't reproduce that behavior when I modify the test script to do that:

default
{
    state_entry()
    {
         
    }
      
     touch_start(integer total_number)
     {
          llRequestPermissions( llGetOwner(), PERMISSION_ATTACH );
     }    
   
    run_time_permissions( integer vBitPermissions )
    {
        if( vBitPermissions & PERMISSION_ATTACH )
        {
            llAttachToAvatarTemp( ATTACH_LHAND );
        }
        else
        {
            llOwnerSay( "Permission to attach denied" );
        }
    }
   
    on_rez(integer rez)
    {
        if(!llGetAttached())
        { //reset the script if it's not attached.
            llResetScript();
        }
    }
   
    attach(key AvatarKey)
    {
        if(AvatarKey)
        {//event is called on both attach and detach, but Key is only valid on attach
            integer test = llGetAttached();
            if (test) {
                llOwnerSay( "The object is attached" );
                llSleep(5);
                llOwnerSay("Time to remove this script from the object..");
                llRemoveInventory(llGetScriptName());
            }
            else {
                llOwnerSay( "The object is not attached");
            }
        }
    }
}

1. Rez a box, and save the above script in it
2. Touch the box, and accept the permissions request
3. Observe that the box attaches to the left hand
4. After 5 seconds, the script announces that it's removing itself
5. Observe if the box detaches and if the script is still present
   After the last step, the script has removed itself but the attachment remains on my hand.

Maestro Linden commented at 2014-06-24T18:05:56Z

If you think this is a bug in the server or scripting engine (as opposed to one in the script itself), please provide full repro steps along with the repro script.

ObviousAltIsObvious commented at 2014-06-25T00:41:18Z

llRemoveInventory(llGetScriptName()); does not have an immediate effect, a few function calls can easily sneak through before the script is killed. To guard against the possibility of competing events that might be detaching the object, you could llSleep() for a second or two after the llRemoveInventory(), or switch to a do-nothing state, while waiting to die.

Akaesha Revnik commented at 2014-06-25T14:20:41Z, updated at 2014-06-25T14:32:28Z

here is the script. I trimmed it down to a reproducible point.
it is only happening on certain sims only including one of my sims 'Akaesha Island'.
If a listener is removed and the timer stopped the object detaches, but only for the owner.

Steps:
1-create a new object
2-create new script with the following code
3-Touch the object
4- object will attach and immediately dissapear

integer handle;
integer channel = -38117;
integer attachPoint = ATTACH_HUD_TOP_LEFT;
key avatar = NULL_KEY;

default
{
state_entry()
{

}
touch_start(integer num_touches)
{
    llRequestPermissions( llGetOwner(), PERMISSION_ATTACH );
}
timer()
{
    llSetTimerEvent(0.0);
    llListenRemove(handle);
}

run_time_permissions( integer vBitPermissions )
{
    if( vBitPermissions & PERMISSION_ATTACH )
    {
        llAttachToAvatarTemp( attachPoint );
        llListenRemove(handle);
        llSetTimerEvent(0.0);
        llRemoveInventory(llGetScriptName());
    }
    else
    {
        llWhisper( 0, "Permission to attach the HUD DENIED by "+llKey2Name(avatar) );
        llDie();
    }
}

}

Akaesha Revnik commented at 2014-06-25T15:07:12Z

Bug is seen on Regions that are RC Magnum 14.06.20 ( Akaesha Island 1000m up in the air)

It is working as intended on Second Life Server 14.06.13.2910 ( Two Worlds , 26m on the ground)

Whirly Fizzle commented at 2014-06-25T16:09:12Z, updated at 2014-06-25T16:22:17Z

This reproduces for me on Magnum regions only.
No repro on main channel, BlueSteel or LeTigre.

Also, it only appears to reproduce when attaching to a HUD point

Lucia Nightfire commented at 2014-06-25T16:20:59Z

Since an HUD slot is involved, it seems like this is related to https://jira.secondlife.com/browse/BUG-2301 which has recently bitten me hard with a demo product of mine.

Whirly Fizzle commented at 2014-06-25T16:23:12Z

I think its different Lucia. This repros with just a single default cube and its a 100% failure on Magnum regions only - and only fails for the object owner.

Whirly Fizzle commented at 2014-06-25T16:27:32Z

There was BUG issue filed by a Mole reporting something similar to this when testing exp tools, which only reproduced on experience tools regions (Magnum has exp tools). I cant find that issue now though, guess it got moved to an internal project. I'm sure Maestro will find it :D

Maestro Linden commented at 2014-06-25T17:31:40Z

Doh! Yes, I can reproduce this on Second Life RC Magnum 14.06.20.291356 with the test script in my previous comment. Yesterday I was on Second Life Server 14.06.13.291023, which is not affected (as Whirly said).

The original-owner-only behavior of this bug is bizarre; when the object attaches itself to a different avatar, the bug doesn't appear, even if the object is next-owner fully permissive.

Lucia Nightfire commented at 2014-06-25T17:54:07Z

Weird, I haven't been able to repro this bug with all the conditions.