Rezzing items from hud with animations. Animations work for me but not others?

[Glovercali]

Hello, new to scipting here. 

I have this hud that rezzes a spell on the ground with a simple animation.

In example:

1. Avatar attaches hud

2. Clicks hud

3. Places(rezzes) a spell on the floor with squating down animation.

IT WORKS PERFECTLY FOR ME and other can see me do it.. the issue is when I send to others to test out. 

This happens..

 

Script error - Script trying to trigger animations but PERMISSION_TRIGGER_ANIMATION permission not set.

This is the code

rotation relativeRot = <0.0, -0.0, -0.5 , -0.5>;

float floor_distance; //global used for determining individual avatar height

default
{
    state_entry()
    {
        llRequestPermissions(llGetOwner(), PERMISSION_TRIGGER_ANIMATION | PERMISSION_TAKE_CONTROLS);
    }

    touch_start(integer n)
    {
        //calculate for individual avatar size 
        vector size = llGetAgentSize(llGetOwner());
        floor_distance = size.z / 2;
        
        string Object= llGetInventoryName(INVENTORY_OBJECT,0);
        rotation myRot = llGetRot();
        
        //position is where it rezzes (left,right,height)
        vector position = llGetPos() + (<2, 0.0, -floor_distance> * myRot);
        
        //rotation is how the prims rotation is set relative to avi & rezzer ? 
        rotation rezRot = relativeRot * myRot;
        
        llStartAnimation ( "spell" );
        llRezObject(Object, position, ZERO_VECTOR, rezRot, 0);
            llSleep(3.0);
            llStopAnimation ( "spell" );
    }
}

Any suggestion? I have permissions set, animations work for me just fine, but not for others. I did try to add a llResetScript(); but I'm clearly missing something because that didn't work. Maybe I put in the wrong section

[Quistess Alpha]

Dealing with permissions can be quite a handful. It might not be the best efficiency-wise, but the M.O. I've fallen into lately is to have a separate state that handles the permission requests, which to me seems cleaner than the other common solution of requesting permissions right before you need them.

rotation relativeRot = <0.0, 0.0, 0.71 , 0.71>;
// this should be exactly the same rotation you had, but it's more correct semantically. 

//does not need to be a global:
//float floor_distance; //global used for determining individual avatar height

integer wantedPerms;
default
{
  state_entry()
  {
    wantedPerms = PERMISSION_TRIGGER_ANIMATION;
    // do not request PERMISSION_TAKE_CONTROLS unless you really need them,
    // they will not be granted in many cases (if you are not sitting on the object and it's not worn) and can be revoked.
  	llRequestPermissions(llGetOwner(), wantedPerms);
  }
  on_rez(key ID)
  {
    llRequestPermissions(ID, wantedPerms);
  }
  run_time_permisions(integer perm)
  {
    if(perm==wantedPerms)
    {   state running;
    }
  }
}

state running;
{
    changed(integer c)
    {  if(CHANGED_OWNER&c)
       {  state default;
          // could do a llResetScript() instead, but not needed in this case.
       }
    }
    touch_start(integer n)
    {
      // seems owner-specific, so do nothing if touched by non-owner:
      if(llDetectedKey(0)!=llGetOwner()) return;
        //calculate for individual avatar size 
        vector size = llGetAgentSize(llGetOwner());
        vector floor_distance = size.z / 2;
        
        string Object= llGetInventoryName(INVENTORY_OBJECT,0);
        rotation myRot = llGetRot();
        
        //position is where it rezzes (left,right,height)
        vector position = llGetPos() + (<2, 0.0, -floor_distance> * myRot);
        
        //rotation is how the prims rotation is set relative to avi & rezzer ? 
        rotation rezRot = relativeRot * myRot;
        
        llStartAnimation ( "spell" );
        llRezObject(Object, position, ZERO_VECTOR, rezRot, 0);
            llSleep(3.0);
            llStopAnimation ( "spell" );
    }
}

 

[Rolig Loon]

When you request permissions, LSL expects you to provide a run_time_permissions event in which you check to be sure that the requester has actually given permission.  That's where you should usually put most of the stuff that you now have in the touch_start event.  If you plan on letting other people use the script, you can either try restarting the script, for example by using a changed event to detect

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

or you can test in the touch_start event to see whether the current toucher has given permission.  For example ...

touch_start (integer num)
{
    if ( llGetPermissionsKey() == llDetectedKey(0) )  { //Do all the rezzing/animating stuff ....}
    else  {  llRequestPermissions( llDetectedKey(0), PERMISSION_TRIGGER_ANIMATION); }
}

 

Edited September 26, 2021 by Rolig Loon
Ooops

[Rolig Loon]

Rather than mess up what I wrote above by editing that comment, let me add a little more here as an afterthought....

The advantage of putting that if test in touch_start, as I suggested, is that llGetPermissionsKey() will return NULL_KEY if permission has not been granted.  So, in one simple test you cover two possibilities: (1) the current toucher hasn't granted permissions yet or (2) the current toucher is a different person from whoever did grant permissions.  Either way, if the test fails, the script is directed to llRequestPermissions, so you're covered.  As Tessa notes correctly, it makes sense to put that request in touch_start instead of stuffing it way at the start of the script, before you really need it.

Now, the other nuance, which I left untouched earlier, is that you can save space and make your script more efficient if you put all of the code that actually does the rezzing/animating things into a user-defined function way at the top of your script.  Then, you can call that function from the touch_start event if llDetectedKey(0) has already granted permissions and from the run_time_permissions event if he hasn't.  You don't have to type all those instructions twice.

Edited September 26, 2021 by Rolig Loon
typos. as always.

[Quistess Alpha]

19 minutes ago, Rolig Loon said:

As Tessa notes correctly, it makes sense to put that request in touch_start instead of stuffing it way at the start of the script, before you really need it.

That's actually the opposite of what I said. In the specific case where all of the following apply:

• The only intended user is the owner of the object
• The permissions requested are not automatically revoked under any (normal) circumstances
  • (PERMISSION_TRIGGER_ANIMATION, PERMISSION_DEBIT, PERMISSION_ATTACH are the main examples I know of these)

I do recommend stuffing the permissions request at the start of the script (in its own dedicated state) before you need it, rather than testing for permissions before each use of a permission-required function.

Rolig's method is the safest though, as even requesting more permissions can revoke permissions you've previously requested, and the case I detailed is a fairly specific one (but it comes up a lot in the kinds of things I like to script. . .)

as an example, I usually have something like

string gAnimation;
safe_animate(string anim, key ID)
{
  gAnimation=anim;
  if(llGetPermissionsKey()==ID)
  {  if(llGetPermissions()&PERMISSION_TRIGGER_ANIMAITON)
  	 {
        llStartAnimation(anim);
        return;
  	 }
  }
  llRequestPermissions(ID,PERMISSION_TRIGGER_ANIMATION);
}

// ... //
run_time_permissions(integer perm)
{
  if(perm&PERMISSION_TRIGGER_ANIMATION)
  {
    if(gAnimation)
    {  llStartAnimation(gAnimation);
    }
  }
}

 

[Rolig Loon]

Ah!  Sorry.   I misread your comment. 

In the long run, it doesn't make much difference where you request permissions, but in this case I actually do think it makes more sense to put the test where I did, in touch_start.  By testing if (  llGetPermissionsKey() == llDetectedKey(0) ), you are only directing the script to reacquire permissions if it's the first time that the current user has touched it, whether the current user is the person who used it last or a new owner, and you are only requesting it if the script is actually doing something that needs those permissions. 

[Glovercali]

thank you ladies so much! I greatly appreciate it

[Innula Zenovka]

It's not completely clear to me how this setup works or where this script is supposed to go.

If it goes in the HUD, then it should ask for animation permissions in the attach event, when the user first adds it.

If it goes in the glowy green mandala, then it needs to request permissions in some way, depending on what you want it to do.  If they sit on it, for example, it would go in the changed event (CHANGED_LINK), though there are other ways to trigger the request, of course.

 

 

[Glovercali]

1 hour ago, Innula Zenovka said:

It's not completely clear to me how this setup works or where this script is supposed to go.

If it goes in the HUD, then it should ask for animation permissions in the attach event, when the user first adds it.

If it goes in the glowy green mandala, then it needs to request permissions in some way, depending on what you want it to do.  If they sit on it, for example, it would go in the changed event (CHANGED_LINK), though there are other ways to trigger the request, of course.

 

 

Hello  the script goes in the hud. The hud triggers an animation when you summon a spell on the ground(rez). The mandala rezzes out and its sensor based. So, if someone is standing near the mandala, they get healed through their already scripted combat hud. Mandala does not request permissions to animate. 

Sorry, hope that clears it up. 

[Mollymews]

1 hour ago, Glovercali said:

Hello  the script goes in the hud. The hud triggers an animation when you summon a spell on the ground(rez). The mandala rezzes out and its sensor based. So, if someone is standing near the mandala, they get healed through their already scripted combat hud. Mandala does not request permissions to animate. 

Sorry, hope that clears it up. 

thanks

the error is caused when the HUD changes ownership. The permissions request (as wrote) happens in state_entry which only fires when the HUD script is reset. The fixes are:  llResetScript on CHANGED_OWNER, or request permissions on attach

Edited September 28, 2021 by Mollymews