/
VR-Forces: Receiving Custom VR-Forces Network Data

VR-Forces: Receiving Custom VR-Forces Network Data

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

Whenever possible, VR-Forces prefers to use open standards such as DIS, the RPR FOM, and the NETN FOM to exchange data as it allows for better interoperability with a wide range of other applications. However, this is not always possible. Over the years, to achieve product needs, we have frequently had to add our own custom messages and records to accommodate new features.

Sometimes our customers find it desirable to be able to read or send these custom data formats in their own applications. We have supported this in a couple of different ways but, before we delve into how this can be achieved, it’s important to understand the ways in which we have extended the standard object models. We have primarily taken two approaches: custom records or new classes/PDUs.

Extending the Object Model

  • Approach 1: Custom Records:
    This was the approach long favored by the product. This approach bundles custom data within standard PDUs and FOM attributes/parameters. It takes advantage of opaque data, such as variable datum records, to make our own variants outside of the standards.

    The benefit of this approach is that it leverages existing PDUs/classes. This means this data can generically be supported by applications like loggers and gateways, often with no additional development work. It also allows us to change the format of our data whenever it is useful without worrying about breaking compatibility with outside applications.

    The downside is that now standard fields and attributes contain non-standard data. This means any application receiving this data must either be adapted to understand it, or at least be smart enough to ignore it. This is always the downside to opaque data within open standards. It opens up the possibility for non-interoperability.

    Some of the current VRF capabilities that use this approach include:

    - Tactical graphics: These are implemented using custom records in the EnvironmentRecData attribute of the EnvironmentProcess object class.

    - Radio messages: Any radio messages sent between entities (such as text messages, spot reports, and tasks) are embedded within ApplicationSpecificRadioSignal interactions. The SignalData parameter is populated with custom message data.

    - Control messages: All messages sent between the VRF GUI and sim engine are embedded within the VariableDatumSet parameter of the Data interaction. This includes commands, interface content, tasks, and set requests. This means everything from loading a scenario, to creating an entity, to giving it a task or a plan, are all embedded within Data interactions.

  • Approach 2: New Classes/PDUs:
    We sometimes prefer to extend the standard object model directly by creating new FOM classes and PDUs. Nowadays, this is our preferred approach for any data that we think outside applications might have an interest in subscribing to or publishing. We try to keep these data formats more stable from release to release (though they can change occasionally). They are always defined within MAK FOM modules and documented in the MAK Object Model section of the MAK One Interoperability Guide.

    The benefit of this approach is that it is more open. It is easier for outside applications to look at our FOM extensions or PDU documentation and develop their own applications to receive or send this data.

    The downside is that it is more fixed. It is harder for us to change or add to the format whenever it is useful to us.

    Some of the current VRF capabilities that use this approach include aerodromes and runways, the AggregateLevel model extensions, dynamic terrain, sensor field of view, and weather extensions.

The choice of which approach to use is based on a few factors. Have we historically used custom records? Do we think the format is likely to change frequently? Do we anticipate that any of our users will be interested in using the data in their own applications?

Accessing Extended Data Remotely

With that in mind, how can a remote application send or receive this data?

  1. The easiest way is to use the Remote Control API (RC API), aka the remote control toolkit. The RC API is a set of C++ classes that extend the VR-Link API to allow any application to process all VR-Forces messages the way the VRF GUI does (the GUI uses the RC API itself). You can send messages to control the sim engine as well as listen to all sim engine updates, including custom data. The VR-Forces toolkit includes a remoteControl example application, which is the best starting point for developing your own remote control application. If you are not looking to fully control a sim engine, and perhaps simply want to process data on our tactical graphics, you may be able to just use the MAK VRF VR-Link Extensions, a subset of the RC API that adds a small layer of classes atop VR-Link. The envProcessListen example is a great place to start if you want to, for instance, know where a waypoint or route is located.

    The RC API supports both Approach 1 and Approach 2, and it is the only way to send and receive data that uses Approach 1. There are two reasons for this:

    a. The data formats in Approach 1 are fluid. They frequently change from release to release, and rather than support a constantly shifting format, we would rather support a far more stable API. This way, your application is protected from the underlying data changes, and your upgrade process is made easier.

    b. We often don’t even know what the data formats are. Many of our messages are assembled dynamically in code by serialization functions. As we define new tasks, new sets, and new command messages, the internal infrastructure of VR-Forces obscures the data format and automatically handles all the byte layouts for us. This is all part of the RC API.

    Many developers have asked us how they can understand our custom VRF control messages in outside applications that do not use C++ or the RC API. Unfortunately, for the reasons above, this is not something we can support.

  2. For any of our object model extensions that use Approach 2, you are also free to develop your own DIS applications or HLA federates that support these extensions. These PDUs and classes are well-defined and completely open for your use. Please consult the MAK One Interoperability Guide for more information and consult MAK support if you have any questions.