Attachment Animation Permissions

I am making an attachment that uses a HUD to issue the commands to the attachment.

1. The HUD sends out a simple llSay message from it's buttons on a HUD channel.

2. The attachment which has multiple prims has a single listener script in the root prim. The listener script hears the HUD, and translates that into sending a llMessageLinked message depending on which button was pushed, to the correct next script through a series of "if.. else if" statements. This allows the attachment to have only one listen.

3. If the desired action requires targeting an object or agent, a sensor / dialogue script in a 2nd prim "hears" that linked message. The sensor / dialogue script "hears" that linked message and passes the desired Key to the end result script in a 3rd prim. If no targeting is needed the listener sends a message directly to the desired end script in the 3rd prim.

4. The end script performs it's function.

5. There are a number of end scripts, which basically need to run an animation, produce an effect such as a particle, or rezz an object, etc.)

Everything works other than one big issue:

Animations permissions for the wearer of the attachment (the owner) are giving me fits. The only way I have gotten an end script to run an animation so far is by each end script requesting permissions when it is run. I tried changing the design of the attachment to put the scripts in the root prim and it is still requiring permissions.

Is there a way to get a "global" permission for the attachment that asks once upon attachment and serves for all scripts? Or is there something I'm not doing that will stop the need for owner animation permissions?

Here's the portion of an "end script" that attempts to animate:

    link_message(integer sender_num, integer num, string str, key id)
    {
        if ( num == object_num )
        {
            if ( str == messageExample )
                 {
                  TargetKey = id;
                  llRequestPermissions(llGetOwner(), PERMISSION_TRIGGER_ANIMATION);
                  llStartAnimation("dothis");
                  llSleep(1);
                  llSay(0, "'Example'");
                  ParticleStart();
                  llPlaySound("5d7f611c-d622-8288-6e08-986b0ef47337",1.0);
                  llSleep(6);
                  llStopAnimation("dothis");
                 }
        }
    }   // end of link_message state
CODE

Each script must request the permissions it needs on its own.

Also, if the script requests different permissions, then any permissions it had before the last request are not granted anymore. Only the last requested permissions (if consented to by the user) are active.

For attachments, permission requests made by scripts that are NOT in the root prim MUST be OK'd by the user wearing the attachment. Even if it is permissions that are granted automatically (if the script is in the attachments root prim)

Therefore the answer is:
No.
There are no 'global' permissions.

It really annoys me when people depend upon the auto-grant status of permissions in specific situations. You should be using the run_time_permissions event and not just assuming they will be granted.

This is extremely bad form:
llRequestPermissions(llGetOwner(), PERMISSION_TRIGGER_ANIMATION);
llStartAnimation("dothis";

Celty, in my "swiss army knife" HUD I created for myself, I have all the various scripts in the root prim, and a central "server" script that handles input from the buttons on the HUD and then, via linked messages, sends command to the various scripts that actually perform the functions. The buttons just have a very simple script that tells the "server" script which button was pushed, and to move the button between the "folded up out of the way" configuration and the "unfolded and ready for use" configuration. Since one of the things I have in the HUD is my AO, having all the scripts that DO stuff in the root prim solves the problem about animation permissions.

In addition, I also have an additional device that I wear as an attachment (for particle effects and such) that responds to some commands from the HUD. Once again, just set it up like above... any scripts that do animation in the root, and farm out additional tasks to other prims in the attachment via linked messages.

It is not neccessary to have separate scripts in buttons on a linkset.
You can use llDetectedLinkName() to get the name of the clicked prim. So you don't even need a "master script" to pass on the touched button to your scripts as you can have the scripts process the touch event and only react if the detected name is the one that they are looking for.

@ Strife - Sorry it was annoying, though you may note it was not intended as final code or would not have needed to post the issue.

@Solomon - Hmm, sounds very similar to what I'm trying. What is very odd is I tried putting all the scripts in a one prim object, changing "llMessageLinked(LINK_ALL_OTHERS, ..)" to "llMessageLinked(LINK_THIS, ...)" where necessary, removing the permission request, and it still gives me a:

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

Any thoughts as to why? (edit: DOH was not awake I guess left the request in and it works without the pop-up or error!)

@Squirrel - Right you are, I will be using non-scripted buttons as you suggest for the most part. The listener script does have some parsing functions which are helpful, and keeps things tidy as far as only a single listen. I'm using this little snippet from the forums in the root prim of the HUD:

integer hudChan = -12345; // for testing purposes

default
{
touch_start(integer num_detected)
{
llSay(hudChan, llGetLinkName(llDetectedLinkNumber(0)));
}
}
CODE

I didn't mean to jump on you. It just needed to be said that it's bad form. In the future LL may change how auto-grant works (like make it client configurable) which would break code that assumes instant availability. An ounce of prevention is priceless when it means you don't have to worry about every customer IMing you when the product breakages.