Object IDs ?

I fear that what seems common sense to me has proved false once again in SL. Here's the issue as I try to use Object ID as a key to a web service.

I own an object that is NO MOD/NO COPY

This object is removed from my inventory when it is rezzed. Makes sense so far. Exactly one copy of this object exists in the universe. I can rez/take/rez/take all I want and will still only have one copy - sometimes in-world and sometimes in my inventory.

After building a web service to interact with this object, based upon its object id as verification of purchase, it appears the the object actually gets a new object ID every time it's rezzed. Is this correct? Really, then, there is no such thing as no-copy. Every object is brand-spanking new copy of it's original every time it's rezzed and all that no-copy means is that the original is deleted from the owner's inventory whenever a new copy is rezzed. Right?

I think I can get around this easy enough by generating my own unique key that stays with the object but, if I'm correct, I'm stunned. I'm a computer geek for a living and it seems to me that there's no wonder the Lindens are having continual database problems. All that inserting and deleting is hard on a database. I would have never dreamed and can not imagine why they wouldn't just re-rez an existing object with a static ID and reference back to the database instead of create a new row. Anyway - I digress.

Before I rewrite my code here, can someone confirm that I'm correct and not missing something? Also - if an object is really rezzed new when taken from inventory, doesn't that automatically mean it's back at state default? I see all kinds of cautions in the lsl wiki about state retention... how can a new object retain a state that existed only in the original?

I'm so confused?!?!? For you more knowledgeable scripters out there - is there another gotcha waiting for me down the road that I don't know enough to ask yet? All I want to do is use an object I can vend that serves as a "ticket" to a web service. I want the object to be giftable (transferable) but, obviously, not copyable. I also want a given AV to be able to purchase multiple "tickets" so I can't use AV as a key either. The existence of the object is proof of purchase. Is there some other way to identify an object with a PERSISTENT key in-world that can reliably interact with my web server? Maybe Object ID is not actually the unique database key?

Thanks.

your correct, everytime you rez an object, it gets a new UUID

as for the state, no it doesnt default to a state upon rez, unless you code it that way. If you take an object into inventory, it will save the state its currently in, and does not change by rezzing it again, unless you specifically code for it

there are ways to get around the UUID issue using your own database, however you generating a unique ID would have no effect on an object in-world, i.e. you cant give an object a specific UUID key

Thanks. I understand that I'd have to store my own unique key with the object. Perhaps the object description field. I already have a few hacker protections in place so visibility is not an issue. Unless I'm missing something - there is absolutely no way for a given object to be uniquely identified persistent across multiple rezzings so I must create that persistence myself and in a place where I can write it (i.e. not a notecard). I really want to make this seamless to the user. Until now - I didn't understand why most purchased objects interacting with the outside world were such a pain to set up. I'm determined to get around this.

If anyone has design suggestions they would be appreciated.

sorry, but if you find a way to keep the key between rezzings, I think hundreds of scripters would love to know...

not without some sort of php/mysql or similar backend system. Your going to have to store the data outside of SL for doing what you want to do I believe. It CAN be done, I've done it with my update server... but for your specific instance and without specifics I couldnt point you in any direction other than its possible, just not within the confines of SL

Saving state and values is your friend for what you want to do.

At time of purchase you can set an value; for example-

MY_UUID = string(llGetOwner()) + llGetTimeStamp();

This value will not change after purchase and you can use it anyway you like.

A few suggestions:

* You could give the object a specific name and do an llSensor to get its key. Have the object doing the llSensor always rezzed so that it retains its key and communicate with that.

* Have the always rezzed object llShout or llSay, and use llListen for a specific response. You can get the key of the responder when you get the correct message. Communicate with the always-rezzed object to get the key.

* Have your object contact a server outside of LL and send its key there when it gets rezzed. You could extend that by having the object save its key each time it is rezzed. Have it introduct itself to your server and send the previously saved key at the same time so that you know to delete the old one (avoids 'orphaned' keys in your database).

* Use one of the three above in an attachment - they key does not change until you remove it and avoids having one always rezzed prim on your land.

* Drop the whole idea and change your overall approach

I'm sure there are more clever approaches -- these are the basic ones.

-2fast

Thanks. Great ideas. LOL Nabob. I've been programming for a lot of years now and it took me too long to realize that - sometimes - starting over was faster than trying to salvage a flawed design - no mater how many lines of code I'd already written.

Yes - I think my approach will be to capture the original UUID since I know it's unique and simply store that in my web database, as well as, save it in the object with a state variable. Then I can ignore the actual UUID assigned and just reference my own. I've done some proof-of-concept testing enough to think this is going to be a relatively easy fix. Thanks for the help.

I still can't believe SL works this way but I'm sure their DB designers must have their reasons.