Note: Do not confuse VR-Forces state repositories with the state repositories provided for VR-Link DtObjectPublishers and DtReflectedObjects. In the context of VR-Forces, the VR-Link state repositories are referred to as network state repositories. (For details, please see The Network Interface.)

There are several derived state repository classes that contain state information specific to a particular category of objects. For example, the fixed-wing state repository class, DtFixedWingStateRepository, maintains information specific to fixed-wing entities, like maximum angle of attack and minimum altitude.

Note: In VR-Forces 4.x, both vrfExternalState and vrfInternalState were combined in the DtVrfObjectStateRepository set of classes. For compatibility reasons, there are still some functions that allow access to some external state using the DtVrfObjectStateRepository classes, however use of these functions is discouraged. See VRF 4 Compatible API for details.

Checkpointing a Simulation Object's State

The state repository is a readable, writeable member of a DtLocalObject and, therefore, is saved and restored as part of an object’s data in the order of battle file.

Whenever you save or checkpoint a scenario, VR-Forces saves the state of all locally simulated simulation objects to the order of battle file. This state includes items such as kinematic state (position, velocity, orientation, and so on), damage status, and resource levels. VR-Forces also saves information about the processes the simulation object was carrying out at the time of the save, such as the name of a waypoint it was heading toward, or the identity of the current target in a weapon system.

The State Repository Hierarchy

As noted in Simulation Object Design, the differences between simulated objects are expressed in the state repository class hierarchy. The differences between a tank, a helicopter, or a route are partly a function of the kind of internal state repository each has. Control objects use a DtVrfObjectStateRepository. Moving simulation objects use DtMovingObjectStateRepository or one of its derived classes. The figure illustrates the hierarchy of derived state repositories for simulating different kinds of objects.

State Repository Hierarchy

DtVrfObjectStateRepository

The DtVrfObjectStateRepository holds information that is common to all simulated simulation objects within VR-Forces. It is an intermediate state repository that has a role similar to an abstract base class for simulation object state repositories. It is not created for any simulation objects in VR-Forces. However, all other state repositories in VR-Forces inherit this class.

DtVrfObjectStateRepository maintains a readable and writeable list of current tasks a simulation object is working on. This data is manipulated by the DtTaskControllerComponents configured on a simulation object (users should not typically have to access it directly). This data is also saved as part of a simulation object's state in the order of battle file. This enables simulation objects to remember what task they were working on at the time the scenario was saved (whether assigned from a plan or from the GUI as an independent task).

DtMovingObjectStateRepository

DtVrfMovingObjectStateRepository is derived from DtVrfObjectStateRepository. It holds information that is common to all VR-Forces objects that can move. It is the base class for all of the individual state repositories. It is also the state repository used for units. It provides storage, accessors, and mutators for the following data:

Ordered speed (the speed the simulation object is supposed to use when moving).
Maximum speed.
Maximum reverse speed.
Turning radius.
Maximum slope.
Inverse stopping deceleration.
Maximum acceleration.
Maximum stopping deceleration.
Fuel efficiency.
Direction of movement (forward() function).

Extending State Repositories at the Base Class Level

Note: This method of extending state is no longer the preferred method. Consider using instead.

You can extend the base state repository class DtVrfObjectStateRepository, as an alternative to, or in addition to extending leaf-level classes in the DtVrfObjectStateRepository hierarchy. The base state repository class, DtVrfObjectStateRepository has-a DtVrfStateRepositoryUserExtension (vrfSRUserExt.h) that you can extend for all types of simulation objects and objects (vrfstaterephierarchyfigure State Repository Hierarchy).

For example, suppose you want to extend all types of simulation objects in VR-Forces (fixed-wing, rotary-wing, ground, and so on) with a new kind of identifier. Rather than extending each type of state repository to include the new identifier, you just need to create a single derived kind of DtVrfStateRepositoryUserExtension class. This allows you to write the extension once, and configure it as part of a variety of different kinds of simulation objects, control objects, or tactical graphics. The alternative to this approach would be to subclass each kind of state repository separately, extending each class in exactly the same way.

Like the DtVrfObjectStateRepository classes, classes derived from DtVrfStateRepositoryUserExtension are readable and writeable. Any DtReaderWriter data members you add to your derived DtVrfStateRepositoryUserExtension will be saved to an order of battle file along with the rest of an object’s DtVrfObjectStateRepository data.

The example project State Repository Extension (extendStateRepository) demonstrates how to extend state repositories at the base class level.

Table of Contents

Checkpointing a Simulation Object's State

The State Repository Hierarchy

DtVrfObjectStateRepository

DtMovingObjectStateRepository

Extending State Repositories at the Base Class Level