making a no copy object inventory item return on death?

i see no way in events to determine if an object is drezzing. I have something written that will rez an objects contents when the main object is rezed but no way to derez anything when it is taken back.
what am i missing? figured there'd be a destroyed event or something.
since i want the objects in the objecty inventory to be no copy they need to get back there if despawned.

Doesn't matter if object permissions are set copy or no copy, you can not return an object to inventory by using a script. Hence, you never,ever want to rez no copy items.

Right click only.

there is no way for an object to know when it is deleted, returned, or derezzed.

Exeption: attachments fire a detach event and get some script time to process it.

This will probably start an argument ... but you could always have your object temp rez its contents? Of course it won't derez straight away, but will eventually... and you've got to keep rezzing to keep it there.

Have a great little grand piano from Second Way that does this...

wonder who though this api up .....

yeah, or rethink your permissions. If you have something that you want to rez by script, and derez, then really you want that item to be copyable. Perhaps you'd be better off making your project no transfer.

Then the rezzer can rez however many copies of "it" that it needs to, and they can just "die" on the ground. You can add a function where if they are rezzed without a start parameter, then they self delete. So if the owner "takes" the thing, it can go "hey I'm supposed to come out of a rezzer" and die.

One way you can do this is to have the contents "ping back" to the rezzer, and if they don't receive a response within a given number of tries/minutes, then the "contents"object(s) can self delete. I think there's also a way for a child object to determine the key of it's rezzing parent. So you could then set up a sensor that searches for the parent, and if the parent gets out of range, (not found) then self destruct. I think this is how the SLWim floaties work.

Best way I know of is to pass a large random channel number through the 'on_rez' start parameter, then have the rezzing script communicate on that channel. It's a good way to pass additional data to the rezzed object as well, though you should probably be careful of timing so the communication isn't missed (maybe initiate communication from the rezzed object).

There's no built-in way to know the identity of the thing that rezzed an object, though there is the reverse: you DO get an event that tells you the key of the object you just rezzed. Unfortunately, you get this even even if another script in the prim (or object?) did the rezzing, so you have to be a little careful if there's any chance multiple scripts could be rezzing objects at the same time. Hope that none will rez objects with the same name, and use llKey2Name(), maybe. Or once again rely on communication, and have the rezzed object chat on the channel given.

That's right, I had it backwards.

Here's what the wiki says:
Q: Is there a way to get the key of the object or agent that rezzed this object?
A: No, not directly. The easiest way is to have the rezzer say something (for example a codeword) after executing llRezObject, and have the script in your rezzed object listen for it in chat. The rezzer's id will then be handed to the rezzed object's listen event handler. You can use a short llSleep delay in the rezzer object if your script isn't hearing it.