Edu Csak Posted May 18, 2022 Share Posted May 18, 2022 (edited) 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 Link to comment Share on other sites More sharing options...
Edu Csak Posted May 18, 2022 Author Share Posted May 18, 2022 I guess I've solved putting a llSleep(5.0); between llRezObject and llRegionSay 1 Link to comment Share on other sites More sharing options...
NardweBones Posted May 18, 2022 Share Posted May 18, 2022 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! Link to comment Share on other sites More sharing options...
Lucia Nightfire Posted May 18, 2022 Share Posted May 18, 2022 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. Link to comment Share on other sites More sharing options...
Moles Quartz Mole Posted May 19, 2022 Moles Share Posted May 19, 2022 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. Link to comment Share on other sites More sharing options...
Quistess Alpha Posted May 19, 2022 Share Posted May 19, 2022 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.) Link to comment Share on other sites More sharing options...
Wulfie Reanimator Posted May 19, 2022 Share Posted May 19, 2022 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.) Link to comment Share on other sites More sharing options...
Lucia Nightfire Posted May 19, 2022 Share Posted May 19, 2022 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... Link to comment Share on other sites More sharing options...
Moles Quartz Mole Posted May 19, 2022 Moles Share Posted May 19, 2022 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). Link to comment Share on other sites More sharing options...
Quistess Alpha Posted September 8, 2022 Share Posted September 8, 2022 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,[]); } // ... Link to comment Share on other sites More sharing options...
Qie Niangao Posted September 9, 2022 Share Posted September 9, 2022 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. 1 Link to comment Share on other sites More sharing options...
Quistess Alpha Posted September 9, 2022 Share Posted September 9, 2022 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. 1 Link to comment Share on other sites More sharing options...
Recommended Posts
Please take a moment to consider if this thread is worth bumping.
Please sign in to comment
You will be able to leave a comment after signing in
Sign In Now