No cookie for

RTI 4.0.4, VR-Link 4.0.3, and the HLA Evolved API

By Aaron DuBois - The MAK RTI version 4.0 was released on the same day that IEEE officially released the IEEE 1516-2010 standard, otherwise known as HLA Evolved. We were very excited to be able to fully support the new version of HLA from the very first day the standard was out. The down side, however, is that we did all of our development for RTI 4.0 before the standard was finalized, and even at the very end there were minor tweaks happening. Unfortunately we failed to capture the very last change made to the C++ API. As a result, versions 4.0-4.0.3 of the MAK RTI were built against a nearly-final version of the C++ headers, which means that those versions are not quite compatible with the final version of the specification. The new release of RTI 4.0.4 fixes this, and is now built against the final version of the header files.

The final change that was not included in the previous RTI versions was related to a defect in one of the final draft versions of the specification. We actually wrote about this defect in a previous blog post. The problem was with the createFederationExecution RTIambassador methods. There were three variations of this method, each with different input parameters. Some of these parameters contained default values, and as a result there was an ambiguity between two of the variations. We mistakenly thought that there hadn’t been time to get a fix for this ambiguity into the spec, but apparently it did make it in after all. The third variation was renamed to createFederationExecutionWithMIM.

So what does this mean? If you are an RTI customer, but are currently using HLA 1.3 or 1516-2000, this doesn’t affect you at all. The new version of the RTI contains a few bug fixes, so you may want to upgrade anyway, but the HLA Evolved API change won’t be a problem unless you decide to move to the new standard. If you are using HLA Evolved, however, we strongly recommend that you upgrade to the new release and recompile your federate against the new header files. If you were using the third variation of createFederationExecution you will also need to edit your code to use the renamed method. Otherwise, no code changes are necessary. Once you recompile your federate, it will then be truly compatible with the final version of the HLA Evolved specification.

In addition, since the latest releases of VR-Link, the Logger, and VR-Exchange have all been built on top of the MAK RTI, the HLA Evolved versions of those products are also not compliant with the specification. To rectify this in VR-Link, we have also just released VR-Link 4.0.3, which was built on top of the new RTI version. As with our RTI customers, we strongly recommend that you move up to this new release if you are using HLA Evolved. In the next month or so we are planning to release new versions of the Logger and VR-Exchange which will also include this change.

Since the HLA standards are designed to be dynamic link compatible, any version of MAK products will generally work with any version of the MAK RTI that supports the same platform (meaning the same operating system and compiler version). But because this change involved a change to the API, there will now be some incompatibilities when using the last few versions of our products with HLA Evolved. In particular, please keep the following in mind when using HLA Evolved and choosing MAK product versions:

  • VR-Link 4.0, 4.0.1, and 4.0.2 are only compatible with MAK RTI 4.0, 4.0.1, 4.0.2, and 4.0.3.
  • VR-Link 4.0.3 and later releases are only compatible with MAK RTI 4.0.4 and later releases.
  • VR-Exchange 2.0 and MAK Data Logger 5.0 are only compatible with MAK RTI 4.0, 4.0.1, 4.0.2, and 4.0.3.

As always, please contact your sales representative for download links to the new versions of the RTI and VR-Link. And don’t hesitate to drop us an email at This email address is being protected from spambots. You need JavaScript enabled to view it. if you have any questions.

Pattern-of-Life Simulation with B-Have 2.0
Meeting with GMU’s Center of Excellence in C...

By accepting you will be accessing a service provided by a third-party external to