Changes to LSL permissions.

Hi all. I just wanted to get some feedback on some changes to how LSL permissions work.

First, the dreaded animation permissions spam. This has been changed recently to only spam the owner, and it includes the location of the script causing the trouble. However, this doesn't help the case of a user flying back into a sim where a script has permissions to animate them. This causes questions like "why do I always dance in this sim"... there currently isn't a way to revoke animation permissions.

The easiest solution to this is to just revoke permissions if the agent it has permissions to animate is not found in the simulator.

Second, does anyone rely on PERMISSION_CHANGE_LINKS? We have been thinking about just taking this permission out, and allowing a script to change links without asking for permissions. I'm just afraid of someone writing a griefing script that, when put on someone's object, will start linking with nearby objects and maybe llDie them all. Perhaps using something like the PIN mechanism for this instead?

Ideas?

Question - what about objects that move across sim borders, will they retain their permissions if the avatar enters the sim the object crosses into?



A PIN mechanism sounds good - with one minor issue, linking with unscripted objects?

Personally I would like permission to animate be global, because:
* When people teleport away from a dance machine, there isn't a thing the machine can do to stop the animation. (yes I know teleporting ushally stop animations)
* Also if it was global SLExchange and SecondServer could ad the ability to preview animations to their servos.
* Almost all other permissions work globally, by making animate be global it would conform to a standard, where all permissions have a global effect.
* Any one purposely making a grief script could avoid the safe guard by checking for the avatar's presence before sending a command.
* Some programer may add that check, even if they're not griefing, and unintentionally end up causing problems.

If you don't want animating to be global. Then I can't think of any script that would be hurt by this change. Except if some one lived on the edge of a sims. Every time they acodently walked out of the sim they would be pledged with permission problems. Or worse if they owned property along the shared side of two sims. I'm also assuming this wouldn't effect dance bracelets, or animation over rides.

The simple solution may be easy, and quite elegant. But what happens when people start asking for ways to revoke other permissions from other scripts? How hard is it to get a list of all script that have permissions for a specific avatar? How hard is it to get a list of permissions for a specific script. How hard is it to send a command to revoke permissions for a specific script?

when permistions are revoked on an avatar, should all animtions being played on said avatar be stoped?

Couldn't you just cancel the anim permissions if the avatar gets out of float range then?

Don, regarding PERMISSION_CHANGE_LINKS - I would personally love to see it either removed or, if possible, only be called when a parent prim attempts to unlink from a set (since that usually causes the children to all delink).

I also think a timer should be placed on animation calls that would need to be "refreshed" by the object's script acting on an avatar in the sim (or in range), much like controlled objects revert to their default state after X seconds of idle time if your avatar isn't bound to the object (ie. remote control movers). If the script does not make a second llTriggerAnimation call that succeeds in an interval of, say, 30 seconds, permissions are reset.

This would fix the problem you've described. Believe me, I had a fun time running my Sentinel script to find an animating object for a friend before.

First I have no problems with PERMISSION_CHANGE_LINKS. I see no reason to remove it but it would be nice if the permission applied to every script in the object. It's a pain to have a peice of furniture have multiple scripts in it that all require this permission. If you do remove it please don't have it break our scripts (auto grant it if it is requested (unless they refuse the permission dialog for other permissions); and ignore it when calling link functions).

30 second pemission resetting is bad for items that use looped animations. For example a sit script.

If the av isn't in the sim it should return an error to the script; maybe make llStartAnimation return an integer of TRUE or FALSE as to weather it was successful. Or better yet add a list window of objects in the sim with permissions you have granted; and that allows you to revoke them; in the case of revoked privlages a run_time_permissions should be thrown.

As for looping animations, Strife, I see no problem - so long as the refresh timer is roughly as long as the animation itself. As I understand them, if you called a "sit" animation twice, the avatar would not "move into place" the second time - (s)he'd remain sitting.

or a looped dance script.
I don't think it should auto release, it's a slick solution for some things but a bad idea in the long run (say i attached my gun and 10 min later i dettach it but can't stop the animation because the permission has been released).

A window listing objects in the sim you have granted permissions to is much better (with the ability to revoke them).

I think we can agree to disagree on the other countermeasure option - but I'll second this one. I think that's a good idea.

Edit: Given I don't create dance machines, pose balls, or most of the "mainstream" stuff, really, no offense even initially taken to next post, Strife.

And here is your solution for dance machines
It's a simple script; i have no sympothy for you if your dance machine doesn't do this check; none. I don't see a reason for auto releasing. I don't believe in pandering to shortsighted coders (not directed at you Jeffrey; i have respect for you and i know your not shortsighted).

list animation = ["dance1", "dance2", "dance3", "dance4"];
float time = 20;

go()
{
	if( llStringLength( llKey2Name( llGetPermissionsKey() ) ) )
	{
		llStopAnimation(llList2String(animation, anim));
		anim = (anim + 1) % llGetListLength(animation)
		llStartAnimation(llList2String(animation, anim));
	}
	else
		llResetScript();
}

integer anim;

default
{
	touch_start(integer a)
	{
		llRequestPermissions( llDetectedKey(0), PERMISSION_TRIGGER_ANIMATION);
	}
	run_time_permissions(integer a)
	{
		if(a & PERMISSION_TRIGGER_ANIMATION)
			state dance;
	}
}

state dance
{
	state_entry()
	{
		llSetTimerEvent(time);
		go();
	}
	timer()
	{
		go();
	}
	touch_start(integer a)
	{
		while(a--)
			if(llDetectedKey(a) == llGetPermissionsKey())
			{
				llStopAnimation(llList2String(animation, anim));
				llResetScript();
			}
	}
}

umm far as I know, any one who scripts animations, first checks to see if they have the permission before sending play or stop. Would it be kind of redundant to have stop and start animation to return a value. But I kind of like the idea.

The hole part about dance machines. There should never be a condition where a the avatar was and still is playing an animated triggered by the script, but that script can not stop that animation. i.e. avatar fly out of sim or permission to animate has been revoked. In this sense it doesn't matter if it was revoked because of a time out, out of range (sim or other wise), canceled by user, script reset, extra. When it is the case that a animation is playing from a script, but the script can not stop the animation. The animation should be stopped automatically. Of corse of animation can not be revoked, and dose not have a limited range. Then a script can always clean up after it self.

I wouldn't mind using time as a limit for long range triggering animations, but then maybe there should be a changed ( integer change ) when permissions are revoke. Other wise there would be a bunch of extra timers.
What should happen if animation is revoked, but the script also had other permissions. Should the other permissions stay or be revoked?
For close range having to ping would be annoying. Like already mentioned loop animation, pinging woud just add unwanted complexity. Putting a range limit would remove the sim boundary issue. But if the range dose not have a max, then every one would probable just put infinity into the call. And if there was a max, what should it be? If some one own a hole sim. I don't think they're going to want to have to put the script at the exact center of the sim, but they may want to have the permission work from any where in their sim.