Is there a better way to give ppl permission?

Hello there,

What I want to do is below.
1. If someone touched the object, "PERMISSION_TRIGGER_ANIMATION" would be given.
2. The person who it would be given must not be the owner.
3. It would be given until 20 ppl.

touch_start(integer total_number)
    {
        if(llDetectedKey(0) != llGetOwner())
        {
            if(AVKey01 == NULL_KEY)
            {
                AVKey01 = llDetectedKey(0);
                if(!(llGetPermissions() & PERMISSION_TRIGGER_ANIMATION))
                {
                    llRequestPermissions(AVKey01, PERMISSION_TRIGGER_ANIMATION);
                }
            }
            else if(AVKey02 == NULL_KEY)
            {
                AVKey02 = llDetectedKey(0);
                if(!(llGetPermissions() & PERMISSION_TRIGGER_ANIMATION))
                {
                    llRequestPermissions(AVKey02, PERMISSION_TRIGGER_ANIMATION);
                }
            }
            else if (AVKey03 ...omit

I could write like above. But I thought it was silly to repeat 20 times. Does anyone let me know how to write this smarter.

Thanks.

Lists are just what the doctor ordered
With your code, create a list that contains the avatars that have touched the object.
Here's some sample code:

list gGiven;
default {
    touch_start(integer totalNum) {
        key detKey = llDetectedKey(0);
        if (dKey != llGetOwner() && llGetListLength(gGiven) < 20) {
            gGiven += detKey;
            if (!(llGetPermissions() & PERMISSION_TRIGGER_ANIMATION)) {
                llRequestPermissions(detKey, PERMISSION_TRIGGER_ANIMATION);
            }
        }
    }
}

Keep in mind, a script can only have permissions for one avatar at a time. It looks like you're trying to code a multi-avatar animation script, there are two ways to do this:
1. Have the script request permission to animate every time it starts/stops an animation for a particular avatar.
2. Have a seperate script for each avatar.
Both are inconveniant, but that's all we got

Also, the script above doesn't take into account if the toucher is already in the list. Unless you want the script to respond to the same person more then once, Id recommend checking if the person is in gGiven before adding them using llListFindList.

And anothe thing, particularly concerning llGetPermissions. It tells you the permissions the script currently has, but ONLY for the avatar returned by llGetPermissionsKey; your script might have animation permissions for avatar A, so llGetPermissions() & PERMISSION_TRIGGER_ANIMATION will return TRUE, however, it does *not* have permissions for avatar B, the toucher.
==Chris

Thank you Chris,

If a script can only have permissions for one avatar at a time, I will have a seperate script each avatar. Gimme a hint. All 20 scripts lie in wait to give permissions to one avatar who touched one object. So I imagine that every scriptes would give permissions to him, but what I want to do is one script to one avatar. How should I manage it?

I've never actually done one of these, but at a guess I'd do it something like this:

Controller script, remembers who has touched it and which of the permissions scripts have been used, and which are empty.

Permissions scripts 0-19.

Touching the object *only* triggers an event in the controller. It gets the key works out which permissions script to pass it it, and does so with a link message. Personally I'd use the integer field for the discrimination, key as is and the string field for a start/stop message (so they can touch to stop, maybe with a yes/no dialog box).

The permissions scripts wait for link messages, check it's got their ID number, request permissions and off you go. If permission is not given, or the person leaves they send a message back to the controller saying "I'm free" so the controller can replace the key in their slot with a null key.

I think a list which starts full of null_key and has the keys added to it and deleted from it is probably the most efficient way to do this, and since that script won't do much else it should be OK.

I suspect there are some wrinkles, if you tp away you break permissions but I don't think the script can detect that so you might need a sensor on a slow repeat (say every minute) to check if the avs with permission are in range - that would probably have to be in the permissions scripts and look specifically for their av so you can get around the 16 detected entities limit, and that might be pretty laggy. Something that triggers once when there are 19 dancers to check, and again when there are 20, and again each time someone seeks permission and there are 19/20 dancers might be more sim friendly, unless it's really, really busy.

Instead of a llSensorRepeat, Eloise, perhaps just a slow Timer with a for loop and llSensor to check each person in the animated list.

Hi Eloise, thank you for responding.

Can this below work for it?

key detKey;
list gGiven;
list temp;
integer fileNum = 0;

default
{ 
    touch_start(integer totalNum)
    {
        detKey = llDetectedKey(0);
		if (detKey != llGetOwner())
		{
			temp += detKey;
			if (llGetListLength(gGiven) < 20 && llListFindList(gGiven, temp) == -1)
        	{ 
            	       gGiven += detKey;
            	       fileNum = fileNum + 1;
			           llMessageLinked(LINK_THIS, fileNum, "GivePerm", detKey);
                       temp = [];
            } 
         } 
    } 
}

And 20 seperate link_message scripts recieve it and give permissions.
I just let ppl who touched the object dance together. I've not understood your sensor part yet. Permission is needed to confirm regularly?

[REPORT]
Though I've tried to do this with just one another person, It worked well.
Just increasing cliant scripts, I would be able to bump up the number of ppl. Thank you.

Check out this thread. Evil Fool worked out a single-prim dance machine that does animation for multiple people on touch. It might give you some ideas.

Hi Padraig, thank you for the information.

Seeing Evil Fool's code, I realized that he would also check if dancers with permission were in range by sensor function. But I've not known why it is needed yet. Unless I use sensor, what problem occurs?

And he uses touch_start's integer. According to Wiki, The number of touching agents is passed to the script in the num_detected parameter. Is that "the number of touching" or "the number of agents"? In the latter case, it is very useful. It must have also an awareness who the touched man is.

touch_start() generates a touch event for each agent touching it, so you can cycle through them to grab all the keys of the people touching the item.

The sensor is required so you can clear people from the list I think, although others might be able to point out other ways to do it. Basically if you add people to the list the various scripts don't know when the person they are animating leaves unless you detect them somehow. Click off to stop dancing will work, and is nice, but people crash, tp away etc. and the scripts as described without a sensor will assume they are still animating that agent so you'll quickly and erroneously fill up your 20 spaces and then never allow anyone else to dance again.

Your code looks OK to me, but I have to say I'm really bad at reading code (including mine) and debugging it, I'm a tester of code rather than someone that reads it and understands it cold so to speak. There's no way of removing people from the list that I can see though, when they go home or sit down or similar.

SteveR, it depends on why and how. It might be better in this case, but there's no reason per se to use a timer and a single sensor than a sensor repeat - you can put 120 or 300 or 3600 into the sensor repeat time as well as 0.5... In fact I remember someone suggesting sensor repeats are less heavy, the timer hits two events since you call a sensor from inside it and however you ping your up to 20 sensors they still hit the sim a bit.

Objects can only have 1 sensor at a time (or is that 1 sensor per prim? In this case I believe we're talking about a single prim though.) With llSensorRepeat you'd have to seach for all agents, which can only return 16 matches, while there could be up to 40 people in the area. So I think you'd want to do a scan for each individual person on your 'being animated' list. So you'd end up hitting the sim harder with a timer and up to 20 scans. But it would keep the list clean.

Hello Eloise, I allways appreciate your helpful suggestion.

[EDIT]Oh, you explains touch_start's returning integer in this part, doesn't you? But you seem to talk about keys. hmm the way of my collecting keys is below.
Each touched avatar key stores in "gGiven". When someone touch it, his key stores in "temp" temporally, and it is compared with "gGiven". If it doesn't match it, it stores in "gGiven". And "temp" is cleard.I've got where you're coming from. You might imagine a still fixed object such as an animation sample vending machine at the store. But what I'm making is just a cube. It would be rezed on ground when you and your friends want to dance, and it would be deleted when you are tired. Very sorry. Consider that showing my code is just taling to myself.

For a situation with friends you probably don't need the sensor's etc. yes I'm thinking of the more general application.

Your key grab works for one at a time. A little for loop for(i=0; i<totalNum; ++i) and then llDetectedKey(i) lets you add more than one at a time, just in case. Again less necessary if it's just for friends.

And you're right I'd not thought about the sensor limit. Argh and ouch. Mind you the whole sensor thing like that, argh and ouch. Anyone think of a smarter way?

You seem to talk about more important thing. When I tried this with other 5 ppl yesterday, It could grab just 3 ppl's keys.
I have to study more....

I don't know how accurate this is, but I didn't the lindons recently change script permissions. So that if an avatar leave the sim for any reason, the script losses the permission to animate. WOuldn't this cause a changed event to be triggered?

You'd hope so, but no, at least I don't think it does trigger the changed event. In the same way that they're assigned using the run_time_permissions event and don't trigger the changed event then.