3.2 - How the Object Manager Creates an Object

Table of Contents

• 3.2.1 How the Object Manager Chooses an Object's Subcomponents
• 3.2.2 Identifying Objects
• 3.2.3 Looking Up Objects
• 3.2.4 The Object Type
  • 3.2.4.1 Predefined Object Types
• 3.2.5 The Object Name
• 3.2.6 The Echelon ID
• 3.2.7 The Object Label

The Object Manager needs to create an instance of DtVrfObject for each simulated object.

It does so as follows:

1. The Object Manager calls DtVrfObject::createObject() to create an instance of a new DtVrfObject. The DtObjectType and a Boolean flag, indicating whether the object is local or remote, are cached by the object for further construction in its virtual create() function.
2. The Object Manager calls DtVrfObject::create(). Using the DtObjectType as the key, it looks up the object parameter database entry for the object. The appropriate subcomponent list is chosen based on the local/remote flag cached by the object in its constructor. (For details, please see 3.2.1 How the Object Manager Chooses an Object's Subcomponents.) Each of the subcomponents is created through a factory method, given the corresponding type string specified in the subcomponent list.
3. The Object Manager calls DtVrfObject::init(). This invokes the init() functions on each of its subcomponents. Upon completion of this call, the object is fully initialized and ready to be ticked.
4. The Object Manager adds the new object to its list of objects to be managed.

The Object Manager ticks all of its objects (local and remote) in its tick() function.

Note

For a description of how you can add object types, please see 3.5.2 Creating a New Local Object and "CreatinganEntity.

3.2.1 How the Object Manager Chooses an Object's Subcomponents

This section expands on step 2 in the previous section. When the Object Manager creates an instance of a DtVrfObject, it needs to configure it with different subcomponents, depending on whether or not the object is local or remote. The Object Manager knows which subcomponents to use because the object parameter database entry for each object specifies two lists of subcomponents, one for local objects; the other for remote objects. The strings in the subcomponent list correspond to the C++ objects that make up a DtVrfObject (through a has-a relationship).

When the Object Manager creates a new object, it looks up the entry in the object parameter database for the object type to be created. The Object Manager passes the object’s local or remote status into the DtVrfObject constructor. When the new object gets initialized by the Object Manager, it:

1. Looks up its entry in the object parameter database.
2. Determines if it is a local or remote object.
3. Instantiates the set of subcomponents from the corresponding subcomponent list (local-objects or remote-objects). Each item in the subcomponent list is created from a factory.

For example, if the object is a local object and the state-repository component lists the string ground-entity-state-repository, the Object Manager knows that it has to create a DtGroundVehicleStateRepository for this object. The figure illustrates this process using the subcomponent list for a ground vehicle.

Creating an Object

The following list matches the subcomponent strings to their base class. To find the subclasses for the various subcomponents, please see the class documentation for the base class and navigate to the subclass that you are interested in. Each subclass has a type() member function that returns the type string for the component. The type is registered with the appropriate factory and is what gets specified in the object parameter database.

• state-repository: DtVrfObjectStateRepository
• net-interface: DtSimObjectNetInterface
• task-manager: DtSimTaskManager
• plan-manager: DtVrfObjectPlanManager
• component-manager: DtSimComponentManager.

At any given time, the Object Manager may maintain a mix of local and remote objects.

Note

The Component Manager, Task Manager, and Plan Manager are created only for VR-Forces objects.

3.2.2 Identifying Objects

A DtVrfObject can be uniquely identified through one of the following:

• Unique Identifier (UUID): A unique identifier (typically a boost uuid) that is used to uniquely identify this object. Marking text cannot be used as a unique identifier, because the marking text can be the same for multiple objects.
• Object Name: A unique string given to an object when it is created. Users can change the name through the GUI or programmatically. For details, please see 3.2.5 The Object Name.
• Echelon ID: A unique string that represents a simulation object's place in the organizational hierarchy. It changes if a simulation object is reorganized into or out of a unit. Echelon IDs are managed by the Organization Manager, DtOrganizationManager.
• Object Identifier: The site:application:object number triplet used in DIS and the HLA/RPR FOM to identify an object in inter-application communication. It is automatically assigned by the DtVrfObjectManager, and persists for the duration of the simulation. Object identifiers are implemented using the DtEntityIdentifier class. In DIS, this identifier is equivalent to the global object designator.
• Global Object Designator: A DtGlobalObjectDesignator (or global ID) can be used regardless of protocol to identify a simulation object in inter-application communication within PDUs, interactions, and attribute updates. In HLA, DtGlobalObjectDesignator is typedef'd to DtString - a VR-Link wrapper around char* that can be used to store object names. In DIS, DtGlobalObjectDesignator is typedef'd to DtEntityIdentifier, since in DIS that same type of ID is used to identify an object both within an application, and between applications.

3.2.3 Looking Up Objects

You can look up objects in the Object Manager by object ID (site:application_number:object_number), echelon ID, marking text, or object unique identifier (UUID). Because VR-Forces uses unique identifiers to represent objects, the marking text does not need to be unique. The name of an object simulated by an application other than VR-Forces is its marking text.

3.2.4 The Object Type

The object type (DtObjectType, in objType.h) is an extension of the VR-Link DtEntityType class. It adds an enumerated field to the DIS/RPR FOM object type enumeration. The new field indicates the general type of object, for example, individual or unit. The remaining fields (kind, domain, country, category, subcategory, specific, and extra) are unchanged. For example, the object type enumeration for an M1A2 tank is 1 1 225 1 1 3 -1. The VR-Forces object type is 1 (1 1 225 1 1 3 -1).

The object type is used to:

• Find the appropriate entry for a newly created object in the object parameter database
• Determine (along with force) the icon that should be displayed for a simulation object
• Create the right kind of HLA object (done by VR-Link)
• Look up information such as target priority or the ammunition to select for a given target.

Note

In the object parameter database, objects can have wildcard values in their object type, for example, 1(1 1 225 -1 -1 -1 -1). However, when you include an object type in code, you must use zeros for unkown or generic values. The equivalent object type in code for this example would be (1 1 1 225 0 0 0 0).

3.2.4.1 Predefined Object Types

The DtObjectType class has static predefined object types. These types can provide a convenient short-hand for specifying various kinds of objects. The predefined static types are:

• Null (0's)
• Any (wildcards)
• Individual objects
• Aggregates
• Pseudo-aggregates
• Individual lifeforms
• Individual platforms
• Cultural features
• Munitions.

The VR-Forces extensions to the standard DIS/RPR FOM object type enumerations are specified in objTypeEnums.h.

3.2.5 The Object Name

All simulated objects have an object name, a string used to identify the object within the exercise. Object names are implemented using the DtString (rwString.h) class. An object's name persists not only for the lifetime of the simulation, but from session to session. (It is saved as part of the object's data in the order of battle file.) All references to control objects or simulation objects in plans are made using object names.

All objects are given a unique identifier using the DtUUID (rwUUID.h) class. These unique identifiers persist not only for the lifetime of the simulation, but from session to session for this object. The unique identifier is used in all locations that reference this particular object. This can allow the object to change its marking text without changing how it is referenced.

You may have the DtVrfObjectManager suggest a unique name to assign to the object, or you may choose one yourself. Call DtVrfObjectManager::nextName() to have VR-Forces generate a name for a DtObjectType and DtForceType. It is up to the user to ensure that the name is unique.

Objects can have arbitrary names; however, the names have restrictions on their length, because they are transmitted over the network in the marking text field. The following table lists the limits on object name length.

Object Name Length Restrictions
Protocol	Individual Entity	Unit	Control Object
DIS	11	32	255
HLA RPR FOM	11	10	255

3.2.6 The Echelon ID

Simulation objects that belong to a hierarchical organization have an echelon ID, a unique string that reflects their position in the hierarchy (for example, 1 M1A2, 2 Plt, 1 Force). Please see 4.5 - The Organization Manager, for more information about echelon IDs.

3.2.7 The Object Label

A label is a text string that can persist beyond a particular run of an exercise (unlike an object ID, which can change between sessions if the site:application_number changes.) It does not have to be unique. It would typically be something that makes sense to a human exercise participant, such as labeling a waypoint "Waypoint Alpha".

[<< The Object Manager and Simulated Objects] [Home] [Top of Page] [State Repositories >>]