Feedback: Dropping an attachment with permissions

This is a good question Kelly, and one that I'm going to bring up to my scripter friends.

Is this related to what you said?... I have been wondering about for the following for some time:


For example, I have a dance bracelet. I want to be able to put some animations that are NO COPY or otherwise do not have full permissions into it, but for some reason, I can't drag them into the bracelet while it's attached.

To do so, I soon realize (after some fudging around) that I have to Drop the bracelet first, and then, when it's on the floor, I can examine the Contents and put in animations that are NO COPY and/or NO MOD and/or NO TRANSFER.


Would this qualify as a bug of some sort or does it rely on something else? I was wondering about this for awhile because the current behavior has me scratching my head.

Its a good thing you told us Kelly.

Yes, unfortunatly I am going to rely on the functionaly of keeping permissions as the object is dropped. Infact, we were also going to use this for Unreal before some trouble with the fact that llDetachFromAvatar only detachs to inventory forced us to neglect the idea.

All in all, keeping permissions is a useful feature, even though you are right - something should be done about this when the script does not specificly needs it.

How about making this optional? Default - abandon permissions... but, if: "llKeepPermissions(TRUE)" or such, the object will continue to hold to them as its dropped. Just a concept.

I can just see the spam if a dance bracelet that isn't designed to stop on detach would cause, but I don't know of anyone off the top of my head that relies on the functionality, others may be different, thanks for asking. ^.^

llKeepPermissions might be a good option, as CrystalShard said, I think it'd be useful, though if they loose the permissions, it should have some form of flag so the 'unable to animate avatar' doesn't happen 50+ times, but merely right when it's dropped. (thus eliminating a spam problem)

When a dance bracelet is detached, it has to stop any animations it started. I can't remember if detaching cuases the attach even to fire BEFORE or AFTER the object has been detached. I would think it would be after, but then that is so, I'm serprise it fires when it's returned to inventory. If attach is triggered after the object has been droped, then revoking the permissions at drop, would mean the scripted object could not stop it's animation. This would cause problems.
Unless as part of the revoking prosses, any animation triggered by the revoke animation permistion is automatically stoped. Witch right now isn't the case.

What dance bracelet is failing to stop animation when it is droped? I only ask, because bug reports to scripters seem to be a rare. He or she might not even know her script has said problem.

I'm pretty sure with sitting and object, detecting stand happens after some an avatar stands. Revoking permission at stand, would cause problems. But you wouldn't notice it, unless your dealing with more then one avatar sitting on more then one prim in a link set.

This is a little tricky. Since some permissions are implicit, this currently can result in an unattached object that's got permissions you didn't grant it. Then again, just forcing the object to lose those persmissions sucks too -- most scripters don't seem to test against llGetPermissions() before each task they do that requires permissions. I haven't tested... does attach() get called with NULL_KEY when the av drops the attachment? BTW, what would happen when I drop and then wear an attachment, would it have to re-request (and be automatically granted) permissions again? This could lead to some nasty, hard-to-fix bugs.

You could just say "if you attached it, you probably meant to grant it permissions". Even if it's dropped, you still own it and you still trusted it at some point. Frankly, I think the better solution to this problem would be to allow the object to keep its permissions, but to create an interface whereby users can UNgrant permissions to any specific object. This has been bugged/suggested before.

I suggested just this the other day in the feature suggestion forum.

If you are going to release permissions then "run_time_permissions" should be thrown.

I"m kind of disturbed that debit is a run time permission.

Debt is a runtime because it needs to be authorized every time the script is compiled or reset, for security, last thing you need is a script that spits out singles to every random individual in a 96 meter radius with no way to stop it.

Or a cleverly writen script that at some later date sends all your money to a third party...

If some one had an object, and they wanted to attach it, and then have the object purposely drop. Only to have it reattach it self. Would they be able to do this with out having to grant the permission every time they use it?

In that case, Kelly, I'd say my vote is that you should have the object keep the permissions, because of the implicit trust you had in wearing it initially.

ah I guess that mean it fires after detach?