Detect Wearer Upon Teleportation

[joniveehernandez]

Hi Guy's, I'm trying to detach object when I teleported to other regions in order to achieve that I used changed event, but the llDetectedKey() seems not working and I noticed the value of my global variables I assigned before teleporting also been removed. Is the script reset itself? I didn't put a an reset code on my script.

or there's another way to detach the attachment object. what if the parcel you telerported is "script not allowed" and "building/dropping objects" enabled.

- Thanks! :matte-motes-smile:

[Qie Niangao]

The llDetected*() functions only apply to certain events (sensors, collisions, touches, etc.), so it won't work in changed(). I'd have to see the script to figure out what's happening with the gloval variables, but to answer the question, no, scripts don't reset themselves on teleport unless they're scripted to do so.  (There is a persistent and intermittent bug in the llTeleportAgent*() functions that can crash the script, requiring a manual reset, but I doubt that's what's happening here.)

You mention build-enabled land; a script cannot "drop" an attachment, only detach it so it stays in inventory. The no-script parcel setting, however, is pretty much universally overriden in attached scripts by calling llTakeControls() -- which call must occur somewhere that scripts are allowed, but then that script will keep running on no-script land.

[EDIT: Oh, I just noticed the thread title, which is no doubt the reason for the llDetectedKey() call: you want to know who's wearing the attachment. Once you know the object is attached, one simple way is llGetOwner() because an attached object always belongs to the agent to which it's attached (even with llAttachToAvatarTemp). Of course, the attach() event itself passes in the key of the agent, so that can be stored in a global variable--once we figure out what's happening to those.]

[joniveehernandez]

Hi Qie, You got a point using llGetOwner() and thanks for pointing that, below is my script, before I'm using the variable "id" this is what I understand declaring global variables (correct me if I'm wrong), first the touch event will detect the key who touches the object this is where I store the UUID to the variable "id", so that I can use it again in changed event.

Now I revised the script with llGetOwner() in changed event below:

 

integer is_teleported = 0;
key id; // NO LONGER USE

default
{
    touch_start(integer total_number)
    {
        llRequestPermissions(llDetectedKey(0), PERMISSION_ATTACH);
    }

    run_time_permissions(integer permission)
    {
        if(permission & PERMISSION_ATTACH)
        {
            if(is_teleported == 0)
            {            
                llAttachToAvatarTemp(ATTACH_HUD_CENTER_1);
            }
            else if(is_teleported == 1)
            {
                llOwnerSay("Is Teleported!");
                llDetachFromAvatar();   
            }
        }
    }
    
    changed(integer change)
    {
        if(change & CHANGED_REGION)
        {
            is_teleported = 1;
            llRequestPermissions(llGetOwner(), PERMISSION_ATTACH);
        }
    }
}

The problem is it doesn't detach itself even teleported into a place where scripts and object dropping is allowed. I know the script above works accordingly, because I noticed when teleported into a region that scripts and object dropping is allowed. I right click the HUD to detach but upon right clicking without even clicking yet the "detach" menu, it detach itself. That means the llDetachFromAvatar() is triggered or this is some sort of bug?

[Rolig Loon]

You're right.  The HUD detaches on TP, sort of, but it doesn't disappear visibly. It just stops functioning.  When you right click on it, the HUD finally disappears.  I'm not sure I'd call it a bug, though.  I think you're doing something that's confusing the servers. When you are teleporting from one sim to another, you and your HUD are being transferred from one server to another.  If you try to detach the HUD in the instant of that transfer, it may not be clear which server is supposed to be in charge --- so the function fails.  Here's a similar script that works ....

integer OnMe;default{    touch_start(integer total_number)    {        if(!OnMe)        {            llRequestPermissions(llDetectedKey(0), PERMISSION_ATTACH);        }        else if (llGetPermissions() & PERMISSION_ATTACH)  //Manual detach        {            llOwnerSay("Detached by touch.");            llDetachFromAvatar();        }    }        attach (key id)    {        if (llGetAttached())        {            OnMe = TRUE;            llRequestPermissions(id,PERMISSION_ATTACH); //Second request, needed for detaching        }    }    run_time_permissions(integer permission)    {        if(permission & PERMISSION_ATTACH)        {            if(!OnMe)            {                            llAttachToAvatarTemp(ATTACH_HUD_CENTER_1);            }        }    }        changed(integer change)    {        if(change & CHANGED_REGION)        {            if(llGetPermissions() & PERMISSION_ATTACH) //Detach triggered by TP            {                llOwnerSay("Detached by teleport");                llSetTimerEvent(5.0);            }        }    }        timer()    {        llOwnerSay("BEEP!");        llDetachFromAvatar();    }}

You need that second llRequestPermissions in an attach event because ownership changes as the HUD is attached, and the previous permissions are dropped. Other than that, the logic is similar to your script, except that I have built in a delay after you teleport, after which the HUD will detach.  If I shorten the time to 1.0 seconds, I still have trouble, but 5.0 seconds is overkill.  I suspect the "best" delay depends on how responsive each sim's servers are.

[joniveehernandez]

Thanks Rolig, I tried your script and it works, only if the region where I teleported must allow scripts and building/dropping objects. example of that is... if I teleport to a region with limitations below it will not work:

 

[Innula Zenovka]

in order to keep the script running in no-script areas, you need, as Qie suggested,  to request PERMISSION_TAKE_CONTROLS and, in the run_time_permissions event, to call llTakeControls.

This should keep the script running in no script areas (it's intentional, so vehicles and AOs, for example, can always work).

Try something like this (it's just a fragment, obviously, and needs combining with your script):

 

default{	state_entry()	{		llSay(0, "Hello, Avatar!");	}	attach(key attached)	{		if (attached){//need to take permission_attach again because of the change of ownership			//llRequestPermissions(attached,PERMISSION_TAKE_CONTROLS,PERMISSION_ATTACH);  WRONG!			llRequestPermissions(attached,PERMISSION_TAKE_CONTROLS|PERMISSION_ATTACH);		}	}	run_time_permissions(integer permissions)	{		if(permissions & PERMISSION_TAKE_CONTROLS){//needed to keep running in no script areas			llTakeControls(CONTROL_FWD, FALSE, TRUE);		}	}	changed(integer change)	{		if(change & CHANGED_REGION){			llSetTimerEvent(5.0);		}	}	timer()	{		if(llGetPermissions()&PERMISSION_ATTACH){			llDetachFromAvatar();		}	}}

 

[Rolig Loon]

Just remember ...

To request two or more permissions at the same time, use the bitwise OR (|) operator, e.g.:

llRequestPermissions(AvatarID, PERMISSION_TAKE_CONTROLS | PERMISSION_TRIGGER_ANIMATION)

[Rolig Loon]

@OP --- FYI, you may want to follow Cerise's comments in this thread in the Building/Texturing Forum >>> http://community.secondlife.com/t5/Building-and-Texturing-Forum/Object-I-created-not-staying-attached-sometimes-becomes-glitched/m-p/1734033#M7911

[joniveehernandez]

Thanks Innula for giving me an idea, I mixed all your suggestions in this thread and come up in an idea, because this HUD is temporary, I decided to do a little trick where in the attached HUD is not really detaching itself.

- When the wearer changed region I'll set a timer what Rolig said, as my first way of getting rid with the attached HUD, when the timer event triggered I'll make the HUD transparent and off-screen so even its invisible it will not block the screen of the user.

- Second is using llTakeControls if the user moves the HUD it will automatically make transparent and off-screen.

 

These are my ideas getting rid with the right-click bug (if is it a bug) and to overcome the "scripts not allowed" and "building/dropping objects not allowed". I think the "building/dropping objects not allowed" also affects the detachment of the HUD.

 

~ Thanks Guys!