Each HLA object must have an object name that is unique throughout the federation execution. When an object is registered, the federate can provide a name or let the RTI supply an object name. In the HLA 1.3 specification, when the federate supplies the name, it is up to the federate to make sure that the name is unique. If it isn’t, the RTI throws an exception. The HLA 1516 specification lets you reserve names to ensure that they are unique.

By default, the VR-Link publishers perform name reservation and object reservation at the same time - when the publisher is created. The name reservation process requires a round trip handshake between the local RTI component (LRC) and the rtiexec. Therefore, performing it just before an object is registered can delay the object registration process. If the federate is simulating a limited number of objects that are created at start up, this overhead is negligible. However, if the federate is creating many 100s of objects or if an object is being created in a time critical fashion (say a missile fly out), the delay caused by name reservation can become significant. One way to avoid the name reservation delay is to perform the name reservations ahead of time before the objects are registered. VR-Link can do this. (continued...)

For a number of years, the MÄK RTI has supported a useful feature called FDD (or FED if we’re talking about HLA 1.3) file distribution. The original idea was that often during federation development you might find the need to update your FDD file. This often meant going around to every machine you were using and updating the local copy of the file. Obviously, this is both tedious and error prone. With FDD file distribution, only the federate that created the federation execution needed to have a local copy. When the federation was created, the file was distributed through the RTI to the rtiexec, which then distributed it to every other joining federate. This guaranteed that everyone was using the most up to date file and there were no discrepancies. There was one obvious downside to this feature however: start-up times were slower.

Last week, MÄK was pretty excited to release of VR-Forces 4.0.3, which included HLA Evolved support! At this point the complete MÄK Product lineup supports the latest version of the HLA Standard. 

This means that users who want to build federations that take advantage of FOM Modules and other HLA Evolved features will now be able to do it with VR-Forces. FOM Modules is a particularly powerful feature. It allows subgroups of Federates in a larger Federation to share FOM extensions without propagating the FOM extensions to everyone; most federates that don’t use the module can completely ignore it knowing that they will get the information they require in the base FOM, while the subgroup will get information from the base FOM as well as the model.

This is the 6th and final part in my series of blog posts on RTI RID configuration tips. Each of these tips, unless otherwise noted, works in HLA 1.3, HLA 1516-2000, or HLA Evolved. If you’re interested in learning how to make better use of your RID file, check out the previous posts in this series as well.

Part 1 – RID Consistency Checking
Part 2 – The Advantages of MTL
Part 3 – Utilize Environment Variables
Part 4 – Modularizing Your RID 
Part 5 – Programmatic Configuration 

Make sure you know what parameters your federate is actually using

Anyone who spends any time configuring RID files is bound to make a mistake from time to time. I know I do, and a large number of the questions we get in support are configuration issues as well. Even if you think you’ve setup your RID file correctly, there are some parameters that can be overridden by the RTI Assistant or programmatically by your federate code. That means examining the RID file doesn’t always tell you exactly how a federate is configured. So how can you tell? Well, there’s a RID parameter for that, of course!

This is part 3 in my series of blog posts on RTI RID configuration tips. Each of these tips, unless otherwise noted, works in HLA 1.3, HLA 1516-2000, or HLA Evolved. Check out the previous posts in this series, and stay tuned for more to come.

Part 1 – RTI RID Configuration Tips: Consistency Checking

Part 2 – RTI RID Configuration Tips: the Advantages of MTL

Lookup environment variables within your RID

If you’ve followed me through parts 1 and 2 in this series, you may have noticed a theme: managing multiple RID files is a pain. Whether it’s ensuring consistency between the various RID files involved in a single federation, or maintaining separate configurations to be used in different federations, whenever you’re managing multiple RID files you’re bound to run into the occasional hiccup. The goal of these posts is to help you reduce these hiccups and help you identify them when they occur.

After we completed the recent update to HLA Evolved in the MÄK RTI, we have started overhauling our sockets to support IPv6 for the 4.1 release. One of the new configuration options we added to help everyone with complex network environments is Node Configurable Compression and Bundling.

Specifically, with the current version of the MÄK RTI, you can enable packet-bundling, and or packet-compression throughout the entire exercise. For example, you can do either of the below: