Completely confounded by persmissions - please help

Hi,

what I am TRYING to to is to make an item, that - once worn - will play an animation and also take away the UP and DOWN arrow keys. My English probably isn't good enough to understand the documentation because I wrote the following script and it has an extremely weird behaviour I cannot understand.

Instead of saying "requesting perms" then jumping to runtime_permissions and saying "request received" and then getting on with the next request I get the following output:

[6:12] Dummy: Requesting Anim permissions
[6:12] Dummy: Requesting Control permissions
[6:12] Dummy: Anim request received
[6:12] Dummy: Control request received
[6:12] Dummy: Anim request received
[6:12] Dummy: Control request received

I cannot understand why (a) both requests happen immediately after another - I thought the WIKI said that this would trigger run_time_permissions FIRST which apparently it doesn't and also my checking which permissions were requested must be faulty because I get the answer twice.

Any help with this would be greatly appreciated! I really cannot make head or tails of the documentation.

list animations = ["x","y","z"];
list test = ["a","b","c"];
integer channel= 23;         // the channel the device listens to
string curranim;             // animation orders issued - needed to terminate prior animations
string animation;

default

{
    state_entry() {
        llListen( channel, "", llGetOwner(), "" );
         curranim="";
         animation = llList2String(test, 0);
    }
    
    on_rez(integer dummy) {

    }
    
    attach (key attached) {
         if (attached != NULL_KEY) {
//          llRequestPermissions(attached, PERMISSION_TRIGGER_ANIMATION && PERMISSION_TAKE_CONTROLS);
			llOwnerSay("Requesting Anim permissions");
			llRequestPermissions(llGetOwner(), PERMISSION_TRIGGER_ANIMATION);         	    
			llOwnerSay("Requesting Control permissions");
 			llRequestPermissions(llGetOwner(),PERMISSION_TAKE_CONTROLS);              
         } else {
             llReleaseControls();
         }
             
    }

    run_time_permissions(integer perms)    {
        if(perms && PERMISSION_TRIGGER_ANIMATION) {
	        llOwnerSay("Anim request received");
            llStartAnimation(animation);
        }
        if (perms && PERMISSION_TAKE_CONTROLS) {
	        llOwnerSay("Control request received");
			llTakeControls(CONTROL_FWD && CONTROL_BACK,TRUE,FALSE);	        
        } else {
            llStopAnimation(animation);
            llResetScript();
        }
    }
    

    listen( integer channel, string name, key id, string message ) {

    }
}

You are doing regular "AND" test in your code with these '&&' instead of "binary AND" which is '&'

regular AND is met essentially when "both components are not zero" so it triggers as soon as you receive *any* permission. Binary AND on the other hand tests if both components share certain bits which are used as flag for specific permission type, so it only passes for the permission type you actually receive.

Permissions requests are not additive. Asking for another permission means givig up the old one that way, so you have to OR the permissions you want together in one call:

llOwnerSay("Requesting permissions");
llRequestPermissions(llGetOwner(), PERMISSION_TRIGGER_ANIMATION | PERMISSION_TAKE_CONTROLS);

OK - that explains why there were two answers. Thanks for the info.

It still doesn't explain though, why both permissions come immediately after the other. The way I understood the documentation as soon as you request permissions, the user is asked if he or she grants them. With items worn these perms seem to be given automatically. OK. So ... I'd expect the following to happen:

1. I request the anim permissions
2. The anim permissions are auto-granted
3. runtime_permissiosn is invoked
4. I play my anim in the corresponding if loop
5. the runtime_perms returns
6. the take_control request is executed
7. steps 2 & 3 are repeated
8. I take the keys
9. runtime permission returns
10. the attach script continues

But that is exactly NOt what happens. The granting seems to be activated AFTER the attach part is through. And if this is not done sequentially ..... how can I ever take those two permissions?!

PERMISSION_TRIGGER_ANIMATION's value is "1010".
PERMISSION_TAKE_CONTROLS's value is "0100".

If you check the both second and fourth bit and get the both TRUE, you take PERMISSION_TRIGGER_ANIMATION. If you check the third bit and get TRUE, you take PERMISSION_TAKE_CONTROLS. If you check all the scond, third, and fourth bit and get all TRUE, you take the both permissions.

Ah - a misunderstanding on my part, I think - sometimes it is bad when English is a foreign language. "Non additive" I took to mean "you can only have TRIGGER_ANIMATION" *OR* you can have "TAKE_CONTROLS" whereas you *can* have multiple persmissions in one call when you OR the individual permissions. Only ... when doing *another* call you lose what you had so far.

So the "non additive" refers *not* to the *individual* permissions in a *single* call but to *subsequent* calls of permisison requests.

With that in mind things may be a bit easier now (and make a lot more sense now).

Thanks!

Read up a bit on "events" in the Wiki. A quote:

"LSL is not multi-threaded. Only one event will be run at a time; events cannot interupt each other."

That means any event handler (such as your attach event) will complete all the way up to the end (closing bracket or a return statement) before any other event handlers are called.
In essence, the run_time_permissions event is called right after calling llRequestPermission, but this call merely gets queued up in the event queue until such a time that your code is ready to handle the next event call on the queue, which is right after the attach code ends. By that time of course you have two run_time_permissions events queued up, so that's why it executes twice in succession.

I will do that.

I do not think, however, that I will have been able to look at *all* pages of the WIKI before I stumble across the next problem - so please be patient if I ask another question the solution to which is pretty obvious if you have read the very page on which the information is located.

Not knowing about the way SL handles events I took:



to be a literal *when* and not an *after the permissions have been given and the event handler has finished*.

This explains what happened and I thank you for your input!