Jump to content

Animations scripts errors


MBeatrix
 Share

You are about to reply to a thread that has been inactive for 3492 days.

Please take a moment to consider if this thread is worth bumping.

Recommended Posts

For a bit more than 2 weeks now I've been getting script errors quite often, while changing animations on seats or interacting with pets, for example.  And it is happening to other people, too. Here's a very recent example (while dropping one of my cats to the ground):

[14:32] KittyCats - Phoenix: Script trying to stop animations but PERMISSION_TRIGGER_ANIMATION permission not set

The issue happens with boats and other vehicles as well — but not all the time —, no matter what region I am at.

Any idea about why all of a sudden this started to happen and persists? I use the latest Firestorm release (yeah, it's getting old, I know) and I'm wondering if it's a viewer issue due to some recent changes on the server side...

Link to comment
Share on other sites

From what a friendly top designer told me, the server code was changed and caused many (MANY) problems that will need to be fixed. I found this out when I reported a seat that had worked perfectly before gave missing animation messages. If I remember correctly it has something to do with the sit target but since I only use the most basic 2006 sit scripts LOL, it doesn't really effect me.

 

 

Link to comment
Share on other sites

Hmm. That's a pretty common error anyway. Are you sure it hasn't always happened when Dropping that particular item?

I suppose it's possible that something has changed in the retention of permissions by scripts when detached.

It wouldn't be a viewer-specific thing. Those are sim-side errors, usually generated by buggy scripts.

Link to comment
Share on other sites

Hmm. That's a pretty common error anyway. Are you sure it hasn't always happened when Dropping that particular item?

Yes, I am sure — it happens with both my cats, with all my boats and some chairs, but it's intermitent.

 

I suppose it's possible that something has changed in the retention of permissions by scripts when detached.

It wouldn't be a viewer-specific thing. Those are sim-side errors, usually generated by buggy scripts.

Or the sim running slow/having hiccups? But it happens to me in many different regions (e.g. when sailing.)

Link to comment
Share on other sites

From what a friendly top designer told me, the server code was changed and caused many (MANY) problems that will need to be fixed. I found this out when I reported a seat that had worked perfectly before gave missing animation messages. If I remember correctly it has something to do with the sit target but since I only use the most basic 2006 sit scripts LOL, it doesn't really effect me.

Right. I suspected something like that, since it started to happen all of a sudden and there hasn't been any changes on my side.

Link to comment
Share on other sites

Recently I have noticed in some regions that AO (ZHAO) stops working and there are lots of script errors coming from it. I have changed absolutely nothing in the AO. Not very common problem but it exists anyway - recently.

I have noticed that detaching and re-attaching the AO usually fixes things. Sometimes I need to TP to different region to get the AO working again.

Link to comment
Share on other sites

If a script throws that error it tries to end your sitting animation after you got up but doesn't have the permission to do so.

The script should check that permission but it obviously doesnt.

In the past you could get away with that but there is - for example - that firestorm setting "revoke permissions on stand". If that setting works as promised it will trigger that error on careless scripts.

And for the AO - I don't know what fancy ideas this script includes. Things change in SL and scripts that are a bit sloppy may break when things change.

 

Link to comment
Share on other sites

If a script throws that error it tries to end your sitting animation after you got up but doesn't have the permission to do so.

The script should check that permission but it obviously doesnt.

In the past you could get away with that but there is - for example - that firestorm setting "revoke permissions on stand". If that setting works as promised it will trigger that error on careless scripts.

Yes, but "revoke permissions on stand" doesn't explain the "animation not found" error that occurs once in a while, too. It seems to be rather a perfomance issue.

Link to comment
Share on other sites

Recently I have noticed in some regions that AO (ZHAO) stops working and there are lots of script errors coming from it. I have changed absolutely nothing in the AO. Not very common problem but it exists anyway - recently.

I have noticed that detaching and re-attaching the AO usually fixes things. Sometimes I need to TP to different region to get the AO working again.

Yes, that seems to be a common problem around SL. A friend of mine complains that her Vista AO stopped working completely.

I don't have AO related issues because I use the Firestorm built-in one.

Link to comment
Share on other sites


MBeatrix wrote:

If a script throws that error it tries to end your sitting animation after you got up but doesn't have the permission to do so.

The script should check that permission but it obviously doesnt.

In the past you could get away with that but there is - for example - that firestorm setting "revoke permissions on stand". If that setting works as promised it will trigger that error on careless scripts.

Yes, but "revoke permissions on stand" doesn't explain the "animation not found" error that occurs once in a while, too. It seems to be rather a perfomance issue.

That never happens in my scripts :)

So I consider that as a bug. It can be a race condition. The scripter assumes that things happen in a specific order rather than making sure things work. You can get away with that, but not always and if SL changes this scripts can break completely.

Link to comment
Share on other sites

So I consider that as a bug. It can be a race condition. The scripter assumes that things happen in a specific order rather than making sure things work. You can get away with that, but not always and if SL changes this scripts can break completely.

That makes sense to me, but what do I know? :smileywink:

Still, it's kinda weird that some of the most important boats builders in SL could be so sloppy — not to mention other creators.

Anyway, I just get the errors but the items seem to keep working OK. In the case of the cats, just as a precaution, I take them into inventory and rez them again, to reset the scripts. The boats seem to recover themselves, and many times when changing position again the error doesn't happen.

Link to comment
Share on other sites

A couple observations. Once you have permissions to start an animation, you always have permission to stop it EXCEPT if a viewer breaks things, such as the Firestorm "revoke on stand" which does NOT exist in the official viewer. Once you have permissions, it's crazy to keep checking for it over and over everytime you do an animation change - all that does is make your script laggy. As everyone knows, script lag is a serious problem and poorly designed scripts that do needless things cause a lot of it.

Experience Keys goes even farther with the "always allow" if you read up on it.

I would simply ignore these obnoxious errors, and would STRONGLY recommend NOT hammering the permission system over and over and over to eliminate them. Instead, a better solution would be for LL to recognize that there is a very popular misbehaving viewer out there that can cause them, and implement a way for us to always silently ignore those errors if we choose to do so (like so many other things we can choose to ignore.) Perhaps file a bug report (feature request) asking for that in the LL JIRA.

Revoke on Stand could have been implemented in a way that wouldn't cause these issues, such as adding a delay to the revoke of a couple seconds after a stand. Perhaps file a JIRA on the Firestorm site asking for this since they are the ones causing the problem in the first place.

Link to comment
Share on other sites


Sharie Criss wrote:

Experience Keys goes even farther with the "always allow" if you read up on it.

Actually it's the other way 'round. Experience permissions can be revoked in the Linden (Experience Tools beta) viewer -- the agent can forget or block the whole Experience. On the other hand, the whole way scripts use permissions changes dramatically for Experience Tools scripts because a single script will interleave many different avatars through different parts of the Experience simultaneously. As a result, Experience scripts call llRequestExperiencePermissions (much) more often than non-Experience scripts call llRequestPermissions().-- but on the plus side, there's no need for a proliferation of scripts each holding one agent's permissions.

(To the larger topic, I'm not really sure it's the Firestorm viewer's permission-revocation that's causing the OP's problem. I've never liked that feature because its effectiveness is necessarily so limited by being viewer-side only.  Still, it's not obvious why this should suddenly cause the OP problems more than or different from before.)

Link to comment
Share on other sites

If you read the documentation you linked to....

"the decision to allow or block the request is persistent"

That fits 100% with my statement Once you have permission, you have it for everything requested, you don't have to keep requesting it over and over. Perhaps you are misreading or what I wrote. Furthermore...

"estate managers will always see the permission dialog even if the experience has been previously approved. "

This basically means that if scripts did what you suggest, constantly call and ask for permission, estate managers would be deluged by the permision request dialogs. I plan on using ExperienceKeys on my regions, and I sure as heck don't want to be hammered with permission requests all day long! That would be extremely bad programming.

You are better off letting the errors happen and dealing with it than than pounding the crap out of the script engine causing needless lag. Frankly, the permission system has been broken "forever" and despite countless pleas over the years, LL has failed to address any of the concerns brought up. It would be SO much better to have a graceful way of handling script errors.

(Hint: debug channel is one way.)

Link to comment
Share on other sites


Sharie Criss wrote:

If you read the documentation you linked to....

"the decision to allow or block the request is persistent"

That fits 100% with my statement Once you have permission, you have it for everything requested, you don't have to keep requesting it over and over. 

It doesn't actually work that way. I too got a little confused about this at first, and even after I figured it out, I couldn't come up with improved wording for the wiki articles. In short, an Experience-enabled script still has active permissions for only one agent at a time. If it wants to switch to another avatar in the Experience, it must switch that permission target, too. The script can still use llGetPermissionsKey() to find which agent for which it currently has permissions, so it knows when it needs to switch, but when it does, it needs to call one of the llRequest*Permissions functions.

On the other hand, that bit about Estate Managers and God Mode users always seeing the permissions dialog seems very odd indeed. I can't actually test what that means because I'm not an Estate Manager (my beta Experience is deployed only on Mainland). If that means what it seems to say, maybe Experience scripts really do need to check to see if they can get away with calling only llRequestPermissions, not llRequestExperiencePermissions, when deployed on Estates, despite the extra code needed for that logic. (I actually had all that code in my script at one point, then decided it was wasteful and blew it all away.) There's not a lot of sample code yet, so I'll post a question in the beta forum and see what folks are doing. 

[ETA: Oh, I forgot to mention, what seemed to be the issue at hand was the way FIrestorm can revoke animation permissions on stand, so I took the "always allow" aspect of Experience Tools to refer to scripts being able to assume that they retain permissions they've been granted; I wanted to point out that in fact Experience scripts have even more vulnerability to those permissions being pulled out from under them by the user revoking the whole Experience, and that's still correct. I have always thought that not getting a run_time_permissions() event when permissions are lost is a design flaw of the SL permissions system, and so it may be of interest that Experience scripts get a related feature, the experience_permissions_denied event, which is more useful than it sounds.]

[ETA2: Actually, never mind the idea of using llRequestPermissions instead of llRequestExperiencePermissions; I was misremembering something, and that just won't work. One can, however, avoid requesting experience permissions if the last avatar to use the script is the same as the one it wants to operate on again, and that may be a good thing to do, assuming that avatar hasn't revoked permissions in the meantime. I doubt that actually saves any processing, and certainly adds to the code size, but would be worth it to avoid bugging an Estate Manager over and over, if that really happens.]

Link to comment
Share on other sites

Geez, you guys went too tech for me here... :matte-motes-tongue:

Anyway, the scripts errors seem to happen kinda randomly. In the case of KittyCats, I get a script error when dropping them because the animation had not been started. The same happens with boats, sometimes. And some other times, animations can't be started because they could not be found by the script — but they are there. From my non tech opinion, it seems to be a timing thing... The servers not responding in due time to trigger the animation? The issues are intermitent.

Link to comment
Share on other sites

Depends on if the script is made sloppy or bullet proof.

For example: the scripts expect that the avatar uses the stand button to get up. What is if someone TP's out, logs out crashes gets separated from the vehicle on a sim crossing? There is an extra check needed which many scripts seem not to do. The firestorm setting is one of the special cases too.

Animation not found? Never got that problem but I usually am not on laggy sims. I doubt that this is a timing problem though.

Link to comment
Share on other sites

For example: the scripts expect that the avatar uses the stand button to get up. What is if someone TP's out, logs out crashes gets separated from the vehicle on a sim crossing?

That's totally not the case. Also, concerning my cats (or boats) it is intermitent. When I cuddle a cat and I don't get the pose, I know I am going to get the error when dropping it. But, as I wrote quite a few times here, it is intermitent and started happening recently — and I'm not the only one experiencing the issue.

 

There is an extra check needed which many scripts seem not to do.

Yes, I believe you're right.

 

The firestorm setting is one of the special cases too.

Again, totally not the case, since I have all revoke permissions options disabled.

 

Animation not found? Never got that problem but I usually am not on laggy sims. I doubt that this is a timing problem though.

I spend most of my time at mainland sims, which sometimes can be laggy, as you know. About the timing idea, I don't have the knowledge to disagree or agree with you, so I'm keeping that as an open option.

Link to comment
Share on other sites


Qie Niangao wrote:


Sharie Criss wrote:

If you read the documentation you linked to....

"the decision to allow or block the request is persistent"

That fits 100% with my statement Once you have permission, you have it for everything requested, you don't have to keep requesting it over and over. 

It doesn't actually work that way. I too got a little confused about this at first, and even after I figured it out, I couldn't come up with improved wording for the wiki articles. In short, an Experience-enabled script still has active permissions for only one agent at a time. If it wants to switch to another avatar in the Experience, it must switch that permission target, too. The script can still use
llGetPermissionsKey() to find
 which agent for which it currently has permissions, so it knows when it needs to switch, but when it does, it needs to call one of the llRequest*Permissions functions.

Actually, it DOES work that way. Ever wondered why a dance ball has so many scripts? Or that many furniture items to? It's exactly so the script can maintain permissions. In an Experience, if you are doing it correctly, you are going to have a Master Controller that has these permission scripts, and other little things here and there and everywhere that trigger Experience actions are going to send a quick message to the master telling it to do something to the avi. That Master script will be the one that maintains all the state for the Avi as your little triggers won't have the brains to do it. Another alternative that many people do is to give the user a HUD that will maintain the permissions and initiates the actions.

There are many ways around LL's super limited script engine, and you have to employ them to provide a decent experience to the users. LL's insistance that a script can only maintain one avi's permisions at a time is one of those limitations that people script around all the time. And it kind of sucks, because it DOES require more "needless" scripts, but as they are not active unless actually doing something it really isn't a big deal. These anim / permission scripts are also small and don't use much memory (and as we know, the memory reporting of scripts is fatally flawed as it always reports a full 64K for Mono scripts when they may only be using 2K.)

Cheers!

Link to comment
Share on other sites

HUDs are commonly used in some kinds of applications that Experiences target, for example the sort of "game" that involves scores and levels and other read-outs private to a player. Legacy HUDs from before Experience Tools can get away with minimal re-scripting if they continue to operate that way, but before Experience Permissions we were forced to use attachments for operations that no longer require them.

Similarly, we used to be forced to use a separate script per avatar to hold permissions for things such as danceballs, but that's all unnecessary now for Experience-associated avatars. It will continue to work, of course, but we're now able to do all that with a single script that switches among avatars. That saves memory and reduces the number of scripts in the scheduler's queue.

Just in passing, if an Experience still needs HUDs, they don't necessarily need a central controller anymore, now that they can record (and communicate) player state using the experience persistent store. Legacy games can continue with minimal rework, of course, but new experiences written from scratch will usually adopt the more direct approach.

But returning to the OP's problem: I have scripts watching DEBUG_CHANNEL around some of my servers and they see rare errors related to scripts not finding assets that are certainly present in the object contents. It happens when trying to access notecards and other scripts, so there's every reason to suppose the same could happen with animations. I haven't noticed any change in how often this occurs for the other asset types, although there have been bursts in the past that may have coincided with asset server maintenance.

Also, i very vaguely recall a slight change in how permissions are handled at sim crossing, but that would have been probably a year or more ago, if I'm remembering it at all correctly. No idea if that's related to anything you're seeing, but I seem to recall some old vehicle scripts needing to be reworked to properly check for permissions after sim crossings, both for animations and controls. My memory of all this is very fuzzy, however, so the jira might reveal what really changed if it matters. I get the sense, however, that the problems in this thread don't involve crossing sim borders.

Link to comment
Share on other sites

[...] I get the sense, however, that the problems in this thread don't involve crossing sim borders.

That's right, Qie, it doesn't. My KittyCats, for example, don't travel with me — I cuddle them at my parcel only, and the same happens with at least another person I know. The same is valid for boats when I change position/animation, even when they are moored. Also, as I wrote a few times in this thread, the issue is intermitent, but it happens a lot more with cats than with boats.

Another thing I've been noticing lately, is related to dance machines (the Intan, for example.) Sometimes, it takes more than used to be normal to get the animations responding, and that is happening everywhere. It seems that SL servers got a lot slower...

Link to comment
Share on other sites

You are about to reply to a thread that has been inactive for 3492 days.

Please take a moment to consider if this thread is worth bumping.

Please sign in to comment

You will be able to leave a comment after signing in



Sign In Now
 Share

×
×
  • Create New...