4.7 - Identifying Objects

Table of Contents

• 4.7.1 Identifying Objects in DIS
• 4.7.2 Identifying Objects in HLA
• 4.7.3 How VR-Link Identifies Objects
  • 4.7.3.1 Choosing A Name in HLA

HLA and DIS identify objects differently.

4.7.1 Identifying Objects in DIS

In DIS, entities are identified by a triplet (site:application:entity) known as an entity identifier. This structure can be represented in VR-Link using the DtEntityIdentifier class (defined in entityIdentifier.h). Non-entity objects are identified in various ways. For example, emitter systems are identified using the Entity Identifier of the host entity plus an additional emitter number.

4.7.2 Identifying Objects in HLA

In HLA, an object can be identified in several ways:

• All objects have an object handle – that an application uses to identify a particular object in RTI service calls. In HLA 1.3, the object handle is an integer. In the HLA 1516, the object handle is variable length data. The object handle is unique within a federation execution.
• All objects also have an object name – a character string that can be used to identify an object. The object name is known to the RTI, and the RTI provides functions to find out an object's name, given its handle, and vice versa. Object names can be chosen by applications that register the objects with the RTI, however if you do not want to choose names for objects, the RTI will assign names for you. Object names are represented using char*, or VR-Link's DtString class.
• FOMs may choose to define other ways of identifying particular kinds of objects. These other identifiers are merely attributes of the object, and do not have any special identifier characteristics as far as the RTI is concerned. For example, the BaseEntity class in the RPR FOM contains an attribute called EntityID that is represented by a DIS-style Entity Identifier triplet – the DtEntityIdentifier class in VR-Link.

4.7.3 How VR-Link Identifies Objects

To support protocol independence, VR-Link provides two types that can be useful in passing around the various types of identifiers.

You can use a DtObjectId (defined in objectId.h) (or local ID) regardless of protocol, to identify an object within an application, but it cannot be used to communicate the identity of an object to other applications in PDUs, interactions, or attribute updates. In HLA, DtObjectId is a class that serves as a wrapper around an RTI::ObjectHandle. In DIS, we typedef DtObjectId to DtEntityIdentifier.

You can use a DtGlobalObjectDesignator (or global ID) regardless of protocol to identify an entity in inter-application communication within PDUs, interactions, and attribute updates. In HLA, we typedef DtGlobalObjectDesignator to DtString – a VR-Link wrapper around char* that can be used to store object names. In DIS, we typedef DtGlobalObjectDesignator to DtEntityIdentifier, since in DIS that same type of ID is used to identify an object both within an application, and between applications.

Reflected object lists allow you to look up reflected objects by local ID or by global ID. DtObjectPublishers and DtReflectedObjects have functions to return both the object's local ID (id() or objectId()) and global ID (globalId()). PDU, interaction, and state repository classes have mutator functions that expect global IDs and inspector functions that return global IDs.

For example, if you have a DtEntityPublisher representing an entity that you are simulating, and you are sending a fire interaction, indicating that your entity is firing a munition, you might say:

fireInter.setAttackerId(entityPub.globalId());

If you receive a fire interaction from a particular entity, and want to find out more about its state, you can look up the entity in a reflected entity list like this:

DtReflectedEntity* ent = rel.lookup(fireInter.attackerId());

When constructing an HLA publisher, you can either choose a name for your object, or pass a NULL name (the default), and let the RTI choose for you. For examples, please see 4.5 - Working with Locally Simulated Entities.

4.7.3.1 Choosing A Name in HLA

In HLA, you can choose a name for an object. In HLA 1516, the RTI might reject the name. Therefore, the name must be reserved before you create a publisher. If you do not reserve the name, VR-Link reserves it for you, however, this may take time.

To reserve a name, call:

myExconn->rtiAmb()->reserveObjectInstanceName();

VR-Link caches all reserved names. Make sure you call tick() to allow the RTI to respond. Then you can create a publisher with the name you reserved. For more details, please see 4.5.1.2 Choosing Entity Identifiers.

[<< Working with Remote Entities] [Home] [Top of Page] [Working with Other Types of Objects >>]