Script autodestruct code

I have a script that runs when the object is in the wear position on an avatar. When the AV returns the object to her/his inventory, I would like the script in it to self destruct and not play again in that object, or have the object disappear or die, if the AV tries to Rez it again. Can something along this line be done in SL, and if so is there code to insert in the script to get this to happen? If anyone has such code, I would appreciate a copy. Thanks.

You can't get it to self-destruct when they take it off and return it to their inventory just then, since the code stops running at that point.

But, you could set a variable in it so that the first time it is worn, it runs ok, and then sets a die-next-time-worn variable. So the next time they try to wear it or rez it, it dies.

The function to self-destruct is llDie()

I think you'll need llDetachFromAvatar() for this, as llDie() doesn't work on attachments.

Keep in mind that llDie() does *not* work on attached objects.
The object will have to do a llDetach or something first.

Re-reading the original post, it's possible that just removing the script is a desirable alternative, which is readily accomplished with "llRemoveInventory(llGetScriptName());" (attached or not, I believe).

When the item is attached let the script do what it does and switch state.

In the new state you should react to the

on_rez event with llDie();

and to the

on_attach() event with llSay(0, "This item has already been used, please delete it"; and llDetachFromAvatar();

This should take care of everything.

can't the user reset the script to get around that?

As long as you don't give him modify rights for the script I see no way to reset it ...

Yeah, this is a sad situation, all 'round. God knows how many no-mod attachments have been destroyed by orbital "weapons" because this kludge was put in place, preventing end-user resets without mod perms, which according to legend was done to work-around some historical exploit (though off the top of my head, I can't think how this could exploit anything other than an already flawed script, unless there's an associated VM bug, too). There are a couple of jiras relevant to this mess:

https://jira.secondlife.com/browse/MISC-317 : "orbitting 'weapons' moving you to insane altitude, temp-breaking attachments, requiring one to relog." (Personally not crazy about suggested solution, but something has to be done here: the last thing SL needs now is reduplicating traffic on the login service, caused by what amounts to an exploit of a VM defect.)

https://jira.secondlife.com/browse/VWR-575 : "Ability to reset scripts in no-mod objects" (One variant of this would still permit scripters to set a special "No-Reset" permission on the script, but hopefully cooler heads will prevail.)