problem with permissions to detach link

[Raena Parx]

I have a prop that's supposed to detach on touch. For testing purposes it's just 2 cubes.  This will be a rezzed object that anyone should be able to touch and it will detach.  It works perfectly for my avatar (owner), but not for any other avatars.  

Below is the simplified portion of the script.  I tried changing out llGetOwner() with llDetectedKey(0) , but the other avatar never gets the message to accept permissions to unlink the object. And then it gives this script error: "Script asking non-owner for run time permissions only owner can grant". (I cannot make this dependent on getting permissions from the owner every time it's needed. )

I tried making it a wearable object, but when worn it fails to detach at all.

And one more weird thing - every time I use it, it detaches fine for me, but then the object that was left behind is still visible, but not selectable. It's not locked, it's just like it's not there at all. If you click it in edit mode it selects the objects that's behind it instead.

Can someone please tell me what I'm doing wrong?

Here is the script:

//Test Detachable Link
default{

    touch_start(integer n)
    {
    llRequestPermissions( llGetOwner(), PERMISSION_CHANGE_LINKS );    
    //llRequestPermissions( llDetectedKey(0), PERMISSION_CHANGE_LINKS );    //does not work
    }

     run_time_permissions( integer perm )
    {
        if(perm & PERMISSION_CHANGE_LINKS) {llBreakLink(1);}
    }      
}

 

Thank you.

 

 

Edited March 31, 2023 by Raena Parx
typos

[Wulfie Reanimator]

From the wiki: https://wiki.secondlife.com/wiki/LlBreakLink

"This function silently fails if called from a script inside an attachment."
"This function fails if the owner does not have edit permissions on the object containing the script."
"If PERMISSION_CHANGE_LINKS is granted by anyone other than the owner, then when the function is called an error will be shouted on DEBUG_CHANNEL."

So regardless of who is touching the object, the script needs permission from its owner. That means when someone else touches your object, you must accept permission, not the person touching the object. Making this part work seamlessly is possible but requires extra steps.

When I tested your script, I also noticed the object being a ghost for a moment, but it became selectable after a few seconds.

Edited March 31, 2023 by Wulfie Reanimator

[Rolig Loon]

The error message says it all:

32 minutes ago, Raena Parx said:

Script asking non-owner for run time permissions only owner can grant"

Except by using RLV or an experience, there's no way that anyone can remove an attachment on someone else. If you are wearing an object that you own, you have implicit permission to detach it. You cannot give that permission to someone else, because that "someone else" doesn't own the object.  So, your two possible solutions are to either use RLV or an experience.

EDIT:  To be clear, since Wulfie posted her better answer while I was typing.... The script cannot remove the attachment unless the owner gives it permission.  You can script it to ask the owner for permission the detach the object, as Wulfie suggests, but it's still the owner who gives permission.

Edited March 31, 2023 by Rolig Loon
Cleaner wording

[Love Zhaoying]

I read it as, the object is rezzed in-world and not necessarily attached when a user clicks on it.

In that case..I have a different answer but it is difficult to formulate.

 

[Rolig Loon]

2 minutes ago, Love Zhaoying said:

I read it as, the object is rezzed in-world and not necessarily attached when a user clicks on it.

 

37 minutes ago, Raena Parx said:

I have a prop that's supposed to detach on touch. For testing purposes it's just 2 cubes.  This will be a rezzed object that anyone should be able to touch and it will detach. 

 

[Love Zhaoying]

4 minutes ago, Rolig Loon said:

42 minutes ago, Raena Parx said:

I have a prop that's supposed to detach on touch. For testing purposes it's just 2 cubes.  This will be a rezzed object that anyone should be able to touch and it will detach. 

 

Definitely some terminology issues there. But I think that you pointed out what I missed.

[Quistess Alpha]

56 minutes ago, Raena Parx said:

I have a prop that's supposed to detach on touch.

Non-RLV:

default
{   touch_start(integer n)
    {   llRequestPermissions(llGetOwner(),PERMISSION_ATTACH);
    }
    run_time_permissions(integer perm)
    {   if(perm&PERMISSION_ATTACH) llDetachFromAvatar();
    }
}

RLV:

default
{   touch_start(integer n)
    {   llOwnerSay("@detach=force");
    }
}

 

Edited March 31, 2023 by Quistess Alpha

[Wulfie Reanimator]

Looks like we'll definitely need @Raena Parx to clarify what kind of 'detachment' they mean.

But, considering how the example script uses llBreakLink and they said "it [works] fine for me, but then the object that was left behind is still visible, but not selectable", it seems likely they aren't talking about taking off an attachment.

[Love Zhaoying]

2 minutes ago, Wulfie Reanimator said:

Looks like we'll definitely need @Raena Parx to clarify what kind of 'detachment' they mean.

Definitely, at least once I thought maybe they meant "rezzed in world and UNLINK" not actually "detached" (as if perhaps it is not really attached at all).  Maybe there is some confusion between unlinking and detaching.

 

Edited March 31, 2023 by Love Zhaoying

[Quistess Alpha]

If we really are talking about llBreakLink() I guess I'll mention that it's a fairly standard trick to have a separate state for requesting owner-only permissions before moving on to the 'regular operation of the script' state:

integer neededPerms = PERMISSION_BREAK_LINKS;
default
{   state_entry()
    {   llRequestPermissions(llGetOwner(),neededPerms);
    }
    touch_start(integer n)
    {   llRequestPermissions(llGetOwner(),neededPerms);
    }
    run_time_permissions(integer perms)
    {   if(perms==neededPerms) state running;
    }
}
state running
{   touch_start(integer n)
    {   llBreakLink(1);
    }
}

 

Edited March 31, 2023 by Quistess Alpha

[Rolig Loon]

Aha!  Yes.  I was blinded by the non-standard use of the word "detach".  I suspect you're right, Love. The OP is talking about unlinking, not detaching anything.  In that case, we refer to the wiki discussion of llBreakLink, which says:

To run this function the script must request the PERMISSION_CHANGE_LINKS permission with llRequestPermissions and it must be granted by the owner.  

So again, if anyone but the owner wants to unlink the two cubes in the OP's example, they have to ask the owner's permission first.  If the owner grants permission, then it's OK.

[Raena Parx]

Thank you everyone for your input.  it is greatly appreciated!  I guess I wasn't quite clear when I said "detach".  What I meant is that the object is supposed to separate (detach) from itself, leaving a small piece of itself behind.

A little more details:  This is a prop that rezzes when using MLPv2.  The prop/object rezzes. The user of the table (could be anyone) should be able to touch the object, then the object separates, leaving a piece of itself behind.  The next animation removes the original prop (except the for left-behind link), and then interracts with the left-behind link.  I hope that's clearer.

The mention of making the object wearable was just something I tried as an alternative. I don't believe that works anyway, but it's not really the ideal solution.  I'd rather have the prop be a rezzed object.

The user of the MLPv2 furniture could be anybody, (it's in a medical environment, so it could literally be any doctor or assistant). So "anybody" needs to be able to touch the prop to delink it. Asking the owner for permissions is not an option, because the owner may not be online when it's being used.  So if that's the only way it can work, I"m thinking I may have to give up on the option to delink on touch.

Tessa, thank you so much for the code segments.  I haven't had a chance to try them out yet, but I'm guessing it's still asks the owner for permissions, correct?  Curious, what is the purpose/advantage of using a separate state for requesting owner-only permissions?

Again thank you everyone for your help. 😄 🙃 ☺️

 

[Rolig Loon]

6 minutes ago, Raena Parx said:

Curious, what is the purpose/advantage of using a separate state for requesting owner-only permissions?

As long as you don't reset the script (thereby losing the permissions), the script will remember that the owner granted permission.  Thereafter, script execution will be in the running state, which uses the permissions but never asks to reset them. Each new user is simply popping in at the top of state running instead of state default.  

[Wulfie Reanimator]

54 minutes ago, Raena Parx said:

The user of the MLPv2 furniture could be anybody, (it's in a medical environment, so it could literally be any doctor or assistant). So "anybody" needs to be able to touch the prop to delink it. Asking the owner for permissions is not an option, because the owner may not be online when it's being used.  So if that's the only way it can work, I"m thinking I may have to give up on the option to delink on touch.

The trick around this is to ask the required permissions long before they are actually needed. The script (and any copies made afterwards) will keep the permission forever, unless the script is reset.

Specifically:

1. Start or rez the script for the first time. It asks for permission from owner.
2. The owner accepts the permission request. The script doesn't do anything yet.
3. The owner puts the object (which contains the script + permissions) into the MLPv2 furniture.
4. Whenever a copy of the object is rezzed, it can be unlinked by anyone without the owner's presence (because it already has permission).

The script doesn't need separate states to handle permissions, that's just scripter's preference. An alternative example could be as simple as the following, but there is also a happier middle-ground. (Most notably, you don't have to do anything in the run_time_permissions event.)

default
{
    // When the script runs for the first time
    state_entry()
    {
        llRequestPermissions(llGetOwner(), PERMISSION_CHANGE_LINKS);
    }

    // When anyone touches this object
    // (Don't touch before owner has given permission.)
    touch_start(integer n)
    {
        llBreakLink(1);
    }
}

 

Edited April 1, 2023 by Wulfie Reanimator

[Raena Parx]

Thank you all again.  Wulfie, I understand what you're saying, and although it would work for a custom build, or for an object with MOD permissions so the owner could activate permissions and place it in the furniture themselves.  This particular build is not mod, so I guess this option will not work. 

Just a rant...Sometimes SL has soooo many limitations.  Why the extra permissions needed to break a link?  If the scripter writes it to break, they can use Owner/Group/All permissions to minimize who can use it. So why the EXTRA permissions. Oh well.   

Thank you everyone for your help.  I think for a no-mod furniture, unless I customize it for each buyer, this is not gonna be an option.  But I really appreciate everyone trying!!!

T H A N K   Y O U   !!!!!

 

[Artorius Constantine]

Instead of breaking or detaching, which require permissions, how about just using alpha to make it appear to break off and rez a new whatever you need.

This is a work around yes, but the effect would be the same. The piece you want to go away would "go away" and rezzing a new object would make it appear as if it broke off and now exists as a separate piece. No perms required except rezzing and that could be done by the base object and set to rezz the new piece anywhere so no rezzing perms required by the avatar using it at all.

Someone touches it, the piece vanishes (with alpha) and sends a message to the base prop to rez a new piece. Simple illusion and no break link perms required at all.

[Raena Parx]

OOOOO, I never thought of that. Thank your Artorius!  That is an awesome idea - and might be the answer. Will definitely try it out. Will let you know.  Thank you sooo much!!!

 

[Raena Parx]

Just a follow up -Artorius the rezzing option worked perfectly!  Thank you everyone for all your help!  I also learned a few tricks for when I do need to setup permissions.  I appreciate all of you!!! 

Edited April 8, 2023 by Raena Parx
spelling