VR-Forces: Publishing Additional Data to HLA or DIS

This article was written for VR-Forces 5.1.1. It may not be valid for other versions.

Occasionally, developers who use VR-Forces wish to have it publish additional data to HLA or DIS. In VR-Forces 4.x versions, this could be done directly from any code that had access to the DtExerciseConn, which was much of the code base.

In 5.0, VR-Forces added greater separation between the network and the simulation. This was to support a more multi-threaded application for better performance. (Please see the Threading Model section of the VR-Forces Developer’s Guide for more details.) One effect of this change is that it's now more complicated to publish additional data. We have a few examples that can help, but there are also a few different cases to consider here. Let’s take them one at a time.

Adding Interactions

When an interaction (Fire, Detonation, Signal, etc.) is received on the network, it is converted to a DtEvent and placed on a queue in the DtEventManager in order to pass the event from the network to the simulation threads. Similarly, when a sim thread wants to send an interaction, it must generate a DtEvent and pass it through the DtEventManager to the network thread to send it out.

If you want to send or receive a new interaction, you must define a new DtEvent as well as a translator to translate between your new event and a VR-Link interaction. There is an example that shows how to do this: the addEvent example. If you need to create a brand-new interaction class, please see the VR-Link Developer’s Guide for more details.

Extending Existing Objects

Sometimes additional data needs to be added to an existing sim object. For instance, perhaps you have a new HLA FOM class that subclasses the RPR GroundVehicle class to add new attributes. You have two options in this case.

1. You can extend this class by using state properties. (See the User-Created State Properties section of the VR-Forces Developer’s Guide for details.)
   State properties are additional entity attributes that can be published with the entity. There are multiple ways they can be published, but if their name matches an attribute in your FOM then they will utilize that attribute. This is usually the simplest way to extend an entity.
   The addStateProperty example shows how state properties can be added and used from a plug-in.

2. You can extend this class by adding a new state component and extending the network interface.
   State components are used to store and pass object data between the simulation and network threads. By adding a new state component to an entity type, you can add additional data.

   Network interfaces are responsible for moving data between state components and VR-Link state repositories for updating to/from the network. By overriding the default network interface, you can have it update the VR-Link state repository with additional data. Note that this requires writing VR-Link extensions as well.
   The addStateComponent example shows how to add a new state component and, for HLA, how to override the network interface and extend the VR-Link entity state repository with a new attribute.

Adding New Embedded Objects

I am using the term “embedded object” to refer to any type of object that is published by a sim object (entity, control object, or aggregate), but is not directly part of the sim object’s published state. The best examples of this are the RPR FOM EmbeddedSystem object class and its subclasses, such as EmitterSystem. When VR-Forces creates an entity with a radar system, in addition to the entity itself, it publishes an EmitterSystem to represent the radar emissions.

To create a new embedded object, you would need to create a new state component as well as new network interface classes to publish or reflect this object on the network side. For new HLA object classes or DIS PDUs, that would mean writing VR-Link extensions as well.

There is no example in VR-Forces that shows how to do this. It is more complicated than the cases above. However, some of the process is similar to the Extending Existing Objects case, since it requires adding a new state component and new network interfaces (although in this case, it is a new network interface, not an extended network interface).

Adding New Sim Objects

A sim object is any of the objects that VR-Forces simulates and that you can interact with in the GUI. There are three main categories of sim objects, which correspond to how they are sent on the network: entities, aggregates (i.e., units), and environment processes (most notably tactical graphics and control objects). If you want to make a sim object that is not in one of these categories, that is a considerably harder task.

The simplest way to do this, if possible, is to follow the addFomClass example. You can use this example only in the case where your new object type has concepts similar to those already supported by VR-Forces and VR-Link. When this is the case, sometimes you can simply map the attributes in the new class into existing attributes in the VR-Link state repository. This allows you to avoid updating a lot of the other VR-Forces and VR-Link code that relies on the existing state repository.

If such a mapping cannot be performed, then there is a lot more work involved. We have no examples to show this, and it is beyond the scope of standard support. If you would like our engineers to help with this, please contact sales for additional consulting or engineering time.