Changing object description before giving to an AV

Hi

I have an object which will be giving other objects from it's inventory to other AV's

What i would like to do is change the description of the object I am giving before it is given to the AV.
Any one know if this is possible?

thanks

llSetObjectDesc(). See http://lslwiki.net/lslwiki/wakka.php?wakka=llSetObjectDesc

Thanks, but

That only seems to work from within the object itself.
I want to change the description of an object in the objects inventory.

Basically what I am planning involves an object which when touched will give the user an object from it's inventory.
I wanted to set the object description in the object being given to a unique value before it's given, so that when the users rezzes the recieved object it can use that value to recieve data from a web page.
Using the avatar UUID is not practical for this as it is possible the avatar may recieve more than one of these these items, and would need to recieve a different response depending on which on is rezzed.

Ah.... So you put a script in the object that looks something like this...

default
{
on_rez(integer start_param)
{
     llSetObjectDesc("This is my new unique description");
     llRemoveInventory(llGetScriptName());
}
}

The object's description won't be changed as it is given, but when it is rezzed for the first time. Your script removes itself at that point.

Ok, that's good,

but the unique description needs to be generated by the object going the giving, hence the requirement to set it just before the inventory object is given to the AV.
But it's looking like that's not possible....

Time to rethink my concept I guess ....

Still no problem, although it makes life more complicated for you to set it up. Structure your on_rez event so that it sends an e-mail to the vendor identifying itself and then receives a unique response that sets its object description.

string VendorAddress = "the UUID of your vendor object goes here" + "@lsl.secondlife.com";
default
{
on_rez(integer start_param)
{
     llEmail(VendorAddress,"Newly Rezzed Object",llGetOwner()); // This sends the vendor the new owner's key as a message (or you could send llGetKey() )
     llSetTimerEvent(10);
}

timer()
{
     llGetNextEmail(VendorAddress,""); // Keep checking e-mail every 10 seconds
}

email(string time, string address, string subj, string message, integer num_left)
{
     llSetObjectDesc(message);
     llRemoveInventory(llGetScriptName()); This removes the script
}
}

In your vendor script, you include parallel language that receives the e-mail from the newly-rezzed object and sends a message that is to be stored as its description. This takes a little more work than you might have expected, but it's not impossible.

ETA: Ah.... I forgot to include the bit about removing this script once it has done its job. If you don't do that, it will send a new e-mail and reset its description every time the new owner rezzes it..... Fixed above.

that's very helpful thanks.

YW. I should probably mention that e-mail can be a bit clumsy at times. I haven't had much trouble myself, but it may take several cycles or, if SL's e-mail system hangs, a longer time for a message to get through. It's probably smart to put a few llOwnerSay calls in the script to let the new object's owner know what's happening. In the on_rez event, put something like ...

llGetOwner("Thank you for your purchase. Product registration is in progress .....";

and then in the timer event, put another one like ..

llGetOwner(" .... still working. If registration is not complete within 2 minutes, please contact me by IM for assistance. Niall Braveheart";

and finally, in the email event ....

llGetOwner("Registration is complete. Enjoy your product.";

A little cosmetic dressing can soothe anxious customers.

I would use the rezzed object's key as the unique ID, rather than having the giver-object create it.

Of course, if the object is copiable to next owner, it gets more comlicated, because its key will change each time it's rezzed. In that case, if rez-arg is nonzero, it gets its key and sets its description to the key. After that the description is used.

Easily avoided by rezzing with nonzero rez arg, and only doing the init behavior if rez arg is nonzero.

True. I just figure there's no reason to keep a script around once it's not needed. Extra baggage.

Right, assuming that's all the script does.

If you're communicating with the web anyway, why not get your unique value from your server on_rez instead? This way you can keep your values unique and if you are tracking your items by uuid, serial #, and owner then it's easier to do so in your database, and your web script will know if it's a newly bought product or something being re-rezzed, or if you throw in some http-in you'll even be able to tell if someone has more copies inworld than they should.

I didn't get the impression that the OP was communicating with an external server. If he were, though, that would open up a whole new realm of data possibilities, as you say.

Well ultimately it will be communicating to an external server.

The object is effectively a gift, and the purchaser will have an option to leave a additional info for the recipient, which will be stored on a server and retrieved at rez time.

The unique ID will be generated when the purchaser completes the purchase, which is why i want to set ot when the object is given to the utlimate recipient. It's possible an AV could recieve more than one objext from onr than one sender, so using the recipient AV's UUID isn't an option either (oh how much simpler that would be!!)

The object's UUID would be perfect too, but as that wouldn't be known until the object was rezzed i don't see how it can work in this scenario.

The object rezzing it can get the rezzed object's UUID, if that helps.

Unfortunately the object won't be rezzing it, but giving it directly to the other AV
who may then rezz it at anytime and/or location that suits them

That's exactly why I suggested having it register with the vending object when the new owner rezzes it. It doesn't need a unique ID until it is rezzed, so don't worry about creating one during the sale process. You can build a unique number in any number of ways (I suggest using a portion of the new owner's key, maybe adding a bit of the object's key or a model number... whatever) and then you have the object e-mail that number back home to the vendor. Now, if you're really going to be working with an external server, it does make sense to build a database of unique numbers there instead, as ElQ suggested. The idea's the same, though..... create an ID when the new owner rezzes the object and then send it somewhere that you can find it later, in world or outside.