UUIDs, Asset IDs, and Keys. Oh My!!

Ok, if I read correctly all of the above; UUIDs, Asset IDs, and Keys; reffer to the same thing. They're all the same number. The question I have concerns when objects get new Keys. I have seen discussions and scripts that mention problems with objects getting a new dynamically generated key on server reboots, or when logging in, etc. Yet the key2Name database, and many scripts that use the key to reffer to a specific texture all rely on the keys never changing.

So I was wondering if someone would be so kind as to help me figgure out a table or something in regards to keys of avatars, scripts, textures, sounds, notecards, and objects and which ones are subject to change, along with under what circumstances? (eg. server reboot, sim crash, logging in, editing or changing, sim crossings etc.)

Also does having an object attached, versus in avatars inventory or an objects inventory in world, or even sitting in world itself, where applicable, make any differences?

This is getting a bit confusing, and I think a table describing common key behavior might help solve the riddle of which keys can be counted on and which cannot.

Thank you.

There are algorithms for making Unique Universal IDentifications, or UUIDs. The idea is that no matter what host, when, or where, if you generate a UUID it will be unique, at least on this internet.

To keep track of avatars, agents, objects, sims, and everything else, then need a unique "key". This is a database concept. SL uses a UUID for the key.

for example, it could use your avatar name, since those are unique. However, it doesn't, it uses a UUID. Your avatar name is stored under the UUID, and not the other way around.

This is why you can get two or more objects in your inventory with the same name. They have different UUIDs. Also, you can refer to things in scripts using their "key" (a UUID) even if they aren't in your object or inventory. They are in the database (the asset server) under that UUID.

Hope this is right

Avatars, textures, sounds, anims don't change key. I *think* not ever. Even if you give a copy to someone else, I'm pretty sure they keep a pointer to the texture by UUID so there's only one, but not 100% sure of that.

Objects change when rezzed (whether dropped in world or rezzed directly as an attachment). Since somewhen (1.9, 1.8 somewhere around then, when they introduced CHANGED_TELEPORT and CHANGED_SIM into the changed values anyway) moving sims doesn't change them.

Having something rezzed, right-clicking it and choosing wear (as attachment), then dropping it doesn't change its key.

Notecards get one key when created (possibly when saved rather than created, not 100% sure) and a new key whenever they're edited. Never tried for scripts, I'm assuming that's the same change though.

For the sake of this post i will refer to UUID's as keys.

When it comes to assets they fit into two categories: Instances & Originals (though there is a blurring between these two).

The inventory system is a system of references to originals assets stored on the asset server. Only originals are stored on the asset server. Assets are read-only, they can never be changed, updating an asset actually creates a new asset. Updating it's meta-data does not (the meta-data is a different type of asset).

An inventory reference is really just a wrapper. This wrapper defines the meta data for the asset: permissions, name & description. Currently the wrapper obfuscates the original key if full permissions are not granted; this is done to deter piracy (otherwise you could just rewrite the permissions in memory and trick the client & sim).

Inworld objects are instances of originals, they are given a temporary asset key to identify them. When they are taken or copied into inventory they are duplicated; the duplicate is then stored on the asset server with a new asset key. It is my understanding that it is up to the sim to keep track of objects inside the sim. When an object exists inworld the wrapper becomes part of the asset. When it is taken into inventory, the two are separated.

There is no way to tell the difference between keys, be it an instance key, asset key, obfuscated asset key, sim key, user key, or group key; which is a good thing.

One of the major flaws in my mind is that SL exposes asset keys to the users and incorporates an interface to use asset keys. This is a *bad* mix. You shouldn't be able to glean asset keys from the client and then be able to use them.

The solution to this is to create a new class of key: a reference key. A reference key would be a reference to an asset key. All script interfaces that support asset keys would be shifted over to use reference keys instead; all existing assets would automatically have reference keys assigned that matched their asset keys as to keep existing applications of asset keys functional. New assets would be assigned reference keys that would be different from their asset keys. This way asset keys could still be used in the client, without risk of the keys being misappropriated.

Why all the worry about reuse of asset keys? Say Bob unbeknown to Alice sniffs out the key of an image uploaded by Alice. Bob then uses the key on an object he didn't create and gives away for free with full permissions. Alice finds out months later and it is impossible for her to find out when on who misappropriated the image because the instance records have not been kept. The image was attached by asset key to an instance then that instance was transfered or taken into inventory etc. It would require very detailed logs to track down exactly when this happened. Not to mention have a copy of every instance of the object. If the records had been kept, it could be incredibly time consuming to identify when it happened; and it is possible that they may not ever identify who the culprit was.

With the reference key system, Bob would have to pirate the entire image and re-upload the image, to steal it. This would leave definite footprints in the asset server that would be unlikely to be erased. When Alice finds out months later, LL has the upload records showing that it was in fact Bob who stole it. Which would negate the need to pour over the instance & transfers records.

I've been wondering about this very thing. As part of my texture chooser, I want to be able to show the user the number of each face of a prim (so that they can define one face as "exteriorWall", another as "interiorWall", and so on).

I have the free alphanumeric textures, but would prefer not to have to include them in the inventory of objects I give away. I can refer to them just fine:

list numTextures = [
"1494e996-a91b-f770-bd10-ad788642d859",
"f545e486-2a2e-730d-845a-cbe9d4bcb9fd",
"16a84092-421f-3225-bb36-4071b55fab2d",
"4b0a62c4-65f4-932e-d440-7fe3cf5a1540",
"e0e7eacd-e956-14e6-df65-3bc3b7d4e679",
"6f579c89-bf1f-71d7-854d-b08341edf51e",
"a5063c9b-377c-1244-62b4-7ce5d1dbfafe",
"b055ba6a-d2ff-d67d-066c-ccb8a9e8300d",
"42b58e86-e83c-bc1b-4d73-ab3603d00d98"];   

(subsequent code allows flipping between current set of textures and display of numbers 0-9 on each prim face)

When I give the object to a friend in a different Sim, she doesn't get the number textures. Why? I think the permissions are wide open.

In short, what is the correct way to refer to some textures of alphanumerics without having to include every last one in inventory?

I was thinking of doing the same thing and even made some images that I was gonig to upload and make a script that would use the keys to load the images as textures on the correct faces.

I have 10 textures, numbered 0 through 9, with big numbers and a bunch of smaller numbers, and each a different color, in an attempt to make it so that you can tell which texture is on which side, even if it's very thin.

I would make it so that when dropped into a prim it would set the textures, then when touched, return the textures back to original state and delete itself.

From what I gather above, texture, sound, anim, avatar keys never change. Notecard keys change whenever edited because it creates a new object automatically. (does the old one get deleted?) scripts are unknown. and Objects when attached, or rezed get new keys, but no longer change when crossing sim borders.

How about when server reboots? or when an avatar who's wearing an object logs in? Do the keys still change when rezzing no-copy objects?

Sorry, strife.. i plugged that in and it made no sense to me.

Here is what I got for the sides.

list lstSides = [
"526bca06-2098-f41d-0470-b02b9e65ed78",
"11ff00a9-830b-84ae-6a25-0a6d8ca52720",
"fa6c56eb-8d3a-5b01-cfb0-e6296bfce5b0",
"138321b2-ebcc-3b2e-d756-6c2f4f5361d8",
"6c63420b-3037-8b3c-1c49-30c344579f95",
"8a869ba8-1141-aa16-b97e-ff4ca2d3dd7a",
"ef585372-a473-cfb1-cd9c-7cbbe5585dbe",
"b7853405-2ac1-f165-42da-450c8dd6cd49",
"0ae3dc39-8fc4-fd11-346c-153515bbdc49",
"29665faf-6036-fd93-41f1-e559c4c50295"
];

default
{
    state_entry()
    {
        integer i;
        for (i = 0; i <= 9; i++)
        {
            llSetTexture(llList2String(lstSides, i), i);
        }
    }
    
    touch_start(integer intNum)
    {
        llResetScript();
    }
}

Of course, now I have managed to hijack my own thread, so i'll leave any future developments of this script for another thread. For this thread, the original question was which keys are subject to change and under what circumstances.