This is an old revision of the document!
Table of Contents
Object UUIDs
The SL issue Duplicates
To touch or sit on, and object, the object needs to be identified. The object name is not unique. For instance, you rez out a chair, called “Chair”, you duplicate that chair 5 times, you now have 6 objects called “Chair”. If you were to command an AvaDroid to sit on the Chair, well you can see the issue, which chair to sit on.
The SL issue Linked Objects
Similarly, linked objects, are a composition of one “Root” object and linked “Child” objects. It is seen as one object. An Example, commonly “Dance Pads” comprise of the Root Object (pad) and numerous Linked objects (pads), to instruct the AvaDroid to sit on Dance Pad will have it attempt to sit on the Root Dance pad as it can't see the other pads.
The Solution
Every rezzed object has a UNIQUE UUID. 6 chairs will have 6 unique UUID identifiers. In linked objects, the Root object will have a unique UUID identifier and each child object will have a unique UUID identifier .
How does SL and OS handle object UUIDs? The Asset DataBase has 1 copy of a specific object with all the object details. Many people may have this Object in their Inventory, which is a list, with an item object pointing to the one item in the asset DataBase. Each item in your Inventory has a unique UUID , just for you. When you rez that item out into the world, a Copy is rezzed with its own unique UUID, different from the DataBase UUID and your inventory UUID. The rezzed copy, UUID wise, is unique.
The solution is to work with UUIDs to be accurate and specific.
