Can't get rid of annoying script debug/error message even though offending object deleted

[GloriaGlitter]

Hello there - wonder if anyone has a solution to this:

I am getting this message "Script trying to trigger animations but PERMISSION_TRIGGER_ANIMATION permission not set" a few times a minute while on my sim.  Have deleted the offending object but message persits.  Have tried 'Stop Avatar Animations & Revoke Permissions' but didn't help.  Was hoping region reset would get rid of it but it didn't.  Have tried a couple of viewers (Firestorm & SecondLife) but still get the message.

Grateful for any ideas how to stop this.

Thanks

[Codex Alpha]

Is it on  your avatar or anything you're wearing? I had a similar issue once, it wouldn't stop, but it was a script looking for a missing part in an outfit, and once I deleted it off my person, the script stopped.

[GloriaGlitter]

Hi Codex - thanks for your suggestion.  Its not something I'm wearing - I did check that.  The messages only start once I am on my sim and not anywhere else.  It comes from a piece of scripted furniture that I have since deleted but the debug messages still come every 30 seconds.  Apart from getting rid of my sim which is a bit drastic, I can't think of anything else to try.

[belindacarson]

Have you tried looking around the area it was on? It could possibly be a pose ball left underground?

 

FFirestor has an area search, or use transparent.

 

Do you own the sim or rent it? Asking support or the sim owner to check using the estate tools.

[Odaks]

Firestorm's Wiki has this to offer:-

Error message:

“Script trying to trigger animation but PERMISSION_TRIGGER_ANIMATION permission not set.”

This error message means that an object of yours is trying to animate you but is unable to. This happens most commonly when you have rezzed an item in-world (perhaps accidentally) that is meant to be worn. However, the object may be either worn or rezzed in-world.

Sometimes, a script needs to ask your permission even if it's worn. Some people miss this. Look in your notifications (the envelope icon), System tab, find the message and open it, and click Accept.

The name of the item will show on the tab at the bottom of the script error window.

If you are not sure whether the item is worn or rezzed,

Look in Inventory → Current Outfit folder for the item. If it is there, detach it. The error message should stop. If you get this error every time you wear the item, contact the maker of the item for assistance.

If the item is not worn, find the item and take it or delete it. It's position in the region usually shows in the object's tab in the script error window. If you have trouble finding it, use Area Search or Build menu → Pathfinding → Region Objects to help locate it.

[Frionil Fang]

Being part of deleted furniture sounds like it was a poseball used by an old poseball-driven piece, and said poseball is transparent, placed inside some other object or too small to notice. Like others have suggested, using Area Search or highlighting transparent objects (control-alt-T) to hunt down things near where you had the furniture might help. Also, when a problem of that type occurs, the object should gain a small notification icon like this above it (it does not stay for too long) to signify which item was causing the error:

 

[GloriaGlitter]

Thanks for your suggestions.  Have searched for lost poseballs using Search Area and turning on transparent - nothing around.  Its not anything I'm wearing.  No objects with warning icons lurking around.  Had sim owner search as well but he couldn't find anything either.  The deleted furniture item in question didn't use poseballs but avsitter system.  It seems to defy logic - I get the script error message every 30 seconds when on the sim I'm renting - it says the name of the furniture piece giving out the script error even though its deleted and doesn't show up in search.  Seems like a ghost.

[Qie Niangao]

Thing is, the object must exist in order to generate the error message. As @Odaks said, the Script Warning / Error window should usually identifies not only the name of the object but also its 3D coordinates. Is that not happening?

Incidentally, an attachment could try to start an animation only when it's in a particular region, so the fact you only get the message on your home sim is not conclusive evidence that you're not wearing the object generating the error. (You may have already removed all attachments and the error keeps returning anyway; that's the easiest way to test whether the culprit is an attachment or not.)

(I'm seeing something strange about this particular error message that I never noticed before: it doesn't appear to be communicated openly on DEBUG_CHANNEL, or at least a scripted listen() on that channel isn't getting it. Instead it's as if it's doing llRegionSayTo() on that channel directly to the owner, but I've yet to figure out what's going on there. The idea was to use a script to give more details about whatever is emitting the message, but no luck so far.)

[GloriaGlitter]

It does put out the error messages on the debug channel but doesn't give out the co-ordinates.  Here is a screeen shot of the errors - https://gyazo.com/70a009ae0e627eef63c663dda9bfa9fa

Checked and double checked that I'm not wearing the object.  The object is a bed

[Frionil Fang]

57 minutes ago, GloriaGlitter said:

It does put out the error messages on the debug channel but doesn't give out the co-ordinates.

The chat header in that script error/debug window is not clickable, but if you can catch the message in the normal local chat tab the object header becomes clickable and shows you the precise location.

If you don't get those messages in local chat, you can enable it in preferences: Notifications->Objects&Scripts->Report Script Errors in: Local Chat.

Edit: further checking shows that you are getting that message from an object on a different region altogether.

If the erroring object was on the same region, your screenshot of the script error window would say "Bed FFF (x, y, z)", but since it only says "Bed FFF" it doesn't know the location as it's not a local object. Consequently, the above trick with local chat direction won't work; the chat header will say the object is at (0, 0, 0).

Edited May 28, 2022 by Frionil Fang

[Aishagain]

This issue reminds me of a problem that plagued me several years ago.  The script message was actually from an RLV active device I had used on another region and had totally forgotten about.  In the end I managed to click on the chat header and I then blocked the object/script and my issue went away.  That may be your only resolution.

[Odaks]

All very strange. @GloriaGlitter - These sort of oddities plague all of us at one time or another, so please keep us updated with how things go!

 

[Codex Alpha]

6 hours ago, GloriaGlitter said:

It does put out the error messages on the debug channel but doesn't give out the co-ordinates.  Here is a screeen shot of the errors - https://gyazo.com/70a009ae0e627eef63c663dda9bfa9fa

Checked and double checked that I'm not wearing the object.  The object is a bed

Thanks for posting what you tried, and what suggestions or other worked or didn't work. It is very valuable for everyone who wants to help, and as well as I learned something myself what to look for and search (and what works and didn't) should we ever run into the same problem. Thanks.

[GloriaGlitter]

Have solved the problem.  When I changed preferences to put error messages into local chat so I could click the object name - I was getting <0,0,0> so I assumed that it wasn't in my region.  I looked around on neighbouring parcels but couldnt find anything.  Then I had inspiration to check sky rooms.  Found the object at 2800 mtrs high.  Reset scripts and problem solved.  The thing that confused was that the debug messages kept coming despite the distance but search tools couldn't find it and the coordinates was showing as <0,0,0>. 

Thanks to everyone that offered ideas.

[Wulfie Reanimator]

It's kind of bizarre how the script error transcends sim boundaries, even from one standalone (not border-connected) sim to another. Wiki says "the script will shout an error on DEBUG_CHANNEL," but obviously it's doing more than just shouting on a channel, if the message can arrive like this.

Actually... after relogging, I was no longer able to make that error appear until I visited the sim where the script was. Seems like the sim needs to be aware of the avatar, since I will also stop receiving the error some time after leaving the sim.

 

The error will always be displayed to the owner of the object, regardless of who has granted permission to the script (and would be animated), or who causes the event where the error occurs.

Edited May 28, 2022 by Wulfie Reanimator

[Jaylinbridges]

On 5/28/2022 at 11:37 AM, GloriaGlitter said:

debug messages kept coming despite the distance but search tools couldn't find it

The Firestorm Area Search only detects objects within a 96m radius of your avatar location. This is horizontal radius, so at 2800m you would not see it unless you were standing underneath the 96m detection zone on the ground.   Actually for elevated objects, the detection might go farther, depending on your angle vector to the object.  Speaking from experience looking for lost kittycats on a parcel...

To find lost objects with Area Search, I fly from ground to 4096m and in several parcel sectors.   FS Area search has its limitations.   The sim owner should have been able to find it though with region software.  

 

[Solar Legion]

5 minutes ago, Jaylinbridges said:

The Firestorm Area Search only detects objects within a 96m radius of your avatar location.

Yeah, no. That might be the default behavior but it is not a hard limit.

[Jaylinbridges]

Well in the past when I use Area Search on a full region of shops for instance, looking for a particular named object, I don't see everything listed in the List at once.  I have to fly around to see objects being detected, and there was a 96m limit.  Objects listed were always being removed and added, based on distance from my avatar. If the Filter Default is as shown above (like mine is), maybe the limit is 96m horizontal, but is not stated. Then checking the "Distance between" box allows it to search to a 99999 m limit?   it will be easy to check this out on a fully populated market sim.  Checking the distance box and the list will then grow to over 100,000 objects. I shall see...

 

[Rowan Amore]

Area search generally searches up to your draw distance.

ETA...Area search will list objects that the viewer is aware of. There are many objects in your vicinity that the viewer may not be aware of. So in order to have those picked up, turn around, and move around, or cam around. as the viewer picks up more objects, they will be added to the list. Similarly, if you cam or move away some distance, objects can drop off the list as the viewer “forgets” them.
The above is expected behavior, and not a bug.

Edited May 31, 2022 by Rowan Amore

[Jaylinbridges]

1 hour ago, Rowan Amore said:

Area search generally searches up to your draw distance.

Keyword there is "generally" .   It's not a hard cut off though, with DD at 512 Area Search is seeing objects up to 546 m on my test regions. Also can see objects at 3993 m in the sky, but not everything up there.   With DD set to 32 m, can still see everything out to 113 m.  DD at 72 and still see out to 113 m.  So DD does not limit on the low end it seems.

Can not see sky items that are out of the range of DD based on horizontal radius on the ground.  DD at 128 can see objects out to 246 m.. Generally not linear or consistent.

At my home parcel, with DD set to 80 and 3000 m the sky, I can see some objects at 3200 m away, but not owned my me or on my parcel.  I cannot see my beach objects 3000 m below me, on my own parcel.  Rather confusing I'd say.

Filter was set to see all parcels and Neighboring Regions, btw.  The Distance between setting was not checked.  It is only a cutoff filter for listing, not detection.

Edited May 31, 2022 by Jaylinbridges

[Qie Niangao]

Yeah, Area Search may be handy for some stuff* but this is not one of those cases. Having to fly up and check out a skybox to find the item is a pretty good hint that there must be a better way, and indeed there is: Build / Pathfinding / Region Objects. It works regardless of landowner (in case the target washed ashore on a neighbor's parcel), but if the item strayed across a region border, the query would need to be run on that neighboring sim, too. But it would find the target when Area Search would not, at least not without a lot of work.

I'm still baffled what this permissions error-messaging is using as a delivery mechanism. Maybe some specially-keyed version of llOwnerSay() ? Whatever it is, viewers are able to re-route it (to chat) along with everything else in the Script Warning/Error window, despite it not messaging through the region's DEBUG_CHANNEL (which is very frustrating). I wonder if this behavior changed at some point.

I had the idea maybe it still used DEBUG_CHANNEL but with a direct llRegionSayTo()-like mechanism for the owner (scripts can't llRegionSayTo over DEBUG_CHANNEL, and these messages aren't strictly region-bound anyway), so I hacked a trivial attachment script to see if it could sniff those messages: still no luck.

___________________
* I guess. Personally I prefer a little attached sensor-range "finder" script I hacked up for most such applications.

[Wulfie Reanimator]

39 minutes ago, Qie Niangao said:

I'm still baffled what this permissions error-messaging is using as a delivery mechanism. Maybe some specially-keyed version of llOwnerSay() ? Whatever it is, viewers are able to re-route it (to chat) along with everything else in the Script Warning/Error window, despite it not messaging through the region's DEBUG_CHANNEL (which is very frustrating). I wonder if this behavior changed at some point.

Probably something related to the same thing as functions like llKey2Name which only work if the avatar has recently been in the sim.

As to the viewer being able to redirect it to chat, that's not particularly special, the viewer can generate any kind of chat message regardless of if it actually originated from chat (or any source). I'd have to check where debug messages are pulled from to figure out that part of the puzzle.