Difference between revisions of "UUID"

From Second Life Wiki
Jump to navigation Jump to search
m (Undo revision 75270 by Zai Lynch I believe it qualifies for the a-an exception, like unicorn. http://owl.english.purdue.edu/handouts/ grammatically it didn't work)
m (Replaced <source> with <syntaxhighlight>, some spellchecking, added links to Wikipedia and intra-page (anchor) links)
 
(22 intermediate revisions by 10 users not shown)
Line 1: Line 1:
{{multi-lang}}{{LSL Header}}
{{Help |Glossary=*}}{{LSL Header}}


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.  See [http://en.wikipedia.org/wiki/UUID Wikipedia on UUIDs] for more information.
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 [http://en.wikipedia.org/wiki/UUID Wikipedia on UUIDs] for more information.


In LSL they are stored in the [[key]] variable type (which is a specialized form of a string).
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 have an UUID, which can be split up into four groups: [[UUID#Asset UUIDs|Asset]], [[UUID#Instance UUIDs|Instance]], [[UUID#Account UUIDs|Account]] and [[UUID#Land UUIDs|Land]] UUIDs.
<syntaxhighlight lang="lsl2">
key whatever = "01234567-89ab-cdef-0123-456789abcdef";
</syntaxhighlight>
SL uses Version 4 UUIDs as defined in {{RFC|4122|target=section-4.1.3}}, though there are some that are not V4.
<syntaxhighlight lang="lsl2">
key uuid = "xxxxxxxx-xxxx-4xxx-yxxx-xxxxxxxxxxxx";
//  where:
//      4 is 4
//      x is [0-9a-f]
//      y is [8-9a-b]
</syntaxhighlight>
=== UUID Version ===
While SL uses [https://en.wikipedia.org/wiki/Universally_unique_identifier#Version_4_(random) '''Version 4''' UUIDs] for some things (ex. All avatar UUIDs post ''~Jan 2006, exact date TBD''), you may find '''Version 5''' UUIDs (Generated by [[llGenerateKey]], ''July 2012 - present'' ('''''STC''''')), Version 3 UUIDs (Generated by [[llGenerateKey]], prior to July 2012), and '''non-standard UUIDs''' (All UUIDs prior to ''~Jan 2006, Exact date TBD''), ''∞-present'' for some assets (e.g. in-world objects, textures, etc.).
=== Inventory ===
Inventory as it is thought of is 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 de[[rez]]zed, 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 placed in a database where they await deletion but can still be revived.
=== Instance UUIDs ===
Every time an object is [[rez]]zed, all the prims (including the root prim) are assigned instance UUIDs. An avatar's attachment keeps its instance UUID 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.
While avatar UUIDs have been using [https://en.wikipedia.org/wiki/Universally_unique_identifier#Version_4_(random) Version 4 UUIDs] for more than a decade, you cannot assume that because a given key is not Version 4, that the asset the key is linked to is ''not'' an avatar — this is because older accounts have a non-standard UUID format assigned to them.
=== 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.
<!--* Joining parcels causes a new UUID to be assigned. -->

Latest revision as of 11:06, 7 April 2022

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 have an UUID, which can be split up into four groups: Asset, Instance, Account and Land UUIDs.

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

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

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

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

UUID Version

While SL uses Version 4 UUIDs for some things (ex. All avatar UUIDs post ~Jan 2006, exact date TBD), you may find Version 5 UUIDs (Generated by llGenerateKey, July 2012 - present (STC)), Version 3 UUIDs (Generated by llGenerateKey, prior to July 2012), and non-standard UUIDs (All UUIDs prior to ~Jan 2006, Exact date TBD), ∞-present for some assets (e.g. in-world objects, textures, etc.).

Inventory

Inventory as it is thought of is 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 placed in a database where they await deletion but can still be revived.

Instance UUIDs

Every time an object is rezzed, all the prims (including the root prim) are assigned instance UUIDs. An avatar's attachment keeps its instance UUID 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.

While avatar UUIDs have been using Version 4 UUIDs for more than a decade, you cannot assume that because a given key is not Version 4, that the asset the key is linked to is not an avatar — this is because older accounts have a non-standard UUID format assigned to them.

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).
  • 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.