attach hud on rez

[Tattooshop]

Hello! I am making a script that allows to automatically attach (and later to detach) the HUD to the avatar if it was rezzed to the ground.

However, this only happens if the avatar first wears the HUD at least once in the usual way (right click-wear).

If the avatar rez HUD first, an invitation "... would like to: Attach to your avatar" appears but nothing happens.

It only happens when I give the HUD to my alt to test!

What am I missing?

integer ATTACH_POINT = ATTACH_HUD_CENTER_1; // HUD attachment point

default
{
    on_rez(integer n)
    {
        if (!llGetAttached())
        { 
            llOwnerSay("Please allow me to be on your HUD!");
            llRequestPermissions(llGetOwner(), PERMISSION_ATTACH);
        }
    }

    run_time_permissions(integer permissions)
    {
        if (permissions & PERMISSION_ATTACH)
        { 
            llAttachToAvatar(ATTACH_POINT);
        }
    }
    
    attach(key id)
    {
        if (id)
        {
            llSetRot(llEuler2Rot( < 0, 0, 0 > * DEG_TO_RAD));
        }
    }

    touch_end(integer total_number)
    {
        string button = llGetLinkName(llDetectedLinkNumber(0));
        if (button == "detach")
        {
            if (llGetAttached())
            {
                llRequestPermissions(llGetOwner(), PERMISSION_ATTACH);
                llDetachFromAvatar();
            }
        }
    }
    
    state_entry()
    {
        llSetRot(llEuler2Rot( < 0, 0, 0 > * DEG_TO_RAD));
    }

    changed(integer change)
    {
        if (change & CHANGED_OWNER) 
        {
            llResetScript();
        }
    }
}

 

[Qie Niangao]

What happens if the on_rez event fires before the CHANGED_OWNER is processed?

[Nova Convair]

What happens if you give it to your alt and the alt rezzes it?

on_rez - triggers maybe
changed - triggers and resets for sure
run_time_permissions - most probably never get's a chance to complete

1st - there is no guarantee that the events fire in a specific order. If you want a script that does not run by coincidence you need to code it so it runs in any order of events.
2nd - why do you reset it? there is no reason. The script overwrites the permissions every time it's rezzed. There is no owner variable and no open listens or anything else bound to an uuid. So the only reason to reset is to follow bad example scripts. 😁

[Tattooshop]

3 hours ago, Qie Niangao said:

What happens if the on_rez event fires before the CHANGED_OWNER is processed?

 

39 minutes ago, Nova Convair said:

What happens if you give it to your alt and the alt rezzes it?

on_rez - triggers maybe
changed - triggers and resets for sure
run_time_permissions - most probably never get's a chance to complete

1st - there is no guarantee that the events fire in a specific order. If you want a script that does not run by coincidence you need to code it so it runs in any order of events.
2nd - why do you reset it? there is no reason. The script overwrites the permissions every time it's rezzed. There is no owner variable and no open listens or anything else bound to an uuid. So the only reason to reset is to follow bad example scripts. 😁

Thanks very much! I removed changed event and it seems work fine!

 

[Tattooshop]

NM fellows! Its fine now! Fixed

(edited)

 

 

Edited December 23, 2020 by Tattooshop

[Tattooshop]

4 hours ago, Qie Niangao said:

What happens if the on_rez event fires before the CHANGED_OWNER is processed?

I tried changed event before on_rez event but it doesnt work

 

[Tattooshop]

THANK YOU!

[KT Kingsley]

In the script you posted, you request permissions in the on_rez event from the owner, which will be you. You need to request the permission to attach from the target avatar. Also, you need to need to target the chat message at this avatar rather than to yourself.

Once the object has attached itself to the target they become the new owner and this triggers the changed event with the CHANGED_OWNER flag set.

Telling the script who the target is generally requires opening a chat channel between it and the object that rezzed it. It's common to use the on_rez parameter to tell the rezzed object which channel to use, setting it in the llRezObject call in the rezzer script, which then starts listening and waits for the rezzed object to come on line and ask for the key of the target. When the rezzer replies the rezzed object can go ahead and ask the target for the relevant permissions. Other methods are available.

Edited December 23, 2020 by KT Kingsley

[Tattooshop]

On 12/23/2020 at 7:24 PM, Qie Niangao said:

What happens if the on_rez event fires before the CHANGED_OWNER is processed?

 

On 12/23/2020 at 10:40 PM, Nova Convair said:

What happens if you give it to your alt and the alt rezzes it?

😁

 

22 hours ago, KT Kingsley said:

In the script you posted, you request permissions in the on_rez event from the owner, which will be you. You need to request the permission to attach from the target avatar. Also, you need to need to target the chat message at this avatar rather than to yourself.

 

I have a related question. Is it possible to put on HUD on rez automatically without asking avatar permission? Thanks!

[Qie Niangao]

1 hour ago, Tattooshop said:

I have a related question. Is it possible to put on HUD on rez automatically without asking avatar permission? Thanks!

The script must *have* permission, so it must *request* it, but that need not require that the avatar be explicitly asked that request each time the attachment happens. One (probably academic) way to do that is to store the object with the specific intended avatar's PERMISSION_ATTACH already granted. The more likely useful way is to use Experience permissions and llAttachToAvatarTemp() so the avatar, having once granted permissions to that Experience, will be able to have objects seamlessly attached without further ado, anywhere that Experience operates, until the avatar revokes permission. This means you could piggyback on commonly-granted Experience permissions such as AVsitter's, and just define your [AV]object-scripted attachments as PROP1s in an [AV]prop scripted rezzer... but it only works on land where that Experience is enabled, and crossing to other land will cause the attachment to detach.

Besides avoiding asking over and over, llAttachToAvatarTemp's big advantage is that it doesn't clutter up the avatar's Inventory (even though it is transferred to their ownership while worn).