Unique Object Keys...

I have successfully built a vendor/server script for a server located anywhere in SL. The problem is that the remote vendor needs to keyed to the object key of the server. Yet, for some very strange reason Linden Labs creates new keys every time an object is rezzed, even if it is no copy.

So, I install the server, everything works perfect. I return the server and place it at a new location only to have it break because it now has a new key.

Any ideas on how to keep the vendor and server in sync?

That is how it is
If you want to move an object and keep the key: attach it, travel to the new location and drop it. This way the object is not rezzed and the key is kept

Perhaps the server could keep a list of vendor keys and send them an "I am your new server" email when it is rezzed.

Otherwise, script a way for the newly-rezzed object to e-mail its key to whatever object it's supposed to be communicating with, or have both of them check in with an off-world server periodically and update their UUIDs.

ETA: Yup, what Pete said....

"I AM YOUR SERVER, LUKE"

Thanks for the advice. I think a combination of the above will work well.

Step 1) Rez vendor near servers and have the servers communicate to the vendor their keys, which you could create a server association pick list from a menu to make it easy for people. The vendor and server store each other's keys. Take up the vendor back into inventory.

Step 2) Rez the vendor in the appropriate location, have it transmit its old key and new key to the server it was just associated to.

If the server is Rezzed or moved, hence a new key, it can send to all associated vendors the updated key. If the vendors are moved, it can send both the old and new key to the associated server, the server can then delete the old key from its list and add the new key.

A little convoluted, but I think it will work.

Of course, it would be really cool if you could lock the key (hint hint, please please Mr. Lindens... bats eyelashes)

Yeah, it would be cool. Essentially, it would mean adding another "lock" checkbox in Edit that would prevent you from making a copy, modifying, or transferring ownership of the object. Suppose, though, that you created such an object, saved it in inventory, and then re-rezzed it and unchecked the box. If you then modified the object and checked the box a second time and then saved it, the asset servers would have a new version of the object but wouldn't have a new UUID with which to distinguish it from the original. There's probably a way around that problem, but it makes my head hurt to think about it.

Fah. After rereading your post and checking the portal, I'm not sure anything I have below is going to be useful to you - unless I'm missing something obvious. This is more useful for inter-sim usage.


object UUID's get changed on each rez, but owner keys do not and group keys *should* not but I have not yet tested that... [note: I'm using UUID and key interchangeably here, and while you only need the UUID's for email I'm generalizing this to chat as well]

key owner_id;
integer owner_ch;
owner_id = llGetOwner();
owner_ch = (integer)("0x"+llGetSubString((string)owner_id,-8,-1));

-or-

key grp_id;
integer grp_ch;
grp_id = llList2Key(llGetObjectDetails(llGetKey(), [OBJECT_GROUP]),0);
grp_ch = (integer)("0x"+llGetSubString((string)grp_id,-8,-1));

You can also derive a group key through llGetParcelDetails, or may want to use a creator key instead of an owner key, which would give the creator a backdoor channel to anything they create and give/sell (for maintenance only I sincerely hope).

Using the above method with llGetKey() to get the object's UUID and passing the derived channel as a start parameter for anything rezzed from it also gives you a sufficiently unique channel that can be also used to pass info back and forth to child objects (since object UUIDs can be detected I would not count on that for anything needing secure communication). The example I stole this from uses it to set up dialog channels which is also a good use.

You may find yourself using owner and group id's on several projects so if you derive a channel from them using the above method (shamelessly stolen from the portal's dialog tutorial -- well worth checking out because there's a lot of clever code hacks in it) I'd recommend munging it a bit for each project to eliminate overlap.

I've been thinking a lot on this since I have some vaguely defined dreams of establishing a service discovery protocol for all the stuff I'm working on -- such as hijacking a color change script in one object to change the color of another object on the fly.

I use a internet page that stores the uuid's of all my servers. The clients first check this internet page and grab the correct uuid before attempting communication with the in-world server.

Works like a charm.

Or, you could generate a unique serial number and put it into the description field. Then whenever it's rezzed it will send the new uuid, url, whatever to your database and update that information.