Is the new 'run_time_permission' event call going to stay?

I assume you are going to remove the extra 'run_time_permission' event now triggered on every 'unsit' (changed event) or detach event?

This breaks a LOT of content which does permissions checking based on the fact that these events are triggered on a specific llRequestPermissions call. Not on some rogue permissions change caused by the camera code.

Although the assumption that the extra event triggering is the 'right' thing to do after a permissions change. The fact that the 'run_time_permissions' event changes from something that is 'planned' to happen after the llRequestpermissions (sequentially following). This now changes to a fully stateless system where the event can happen anytime.

This also assumes that people either now statefully trace the permissions themselves, as the permissions flag parameter is not directly related to the origin of the call. (It just lists the current permissions). Or that they move all logic that requires specific permissions in the 'changed' or 'attach' event, just assuming these permissions are granted.

Both doesn't seem like the optimal solution. All in all, i don't think the current change implementation is making a lot of people happy.

Thank you for the detailed info, Damani... I will check with the experts in LL QA about this.

First, pardon for the replicated post--didn't want to narrow our communication range here.

These recent postings all detail related experiences, so to connect them:
/139/b0/97398/1.html
/139/d2/97502/1.html
/139/ee/97281/1.html
/139/ae/97520/1.html
/54/f2/97438/1.html

Second, I'd like to apologize for the sheer frustration this has caused. As we have a history of doing--see Known Issues--we like to fix something like this agilely, sometimes quicker than a timeframe can be discussed, as was the case just the other day with the llXorBase64Strings problem.

To confirm, "llReleaseControls should fail silently if you do not have permissions", allowing for automatic revocation of permissions for animations and soforth, has JUST been fixed internally. Which means, pending verification, should be addressed in the next version of Second Life ASAP.

I witnessed amazing teamwork today in coordinating everything together.

Help is on the way, please be assured we very much care about things like this!