Changed event for Ownership & llReturnToOwner()

As per this thread, we really need the following two features to make vendors of unique or combination items work more smoothly and with less server impact.


#1 - "changed" event notification for change of ownership

Add a new event flag for the changed() handler of CHANGED_OWNER so that when an object is set to Buy Original, the script can do something at the moment ownership changes. (Instead of having to run a timer, which might not get a chance to run before the obejct is taken or returned to the new owner's inventory because of land auto-return effects.)


#2 - llReturnToOwner()

Object the script is in is returned to its owner's inventory in the same way land auto-returns things. A compliment for llDie() that doesn't destroy the object completely. Also great for no-copy objects like vehicles that may be lost. A script to scan for the owner and llReturnToOwner() if they aren't in range would be a boon to vehicle owners everywhere.


(I'll mention this here as well as the Bug Report I sent...)
#3 - Reset rez timestamp for land auto-return purposes when ownership changes

Let's say we have an object that is set Buy Original and is on land set to auto-return objects every, say, 5 minutes, but the object is tagged with a group so that it doesn't get returned. When someone buys the object and the group tag is cleared. Right now, the object is returned right away (or as soon as the land does it's next sweep) instead of lasting the full 5 minutes. The timer needs to be reset so the new owner has time to take or interact with the object. It should be considered to be a "new" rezzing of the obejct.


(and a more pie-in-the-sky feature wish...)
#4 - llSetInventoryObjectDesc() / llSetInventoryObjectName()

Given the name of an inventory object, you can either change it or set its description. This would allow objects to be sold directly with uniquie information in them. Then when it is first rezed by the new owner, it can act on that information and change its look or funtion.

i love #4.

#1 Supported
#2 Supported
#3 Supported
#4 Supported

#2 could be done by just pushing the object offworld, (which would take a while since the voids have been filled in.


#5 llGiveMyself(), so we can make cool fractals out of anything (course you couldn't use it on no copy objects, or it would eat itself, which would be *very cool*)

Should I add...

#6 llSetPrice(string inventory, integer value) and integer llGetPrice(string inventory)
with inventory == NULL affecting the current object?

#7 llGiveInventory(string parameters) which would pass a set of parameters to the object given away (which could handle them inside a new event). I think this is quite hard to accomplish due to the way the asset server currently works. The alternative, of course, would be to implement inter-object messaging (even a slow way that does not rely on email would be more than adequate). We'd need something like a object_given() event on the giving side to get the object's UUID... and then we could llSendObjectMessage() to it


BTW, #1 will very likely be implemented as late as 1.7, due to the change in the permission system to accomodate Creative Commons and the complex copyright handling...

#6 Supported
#7 Supported

All supported. The first few are VERY important to me.

#7 really couldn't work since when an object is given, it goes right into their inventory. It doesn't exist as a running script to handle the string parameter, and trying to save that data in some way would go outside the system as it's designed. That's why I suggested #4 so you can stick the data in it's description or name for it to access next time the object is rezed.

#5 Is a meta-function, which are usually a bad idea to add to a language. It may open up many possibilities, but it also would permit a lot of very broken scripts. But the biggest problem is that the object only exists as a world reference when its script is running, not as an inventory item. It would be like a script-driven "take copy" command, which would have the effect of the copy's script being frozen on the next line, ready to start up from there when re-rezed. Messy. Fixing that would be messy too. If I was the one implementing new script functions, I wouldn't want to be responsible for debugging THIS one. (Calling it llTakeSelfCopy() might be more useful, though still have the same issues.)

#6 I've thought about this one before. I can see it as being abused, possibly, by changing an object's price unexpectedly in the middle of someone trying to buy it. It could work, but the system would have to be really ready to handle price changes in the middle of transactions safely.

Since we're going beyond the "theme" of the 1-3 ideas I started with, let me expand on #6 with some other ones I've been thinking about...

#8 llSetObjectPermissions() and llSetInventoryObjectPermissions()
These may be of more use when a new permissions system goes in, but even now they could be VERY useful. Objects could be scripted to release greater control to the new owners for a fee. Or objects could be scripted to allow particular people to manipulate them without having to mess with groups to do so. I've not mentioned it before since there are a number of issues here, I'm sure, that I haven't thought of yet. I'll start thinking on it now...

Tiger, thanks for your insight

Yes, I thought it would be impossible to "manipulate" things inside the inventory. Setting descriptions or even other things (imagine a generic field that all objects would be able to Set/Read, but not "visible" under Properties) is currently the way to pass information. - llSetInventoryObjectDesc() / llSetInventoryObjectName() would be more than adequate for that. Not perfect (until we wait for inter-object communication to be implemented...) but at least would come in handy!

I'm alarmed at the idea you gave about llSetPrice() being used for abuse if it is not implemented correctly! Wow. It really seems that I haven't got a criminal mind I always thought of the price as something like a "special" description and nothing else, I never thought before that one of the reasons why people can't change the price from within LSL is to avoid abuse! I consider myself enlightened I guess I'm just too naive and always thinking about the positive, creative things that would be possible if I had X or Y at my disposal, and never think about forms of abusing those things...

Excellent suggestion for #8, btw. Yes, this would facilitate lots of things, even right now!

I design and program user interfaces for games... I've been trained by experience to expect almost anything from the "average" user.