Animation Oddites

I had a wierd occurance when using the llStartAnimation() function. I made an object that is sort of a portable dance machine. At the time of the test, I was wearing it as an attachment.

When a user wants to dance, the main script calls one of the child scripts that gain permissions. The child script then requests permission to animate from the person who clicked on the object.

This worked ok, and the person even got the permission request dialog box.

In the run time permission event after verifying that I indeed had permissions, I called a function that basically said llStartAnimation() (or whatever the function is). Only, my character started dancing instead of the person who requested the permission.

I fixed this by taking the body of my start_dancing() function and putting it inside the run time permission event, and it worked as intended, animating the other avatar.

So I can only assume that once you leave the run time permission event, any further calls to animate something will default to the object owner?

It is pretty late so I am sorry if this doesn't make sense. But if someone does, could anyone shed light as to the reason the script animated me when animate was called from a function out of the run time permission event that was triggered by another, and why it animated the other avatar when the animation call was right in the run time permission event?

Hamaar

Unresponded post that's getting a bump from the backlog.

Interesting. I've always wondered quite how these worked without specifying a target. Sounds to me like a nuance in the actual code of the functions.

Perhaps the resident bytecode hunters can take a look?

it's probable your code. If youw ant I'd be happy to take a look at it.

Its also possible that the "attachment default permissions" are overriding the permissions granted to the other avatar. Hopefully LL checks if the script passes llGetOwner to llRequestPermissions before auto-granting the permissions for the owner. llStartAnimation and llStopAnimation start and stop the animation for whomever the script has PERMISSION_TRIGGER_ANIMATION for. This makes it possible to have single-prim, single-script (though unsynchronized) dance machines.
==Chris

Sorry I was away for a bit and unble to get to the net. Thanks for all the responses so far. I haven't been able to get back into the game to look at my script yet, but let me hazard a guess as to what happened. When I get a chance I will test the object when it is not attached to observe its behavior.

Christopher's guess is mostly in line with what I observed. It seems as though the permissions dropped back to the default attachment perms when I called the function to animate. I am not sure when I'll have time to do more testing with it but that pretty much seems like that is what happened.

I asked my question before to see if it was a common problem people had when getting permission from other people. Am I safe to assume that when an object gets run time permissions that do not have defaults auto grants, a script can carry the permissions around from function to function?

Again, thanks all for responding

Hamaar

Once you've got the permissions, if they're tied to a global variable you can use them elsewhere.

you want something like (this won't compile obviously)

run_time_permissions(integer perm)
{
    perms=llGetPermissions();
}
some_other_event()
{
    if((perms & PERMISSION_TRIGGER_ANIMATION) == PERMISSION_TRIGGER_ANIMATION)
    {
        llStartAnimation();
    }
}

This ought to let you do your stuff I think.

Also, if the script has PERMISSION_TRIGGER_ANIMATION, llGetPermissionsKey will get you the key of the avatar that llStartAnimation will animate once called.
==Chris

I found the problem, and figured i would post it just for completeness of the thread.

The problem was basically lingering permissions in the secondary scripts. The master script organizes all the secondary scripts. So what would happen is a script would get freed up on the master script, and then a new person would come along and get assigned an old secondary script that already had someone elses permissions tied to it. So the new person would request an animation, and it would play on the old person if they were still around.

The reason that I thought unrolling the animation from the function was the problem was that after saving and changing the script, it caused the script to reset, and freeded up the lingering permissions. This then caused the script to behave as intended until the master script started reassigning secondary scripts again. I had not had time to test extensivly, so I simply assumed that my change fixed the problem, which prompted the intial post.

Hamaar