Detect if script has been transferred...

I'm sure I can work this out myself, but was wondering if anyone already has a solution to save myself some time

I want to sell an object copy/transfer so that the customer can deed the object to a group (so they can play media on group owned land).

However, if they try to transfer it to another avatar I want the script to either stop working or delete itself or come up with a rude message... the "once transferred do this" bit I can do myself quite happily.

So basically I want someone to be able to deed to a group but not resell/transfer... it already detects if it's been deeded, so that's no problem.. but how to check easily if it's been transferred to another avatar? Does CHANGED_OWNER still work if the item is not "bought"?

Thanks

Yes, works also for items you give away (because the item will get a new owner! lol)

Well yes.. that had occurred to me but the Wiki just mentions buying so I was concerned that dropping in someones inventory wouldn't pass the neccessary test....

Not when you drop it in their inventory, but the first time they rezz it, the event will be processed!

One gotcha is that deeding will also trigger CHANGED_OWNER.

You can use llGetObjectDetails(llGetKey(), [OBJECT_GROUP]) and compare that against llGetOwner to tell if the object was deeded. But then it gets messy, because undeeding the object later on will change the owner yet again. You could leave in this transfer loophole, leave things so that once deeded, the object can't be reclaimed, or try to figure out some kind of semi-robust way to remember the last avatar owner.

Note that an invalid new owner could probably rez the object on a no-script parcel and deed it to a group before moving it or enabling scripts on the parcel, so the object wouldn't know there was an intermediate owner (so ANYONE, not just the intended first owner, could deed to a group).

Could you divide the functionality into an object that can be deeded and a no-transfer object the legitimate owner must use to activate it or something?

Plus wouldn't a forced script reset cause havoc here? Like a Reset Scripts in Selection, or sim reset/restart? I don't know much about when resets can be forced, so just asking.

There may be a better way to work your situation through ... but here's a thought:

1 - On transfer get the new owner key.

2 - then llRequestAgentData() ... any variable really ...

If the owner-key is a group, the llRequestAgentData() will NOT fire a dataserver event.

...however, if the owner-key is an avatar, the dataserver event WILL fire ... and you can make the object yell/scream/self-delete/etc.

Thanks for all the suggestions... in the end I kept thinking of ways someone could get around any solution I tried so have fallen back to the item rezzing a mod/copy/transfer ball that can be deeded and talks to the item via a channel.

Of course, that came with problems of cross-talk for which some swapping of keys was needed, but it seems to be a reasonable solution.

Good deal. I'd use the start parameter to help eliminate cross-talk. That can be used to establish a random channel on which the parent and child objects can communicate. You could also or instead establish some kind of encryption or (more likely) authentication based on a shared secret and maybe the key of the rezzed object or something.