llRequestExperiencePermissions

[Edu Csak]

I'm using the wiki provided script for llRequestExperiencePermissions and I've notices it's works on the SECOND try 
First try NEVER ever works. The object rezzes then nothing else happens. Then I try again and it works
Can anyone, please explain to me what's wrong?

https://wiki.secondlife.com/wiki/LlRequestExperiencePermissions

You can check inworld if you're online http://maps.secondlife.com/secondlife/Tenerona/191/9/2148

Edited May 18, 2022 by Edu Csak

[Edu Csak]

I guess I've solved putting a llSleep(5.0); between llRezObject and llRegionSay

[NardweBones]

If you can send me the original script possible stripped down to the glitch you are encountering we can try to make a bug report and see if it is really an issue and hopefully get it fixed!

 

[Lucia Nightfire]

7 hours ago, Edu Csak said:

I guess I've solved putting a llSleep(5.0); between llRezObject and llRegionSay

Sounds like the problem is unrelated to llRequestExperiencePermissions().

I suggest posting a bare bones script that repros the problem so that the brilliant minds here can tell you what is really the issue.

[Quartz Mole]

If you're trying to send a message to the rezzed object, to give it the key of the resident whose experience perms the object is to request, then it's always safest to have the object ping the rezzer in the the on_rez event to confirm that it's rezzed successfully, opened a listener and is ready to receive messages.

Never rely on an object being able to hear messages as soon as it rezzes -- always have it ping the rezzer first, because there can, depending on what else is happening on the region easily be a second or so's delay before it's ready to receive messages and the simulator is ready to deliver them.

 

[Quistess Alpha]

If anyone feels like modifying the wiki page posted in the OP, I'd recommend sending the rezzed HUD the hash of the person to attach to via its rez parameter, then having it sensor for them:

default
{
    state_entry()
    {
        llVolumeDetect(TRUE);
    }
    collision_start(integer NumberOfCollisions)
    {
        integer i = 0;
        for(; i < NumberOfCollisions; i++)
        {
            key give_to = llDetectedKey(i);
            llSay(0, "Rezzing HUD for " + (string)give_to);
            llRezObject(llGetInventoryName(INVENTORY_OBJECT, 0), llGetPos(), ZERO_VECTOR, ZERO_ROTATION, llHash(give_to) );
        }
    }
}

 

// Example script for LSL Experience Tools attachment

// This script runs on an object that is rezzed in-world which gets
// an Experience permissions and then attaches to an AV.

integer target_hash;

integer log_spam_channel = 0;       // Change this or remove llSay() commands

default
{
    on_rez(integer start_parameter)
    {   // Start listening for a message from rezzer
        target_hash = start_parameter;
      	llSensor("","",AGENT,5.0,PI);
        llSay(log_spam_channel, "Test HUD has been rezzed");
    }
    
    sensor(integer n)
    {   // Listen for the message from the rezzer with the target agent key
      	llSetTimerEvent(0.1); // if no-one detected; time-out quickly.
        while(~--n)
        {   if(llHash(llDetectedKey(n))==target_hash)
            {
              // Ask for the experience permission
              llSay(log_spam_channel, "Trying experience permissions request.");
              llRequestExperiencePermissions(llDetectedKey(n), "");
              llSetTimerEvent(60.0);
            }
        }
    }

    experience_permissions(key target_id)
    {   // Permissions granted, so attach to the AV
        llSay(log_spam_channel, "Trying llAttachToAvatarTemp()");
        llAttachToAvatarTemp(ATTACH_HUD_CENTER_1);
        llSay(log_spam_channel, "After llAttachToAvatarTemp() with llGetAttached() returning " + (string)llGetAttached());
        llSetTimerEvent(0.0);
        if (llGetAttached() == 0)
        {   // Attaching failed
            llDie();
        }
    }
    
    experience_permissions_denied( key agent_id, integer reason )
    {   // Permissions denied, so go away
        llSay(log_spam_channel, "Denied experience permissions for " + (string)agent_id + " due to reason #" + (string) reason);
        llDie();
    }
    
    attach( key id )
    {   // Attached or detached from the avatar
        if (id)
        {
            llSetTimerEvent(0.0);
            llSay(log_spam_channel, "Now attached with a key " + (string)id + " and llGetAttached() returning " + (string)llGetAttached());
            // From this point, the object can start doing whatever it needs to do.
            state running;
        }
        else
        {
            llSay(log_spam_channel, "No longer attached");
            llDie();
        }
    }
    
    timer()
    {   // Use a timer to catch no permissions response
        llSay(log_spam_channel, "Permissions timer expired");
        llDie();
    }
}

// This state starts when permissions are granted and the object is properly attached
state running
{
    state_entry()
    {
        llSay(log_spam_channel, "off and running!");
    }
    
    attach(key id)
    {
        if (id == NULL_KEY)
        {   // if the object ever un-attaches, make sure it deletes itself
            llSay(log_spam_channel, "No longer attached");
            llDie();
        }
    }
}

(untested.)

[Wulfie Reanimator]

4 hours ago, Quistess Alpha said:

I'd recommend sending the rezzed HUD the hash of the person to attach to via its rez parameter, then having it sensor for them:

Alternatively just use the first part of the owner/rezzer's key as a channel. That way it's immediately known/usable.

Rezzer opens channel, rezzes object with the channel as rez_param, new object talks on that channel, done.

(Though there's an even shorter way to do this that no one seems convinced by.)

[Lucia Nightfire]

9 hours ago, Quartz Mole said:

because there can, depending on what else is happening on the region easily be a second or so's delay before it's ready to receive messages and the simulator is ready to deliver them.

Afraid of mentioning this disaster that is now 2.5 years old? 😉

Dat watch count, though...

[Quartz Mole]

18 minutes ago, Lucia Nightfire said:

Afraid of mentioning this disaster that is now 2.5 years old? 😉

Dat watch count, though...

That wasn't specifically what I had in mind, but it's an example of why it's a good precaution always to have the rezzed object to ping the rezzer to ask for any data it needs (or, as Quistess suggests, to pass a hashed key as the start parameter).    

[Quistess Alpha]

I know this is an old thread, but I happened to think about the 'problem' of rezzing an attachment and communicating to it who it's supposed to attach to again today, and as happens when you revisit old problems, I think I thought up an even more elegant solution: simply set the description (or invisible hover text) of the rezzer to the key of the avatar to attach to:

//rezzed attachment:
on_rez(integer i)
{   key rezzer = llList2Key(llGetObjectDetails(llGetKey(),[OBJECT_REZZER_KEY]),0);
    key attach_to = (key)llList2String(llGetObjectDetails(rezzer,[OBJECT_DESC]),0); // alternatively OBJECT_TEXT, depending on the rezzer setup.
    llRequestExperiencePermissions(attach_to,[]);
}
// ...

 

[Qie Niangao]

1 hour ago, Quistess Alpha said:

 simply set the description (or invisible hover text) of the rezzer to the key of the avatar to attach to:

That would work in many practical applications. If I understand the suggestion, however, a difficulty could arise if the rezzer ever rezzes another object before a predecessor reads the rezzer's hint.

Without some acknowledgement back to the rezzer, it wouldn't know to wait before rezzing the successor, and that's back to (at least) the same complexity as the chat channel approaches.

[Quistess Alpha]

26 minutes ago, Qie Niangao said:

If I understand the suggestion, however, a difficulty could arise if the rezzer ever rezzes another object before a predecessor reads the rezzer's hint.

Indeed, that would be a problem. Practically speaking, that could be mitigated by the rezzer sleeping for a bit after rezzing something, but that's not 100% error-proof either.