Viewer Object System

Someone make this page prettier. Please.

The viewer objects are contained in the global gObjectList, which is the only instance of the class LLViewerObjectList (http://doc.daleglass.net/classLLViewerObjectList.html)

ViewerObjects are most things you see on the screen, such as prims, particles, trees, avatars, etc. A number of different types of viewer object exist, when an object is created the pcode variable passed to the createObject() function determines the object type:-

   LL_PCODE_VOLUME:   Most prims, includes attachments
   LL_PCODE_LEGACY_TREE:  Actually not legacy, a normal linden tree.
   LL_PCODE_LEGACY_GRASS: Not legacy, I don't think.
   LL_VO_CLOUDS:  Clouds
   LL_VO_SURFACE_PATCH: Terrain
   LL_VO_SKY:  The old non-windlight sky.
   LL_VO_STARS: Stars
   LL_VO_WATER: Water
   LL_VO_GROUND: Not terrain, the stuff that's under the terrain.
   LL_VO_PART_GROUP: ??

Legacy stuff:

   LL_PCODE_LEGACY_AVATAR:
   LL_PCODE_LEGACY_PART_SYS:
   LL_PCODE_TREE_NEW:
   LL_PCODE_LEGACY_TEXT_BUBBLE:

Each Object is represented by an instance of the LLViewerObject class (http://doc.daleglass.net/classLLViewerObject.html) but this will be sub-classed based on the PCODE that was passed to the createObject() function, in most cases this is a LLVOVolume for a PCODE = LL_PCODE_VOLUME (http://doc.daleglass.net/classLLVOVolume.html)

ObjectUpdate messages are handled by gObjectList.processObjectUpdate() this either updates an existing object if it is contained within the object list, or creates a new LLViewerObject to represent the object the viewer has just discovered from a server message.

Properties

Objects have quite a lot of properties that can be retrieved or set, which are available through accessor methods.

Some of the available functions include :-

• Position(s) Local/Global/Agent
• Rotations
• Scale
• permissions (read only from LLViewerObject)
• Various Flags for scripted/phantom/takes money,handles touch,cast shadows,temporary etc (read only);
• Active: If it's liable to change itself, i.e. scripted or physical
• Orphaned: If it's crossing a region boundary or in the process of being reparented.

After changing properties it is necessary to inform the server, this can be achieved with functions such as :-

• LLViewerObject::sendMaterialUpdate()
• LLViewerObject::sendRotationUpdate()
• LLViewerObject::sendPositionUpdate()
• LLViewerObject::sendScaleUpdate()
• LLViewerObject::sendShapeUpdate()
• LLViewerObject::sendTEUpdate() (Texture elements)

these functions all generate mesasges back to the server that contain the properties of the object. If you do not send the updates back to the server, the object will snap back to the original settings as soon as an object update package is received from the server that over writes your settings. Also no one else would be able to see the changes.

NB: I had difficulty sending multiple updates at once, it seemed i could send any one in isolation but i could not send for example a Rotation and a Position update, only the first sent would be respected.

Inventory

Whist Objects in world can have inventory, LLViewerObjects do not *automatically* and it may need to be requested from the server. The process to get inventory is asynchronous and you should :-

• Register an inventory listener with LLViewerObject::registerInventoryListener(LLVOInventoryListener* listener, void* user_data)
• Call LLViewerObject::requestInventory()

The class derived from LLVOInventoryListener should implement the inventoryChanged() function which will be called when the inventory details are received or are updated.

• When you are finished, clear the inventory listener (possibly in the deconstructor of your derrived LLVOInventoryListener).

Various other inventory access methods exist with in LLViewerObject but it is probably advisable to ensure you have requested the objects inventory from the server before attempting to use them.