I talk to a lot of customers and I keep hearing the same thing when it comes to the VR-Vantage Developer's Toolkit... needs more documentation! Sure, people are always asking for stuff (and please continue to do so!) but even if we have an awesome API, it's no good if people can't figure out how to use it.

Along with providing new capabilities like Simulated Video and Effects Based Sensors, we plan to do a lot of work on our class documentation and examples during the 1.5 development effort. We also will be adding a bunch of tutorials that will walk developers through a series of examples that demonstrate the various layers of the VR-Vantage architecture or go in depth into a specific area.

You have to hand it to Singapore. They sure do know how to put on an Air Show. There’s nothing like holding a pleasant conversation with customers or colleagues only to be interrupted by the roar of an F15 jet passing right in front of the door then ascending like a rocket straight into the clouds. Very impressive. 

MÄK is presenting in two locations at the Singapore Airshow. Our COTS products are on display at the TME Systems booth and our Battle Lab (a.k.a. ISR Lab) is in the Ideas section of the ST Engineering booth. 

It is great to see so many existing and potential customers at the Singapore Air Show this week.  Tomorrow (Friday) will be the last commercial day with this weekend open to the public.  MÄK is currently exhibiting in two locations this week.

All of our products and tools are currently being demonstrated in TME’s booth B-11 – MÄK’s reseller for Singapore, Thailand and Indonesia.  Customers are receiving live demonstrations of the latest release of VR-TheWorld Server v2.0 streaming terrain, imagery, and now cultural features.  We are also showing VR-Vantage v1.4, as well as the rest of the MÄK suite of products such as VR-Forces and VR-Link.

Some of you may have noticed that MÄK has recently started supporting the SUSE Linux Operating System in some of our latest releases.  MÄK has a long history of supporting a wide variety of common Operating Systems. SUSE is a very popular OS in Europe and has been used by our customers for some time through custom ports. With the latest release of VR-Link and the MÄK RTI we are proud to announce we now officially support the platform with our standard interoperability products. That means future versions of both the MÄK RTI and VR-Link will continue to support SUSE.

For a complete list of standard supported platforms, please see the MÄK website. If you have a platform you would like to see supported, please let us know at sales@mak.com.

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.

Earlier this week MÄK released the latest version of the RTI, 4.1. One of the big features of this release was support for IPv6. For those that don't know much about IPv6, it is the latest version of the Internet Protocol and replaces IPv4. The primary motivating factor behind the creation of IPv6 was the size of the IP address space in IPv4. IPv4 addresses are only 32 bits long. That's enough for 4,294,967,296 different addresses, but it's not enough for the size of the internet today.

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!

Having released VR-Vantage 1.4 it's time to move on to the next version. We showed several technology demonstations at IITSEC this year and we are in the process of productizing them for VR-Vanatage 1.5. 

Effects based sensors let users visualize NVG, FLIR and other sensor views without materially classifying data. While these sensor visualizations are not physically accurate, they are pretty good and since they don't require any changes to models or databases they are super easy to use. They still utilize JRM's world class technology for sensor visualization, just without the high fidelity physics based stuff (which can be enabled via a drop-in add-on module).

This is part 5 in my series of blog posts on RTI RID configuration tips. Check out the previous posts in this series, and stay tuned for more to come.

Part 1 – RID Consistency Checking 

Part 2 – The Advantages of MTL

Part 3 – Utilize Environment Variables 

Part 4 – Modularizing Your RID 

Change RID parameters programmatically in HLA 1516-2000 and HLA Evolved

The RID file isn’t the only way to specify RTI configuration parameters. Many people don’t know that RID parameters can also be specified programmatically by the federate. Unfortunately there was no mechanism for this in the HLA 1.3 API, but in 1516-2000 such a mechanism was added, and the same idea was kept in HLA Evolved (though the API for it changed). In HLA 1516-2000 and HLA Evolved, the standard included a way to pass a string or series of strings to the RTI to be used in RTI initialization. Since RTI configuration is different for every RTI, the standard left it to RTI developers to determine how these strings were used. As a result, this is one of the few areas of the API that will work differently from RTI to RTI. So if your federate needs to operate with multiple RTIs, you may want to consider other configuration options or have a switch in your code based on what RTI you are using. So how can you use these strings with the MÄK RTI?

As the news of Warren's upcoming departure from MÄK has spread after today's announcement, I've heard from a few long-time partners and customers asking for my take on what this means for MÄK. So I wanted to share a few quick thoughts. But first, this is good time to express how lucky I feel that I've had the opportunity to work for Warren for more than 18 years.

I first met Warren when I was 20 years old, when he conducted an on-campus interview at MIT. As I walked past all of the other companies' representatives wearing suits and ties, there was Warren wearing sneakers, jeans, and a T-shirt (although he did have a blazer on over the T-shirt). I said to myself "That's the guy I want to work for!" And I have enjoyed doing so ever since. Over the years, I've found Warren to be a visionary leader, an eternal optimist, a businessman of unimpeachable character, an outstanding role model, and a good friend. I wish you the best of luck, Warren, in your post-MÄK life, and I thank you for creating and cultivating a company that remains engaging, successful, and fun even after almost two decades. (continued...)