From Second Life Wiki
|LSL Portal||Functions | Events | Types | Operators | Constants | Flow Control | Script Library | Categorized Library | Tutorials|
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.
SL uses Version 4 UUIDs as defined in RFC-4122, though there are some that are not V4.
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 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.
- 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.
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 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.
- 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.