The Windows versions of MAK products are built using the Microsoft Visual C++ (MSVC++) compiler. Because application and library compatibility is usually broken between different versions of the compiler, applications that interoperate must be built using compatible compilers. To help customers choose the correct version of an application to install, each MAK application installer includes the compiler version it was built with in the installer filename. Additionally, the About box for each application includes the compiler used to build it.
Every year we receive a number of support questions which have to do with licensing. We hate to receive them, because licensing should be easy! For the most part it is, as many customers never run into any problems at all. However, when a problem does crop up customers frequently feel at a loss.
As many of you know, MÄK has an unorthodox model for technical support. We are proud of how we do support, and believe it’s a key reason why people buy our products (other than the fact that we make awesome products!). In the next few weeks, and continuing over the summer, we will be making a few minor changes to how we handle technical support.
We are working on our demos for I/ITSEC and the Traffic Generation feature in B-HAVE 2.0 for VR-Forces 4.0.1 is proving to be a big help. Jim Kogler has blogged about this feature in his Pattern of Life blog, but to recap, when you add spawn points and sink points to a scenario, VR-Forces automatically creates entities (civilian lifeforms or civilian vehicles) at a set interval at the spawn point. They then move towards a randomly chosen sink point. When they get to the sink point they are deleted. This provides a steady stream of entity traffic that moves purposefully without the need to create plans, assign tasks, create routes, and so on. So I thought I would share some of my experiences with them.
My scenario has 18 spawn points and 18 sink points in a relatively small area. After one minute of simulation, more than 200 entities get created. After four minutes more than 400 are created. So when you plan your scenario, consider how many entities you want (including any entities that have specific plans as the main point of the scenario) and plan the number of spawn points accordingly; otherwise, like the Sorcerer’s Apprentice, you may find yourself dealing with a flood of entities.
Periodically, MÄK reassesses platform support for our product line. We consider a platform a paired version of compiler and OS. For example, Windows 7 and MSVC++ 8 is a single platform, while Windows 7 and MSVC++9 is a different platform. In order to support the most popular and stable platforms while maintaining commitment to quality products, we need to limit the total number of platforms we support as part of the standard product offering.
In general, when deciding to support or not support a platform we consider a number of factors:
1. Does the product have a heavily used API? - some of our products are generally used out-of-the-box with little API usage. In those cases we can support fewer compiler variations.
2. Do customers have to integrate our products and libraries into legacy systems, or larger systems that they are developing? - this requires broader compiler variation support.
3. How easy is it for us to build and test on a given platform?
4. How many customers are actually using the platform at all?
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...)
To reserve names in advance, your VR-Link application needs to make name reservation calls. If the calls are performed through the exercise connection, the results are cached. When an object publisher is created, it first checks to see if the name is already reserved. If so, the name reservation call is skipped. We have a code snippet that shows how to do this, but it is a bit too long for this blog. We have put it on the MÄK Community Forum in the Link-Interoperate section. If you want to see the code and a somewhat more detailed explanation of this issue, click here!