Releasing animation permissions when AVATAR has vanished

Standard recurring issue; but today I have the spare 3 minutes to wonder if it can ever be solved.

On an animated thingy (say MLP for instance but this issue can happen with others) you have an avatar using a poseball.

They don't leave the poseball via "stand up." Instead, they simply TP away, or log out, or, um crash.

So the "session" doesn't get closed normally.

When the next person comes along to use the poseball, a string of errors such as those shown below are generated.

Is there any way to trap this error, and to work around it? Currently the only way I know is shutting everything down and restarting. Bit of a nuisance in public places such as a store; you have to keep popping round every few days to make sure that it's not been borked. (yeah, I know, I could do a separate timer script that just restarts everything on a scheduled, and that will be my next step, but curious to know if there is otherwise any other way to sort this.)

[9:05] Animated MLP Object: llStopAnimation: Script trying to stop animations but agent not found
[9:05] Animated MLP Object: llStartAnimation: Script trying to trigger animations but agent not found
[9:05] Animated MLP Object: Climb In
[9:05] Animated MLP Object: llStopAnimation: Script trying to stop animations but agent not found
[9:05] Animated MLP Object: llStartAnimation: Script trying to trigger animations but agent not found

Rather than work too hard at it, I've taken to just checking that llGetPermissionsKey() matches the key I'm threatening to use with llStopAnimation(). From the chat log here, it appears that MLP also tries to push a "stand" or something onto the absent avatar, with an llStartAnimation(), presumably responding to the same CHANGED_LINK event; that call would have to be protected with the same test.

Of course if one doesn't have the source to modify then I don't think an appealing solution exists.

i hope not. because this is the only exception that allows human avatars to get in where bots have taken over.

Explain pls :}

After the permissions check, an llGetAgentSize() or llGetObjectDetails() check on the last sitting avatar works pretty well to kill just about all the debug shouts (permissions can linger after crashes/TPs.).

When an avatar stands up, logs off, crashes, teleports away, the changed() event with CHANGED_LINK should always be called in all of those circumstances, and llAvatarOnSitTarget() should be NULL_KEY (presuming you set a sit target, which is a natural presumption in the case of most scripted animation sit objects). Inside of that situation check, check to see if llGetPermissionsKey() returns something other than NULL_KEY, and, if necessary, check llKey2Name(avatarkey) != "".

Gets rid of all the nastiness.

Apperantly CHANGED_LINK doesnt work. Because it would turn of the animation if it would trigger the change event. All the pose/sitting balls have that to determine in avatar sat on them. U can put in script a check every time animation tries to stop or play. So it would be if(llAvatarOnSitTarget() != NULL_KEY) llTriggerAnimation("Animation";
else return;

That is the only way i can think about.

The only time CHANGED_LINK seems to work consistently is if they hit the "stand up" button.

Doing an extra permission check before llStopAnimation works better for stopping the errors.

tis works for me:

when a avatr getsonn a poe bal, you should us the 'changed' event with the CHANGE_LINK to capture the key of the seated avatar in a special key variable using llAvatarOnSitTarget(), for example 'SeatedAvatarKey'or something. When you get another changed even where the llAvatarONSit target == NULL_KEY, then use the llGetAnimationList to get all the anmations on that avatar and then stop them all in a for next statement. Then simply reset the script using llResetScript();

your script is then clean for the next avatar adventure and the avatar does not have any residual animations runing.

Avatars who teleport away whle in a pose, will only do that once - they usually have to re-log to get out of that animation.

if your product needs some specific infomation that is stored on the script and lost on reset, put the animation stuff in a separate script. In general, you want to create your product so that when users are done the script always resets. None of SL scropting is stable enough for scripts to last very long without attention.