UUID

Template:Needs Translation/de Template:Needs Translation/es Template:Needs Translation/el Template:Needs Translation/he Template:Needs Translation/it Template:Needs Translation/ko Template:Needs Translation/nl Template:Needs Translation/hu Template:Needs Translation/no Template:Needs Translation/da Template:Needs Translation/sv Template:Needs Translation/tr Template:Needs Translation/pl Template:Needs Translation/pt Template:Needs Translation/th Template:Needs Translation/uk Template:Needs Translation/zh-Hans

UUID is an abbreviation for Universally Unique Identifier. It is a 128-bit (16 byte) value which is generated in such a way as to make collisions very unlikely. They are often represented as a string of 32 hex characters with four dashes interspersed. See Wikipedia on UUIDs for more information.

In LSL they are stored in the key variable type (which is a specialized form of a string).

The UUID and Secondlife

In Second Life every object and every avatar has an UUID and they can be split up into four groups: Asset, Instance, Account and Land UUID's.

<lsl>

   key whatever = "01234567-89ab-cdef-0123-456789abcdef";

</lsl>

SL uses Version 4 UUIDs as defined in RFC-4122, though there are some that are not V4.

<lsl>

   key uuid = "xxxxxxxx-xxxx-4xxx-yxxx-xxxxxxxxxxxx";

// where: // 4 is 4 // x is [0-9a-f] // y is [8-9a-b] </lsl>

Inventory

Inventory as it is thought of is really only a permissions layer. The inventory item, is really just a wrapper around an asset. The wrapper contains the permissions, creator & owner of the asset and a link to the asset. The link is the asset UUID.

Asset UUIDs

Asset UUIDs are used as the handle for all types that can be inventory items. The asset UUID is what is returned by llGetInventoryKey and by the "Copy UUID" feature in the client. Full (asset) permissions are required to get the UUID. Assets are immutable (they cannot be modified); when the user is editing an asset, they are in fact creating new assets. The appearance is that modified inventory items are assigned new UUIDs.

• Animation
• Gestures
• Objects
• Notecards
• Scripts
• Sounds
• Textures (including sculpty textures)

---

• When an Object is modified in-world, it is not assigned a new asset UUID until it is derezzed, copied back to inventory or during sim-state save. Modifying an instance of an asset will not update other instances or inventory copies.
• Brand new notecards are just asset wrappers without an asset. That is to say, new notecards have an asset UUID of NULL_KEY. The asset isn't created until the notecard is edited and then saved.
• Assets that are no longer inventory and are not referenced by any script are eventually deleted. Before they are deleted they are place in a database where they await deletion but can still be revived.

Instance UUIDs

Every time an object is rezzed, all of the prims (including the root prim) are assigned instance UUIDs. An avatar's attachments keeps it's instance UUIDs when the user teleports or moves from one region to another (they are not kept when an avatar logs off). The instance UUID is what is returned by llGetKey and other functions.

Account UUIDs

Account UUIDs are assigned during the creation process and never change. They are generally public information.

• Avatar - Public
• Group - Public or private depending on setup.

The avatar UUID is returned by llGetOwner and other functions.

Land UUIDs

• Parcel
• Region

---

• This information is technically available to the public but there is no interface to get at it directly (the UUIDs are sent to the client but consumed internally and never exposed to the user).
  • The parcel UUID is returned by llGetParcelDetails.
• Only one instance of these can exist in-world at any time.
  • When copied, new UUIDs are assigned.
• Modification does not cause a new UUID to be assigned.