Avatar automatically denying animation permission

[Shaade Fallen]

Hey there =3

I'm having something of a problem regarding animating my avatar with furniture.

My avatar seems to be automatically denying the furniture permission to animate me - and the only fix I have is to reset my furniture.  The problem with this though, is that I seem to have to reset the furniture every time I leave the area and return - and this can take several minutes for each piece of furniture. It's really starting to iriitate me...

Does anyone have any idea what might be causing this?

Thanks

 

[ObviousAltIsObvious]

Xpose has a bug that causes it to break this way if animation permission is removed with the RevokePermissions server message.

It appears that at least recent MLP V2 furniture is not affected, it properly checks for permissions and asks again if needed.

There could be other scripts with bugs like this, the moving poseball type is most likely to be affected.

This is not really a new thing, some of the third party viewers have offered functions to revoke animation permission when you stand up. on the server side this ability has been supported for a very long time.

One thing is new: since a few months ago, LL viewers send this message out when Me>Movement>Stop Animating Me s chosen. Animation permissions are revoked from any script in the region that has them for you.

In either case, once this message is sent, an Xpose pose ball will not work for you again until somebody else sits on it, or you reset the furniture.

So, avoid using "stop animating me" in the same region where there is any Xpose furniture that you want to use.

If you use Firestorm or a similar viewer, you should make sure that Revoke Permisisons under Preferences>Firestorm>Protection is set to Never unless you are in a heavy grief area like a public sandbox.

 

 

 

[Shaade Fallen]

Ah, the 'stop animating me' function would certainly explain it as i've been using it alot recently. Thanks much for the info <3

[Innula Zenovka]

I'm not sure I would describe it as a bug in Xpose so much as a bug in Firestorm 4.5.1 (38838), since it seems  to affect only people who are using this particular release of the  viewer.  

Simply not using the pose stand in Firestorm appears to mitigate, if not cure the problem.  I don't use Firestorm much, so I'm not familiar with the viewer's  pose stand.   I didn't even know it had one!

Anyway, here's a full write-up of the problem in the Firestorm Jira: http://jira.phoenixviewer.com/browse/FIRE-12148

[ObviousAltIsObvious]

I don't use this Firestorm pose stand and have experienced the bug, and can repro it with other viewers, so it is not really a Firestorm issue. It really is that Xpose incorrectly assumes it still has permission, if the same avatar sits on a pose ball again.

 

[Innula Zenovka]

Thanks. I stand corrected, then.  I was mislead by the way that the comments in the Firestorm jira suggested this bug was only an issue since the newest release of that viewer.  Maybe LL changed something round the same time it was released.

I know that getting rid of permissions has always been a bit of an issue with both MPLV and Xpose, but I hadn't realised that Xpose sometimes won't ask for permissions.   I have worked with XPose quite a bit, but not recently, and I haven't heard of problems from any of the for whom I did the work, so maybe it's an intermittent thing.

I dunno.   I am trying to imagine how (or why) you'd script something so it could fall down like that.   Something like 

if (id != llGetPermissionsKey()){

llRequestPermissions (id, PERMISSION_TRIGGER_ANIMATION);

}

would be vulnerable, I guess, but I can't see why anyone would want to use a test like that.   

[ObviousAltIsObvious]

I think the problem is that these scripts with remote seats don't want to ask for permission every time, if they don't have to, so they don't annoy their users as much. They should check both llGetPermissions() and llGetPermissionsKey() before they decide to forego a fresh permission request. When animation permission is revoked via a server message, any other set permissions will stay behind, so llGetPermissionsKey() alone is not really a safe check.

You can reproduce this yourself. try it with a recent LL viewer because it will reliably send this revoke request.

Get a pose ball to rez on any Xpose furniture, have a seat and grant animatin permission.

Stand and sit again, to confirm that it remembered you and didn't ask for permission a second time.

Stand again, and pick Me>Movement>Stop Animating Me.

Sit another time on the same pose ball. the animation does not start, and no new permissions are requested. This persists even if a "STOP" button is pressed and new balls are rezzed, the script simply assumes that the same avatar in that position still has the same permissions.

Repeat the same test with MLP V2.4 furniture, and notice that after the Stop Animating Me step, the script correctly asks for fresh animation permission on the next sit.

 

Well this is a surprise. Firestorm beta 4.5.1.38838 uses new enough upstream code that it does also send this message with Avatar>Avatar Health>Stop Avatar Animations.

 

 

 

[Ansariel Hiller]

As Firestorm dev I can say that this is clearly an XPOSE issue (incorrect way of triggering animations without prior check if animation permission is still granted).

The issue on our JIRA leads to the conclusion that only the integrated pose stand in Firestorm 4.5.1 is affected, but as already mentioned previously, also stopping animations from the "Me" menu in any recent V3-based viewer will trigger this bug. While I have already worked around this bug in conjunction with the pose stand for the next Firestorm release, it will still happen whenever stopping animations from the "Me" menu is invoked - unless you set the debug setting RevokePermsOnStopAnimation to FALSE. That will stop animations, but leave all granted permissions to objects intact. This will work on any V3-based viewer.

[Perrie Juran]

---

Ansariel Hiller wrote:

As Firestorm dev I can say that this is clearly an XPOSE issue (incorrect way of triggering animations without prior check if animation permission is still granted).

 

The issue on 

our JIRA

leads to the conclusion that only the integrated pose stand in Firestorm 4.5.1 is affected, but as already mentioned previously, also stopping animations from the "Me" menu in any recent V3-based viewer will trigger this bug. While I have already worked around this bug in conjunction with the pose stand for the next Firestorm release, it will still happen whenever stopping animations from the "Me" menu is invoked - unless you set the debug setting

RevokePermsOnStopAnimation

to FALSE. That will stop animations, but leave all granted permissions to objects intact. This will work on any V3-based viewer.

---

Is this risky?  It sounds counter productive to

MAINT-2867[c][PUBLIC] Object can obtain and retain permissions indefinitely without avatar's knowledge and no way of knowing who took it - possible security issue

• MAINT-2879[c] Viewer should revoke animation permissions with "Stop Animating Me"

 

Discussed in this thread.

It would seem to me that someone should be very cautious about changing this debug setting.

I don't know so I am asking.

[Ansariel Hiller]

It depends. If you change the mentioned setting to false, invoking stopping avatar animations will not revoke script permissions granted to any objects in the current region. It will basically revert the function to the old behavior where it will stop animations, but if you granted permission to some griefer object for instance, it will retain the permission and can animate you over and over again.

To make a long story short: You should know what you are intending when using the stop animation function. If there is an object (or griefer) constantly animating you, you should definitely set that debug setting to TRUE to revoke permission. If you don't need or want to do that, it should be safe to set that setting to FALSE.

[Perrie Juran]

---

Ansariel Hiller wrote:

It depends. If you change the mentioned setting to false, invoking stopping avatar animations will not revoke script permissions granted to any objects in the current region. It will basically revert the function to the old behavior where it will stop animations, but if you granted permission to some griefer object for instance, it will retain the permission and can animate you over and over again.

 

To make a long story short: You should know what you are intending when using the stop animation function. If there is an object (or griefer) constantly animating you, you should definitely set that debug setting to TRUE to revoke permission. If you don't need or want to do that, it should be safe to set that setting to FALSE.

---

Thanks for answering.

I don't know if it has been technical difficulties or that they did not consider it important enough, but it has taken years for LL to do something about the persistant permissions that Griefers exploit.

Personally I don't think they have done enough.  A lot of griefing would be easier to deal with if they did more.

So it is better that people understand what they are doing and the potential hazard if they change this setting.

[Ansariel Hiller]

Based on the XPOSE bug workaround I added to the Firestorm code recently, I could split that stop animation function in two: One function would just stop animations without revoking permissions, and the other function will additionally revoke permissions, too. So you wouldn't need to hassle with debug settings and have both methods at hand. That won't help anyone on another viewer though.

[Perrie Juran]

---

Ansariel Hiller wrote:

Based on the XPOSE bug workaround I added to the Firestorm code recently, I could split that stop animation function in two: One function would just stop animations without revoking permissions, and the other function will additionally revoke permissions, too. So you wouldn't need to hassle with debug settings and have both methods at hand. That won't help anyone on another viewer though.

---

Being that most people have little to no understanding about permissions that could confuse the heck out of a lot of people.  Though it might not hurt for them to learn something.

If you did do that, other TPV's might do it also.

As far as LL doing it in the Official Viewer, maybe when hell froze over.

 

 

[Ansariel Hiller]

So... Added both options to Firestorm for next release!

[Codex Alpha]

This is still continuing in some capacity today.

I found this nifty little fact out today as I was trying to position avatar poses in some furniture and wondering for the life of me what the hell was going on.,

Apparently I had used "Stop animating me" due to certain tools making me do that for some reason, and in the LL Viewer (even after full re-install and default preferences) continued to revoke animation permissions in the background with no notice.

Dora Gustafson helped me work it out (or at least be a good sounding board) as we worked together to figure out why I was having the issues I was having.

In the end it took a fresh install of Firestorm to find out that the issue was with some revoke setting in the LL Viewer. Until I can figure out how to reset it (already tried experimenting in debug settings), I have to use Firestorm when I want to work with posing and positioning tools in SL.

This had been happening for months in some of my home regions for months, I just thought the tools were flawed.

I consider myself a power user and a very good troubleshooter, and even this had me stumped for months.