Simulation and training exercises are often developed in distinct phases: planning, execution, and analysis. The goal of the Window Layouts feature in VR-Forces is to make it easy to create the phase-appropriate interfaces and then switch between the layouts as an exercise progresses.
When you are creating a scenario in VR-Forces, you usually have complete access to all of the simulation objects in a simulation model set (SMS) and can create as many as you want. However, in the real world, commanders do not have unlimited resources. They are constrained by their Order of Battle (OOB), which specifies the men and material available in a hierarchical structure. VR-Forces now supports the creation of OOBs. You create an Order of Battle in the context of a scenario. However, once you create an OOB, you can export it and then import it into other scenarios. This lets you quickly create new scenarios that use the same OOB for training or scenario development.
Many of the web sites that most of us read regularly are not composed of static pages. They pull content from a variety of sources to customize the pages for the reader. You might see the same news article show up on the sites for multiple different news outlets. This is called content reuse. The goal is to get maximum use out of each content component. Similarly, VR-Forces supports many strategies for reusing scenario components. Using the same terrains for many different scenarios is an obvious case, but for this tech tip we will focus on ways to reuse scenario content – simulation objects and tactical graphics.
Simulation objects in VR-Forces have many state properties, such as speed, heading, altitude, force, and so on. You can set many of these properties using set data requests. In past releases, if you wanted to add a new type of state property, you had to use the VR-Forces Toolkit to write a plug-in or update the application. VR-Forces 4.6 lets you add new state properties without writing code.
We are happy to introduce California and Emerald City (Seattle), two new terrains that come free with VR-Forces 4.6 and are available via our VR-The World online server.
With VR-Forces, we’re always looking for ways to create scenarios that more accurately represent the experience of battle and give instructors as many real-world features for training as possible. In VR-Forces 4.6, we take a step forward in our capacity to simulate electronic warfare, with improved radar system and jammer functions:
During the time between VR-Forces releases, as we work with development versions that have all the new features, we get used to the usability improvements that we’ve added. When we have to go back and use a prior release, the usual reaction to the old version of whatever function has been updated is, “Darn, the old way of doing things is so annoying (by comparison)!”
One of the new usability features in VR-Forces 4.6 is a revision to filtering the object creation palettes. In VR-Forces 4.5 and prior releases, you could filter the object list by selecting the force and category in drop-down lists. Lists are OK if there aren’t too many options, but if you have to scroll, they can be annoying. And even short lists take longer to use than icon bars. In VR-Forces 4.6 we have replaced the drop-down lists with quickly accessible icons.
A common question from people who are new to VR-Forces:“How easy is it to create new scenarios in VR-Forces?” It’s a good question to ask when you are evaluating CGFs. The answer is always: &ldquoIt depends.”
There are obviously some very complicated scenarios you could dream up that would make scripting them quite complicated and difficult. That said, most scenarios are very easy to script. At the end of this post, you’ll watch a scenario with a helicopter flying over some mountains - I whipped this one up in about three minutes. It runs a bit faster than real time, so you can enjoy it in about one minute or so.
After I create the scenario, I slow it down, play it, and show some of the new 3D/2D integrations that are making VR-Forces 4.0 so popular. As a bonus, I also demonstrate a new feature coming to VR-Forces 4.0.4 in June. We’ve overhauled our machine gun model and added chain guns to helicopters and other vehicle types, which is something customers have been asking about for a long time.
While we don’t have firm dates picked for supporting Windows MSVC10 with all MAK products we are planning to roll out support for this new compiler across our product line throughout the year. Today I wanted to provide some details about our thinking, as well as describe how we want to handle the notorious issue regarding SCL and HID compiler flags
In VR-Forces 4.3, we’ve made a number of enhancements that are not immediately obvious, but are still very useful if you know how to take advantage of them. In this post I’ll share some tips on how to make use of the improved Simulation Model Set (SMS) management that is part of VR-Forces 4.3.
For those who don’t already know, a Simulation Model Set (SMS) in VR-Forces is the set of configuration files that defines the entities and objects available for creation in a scenario. This includes everything from their names and type enumerations to their behavior logic and physical movement dynamics. An SMS is typically modified using the VR-Forces Entity Editor tool.
VR-Forces ships with some preconfigured SMSs with hundreds of objects to use in scenarios, however, it is quite common for customers to add specific models, or to modify the shipped VR-Forces models to suit the needs of various projects. In the past, this was most often done by editing the default SMS in VR-Forces directly, or by copying it wholesale and making edits to the copy. Both of these options lead to significant upgrade work when moving to a new version of VR-Forces where parts of the default SMS were edited, since the changes have to be merged.
VR-Forces 4.0 is getting close to release! As many of you are aware, we’ve been working hard over the past year to give VR-Forces a whole new GUI based on MAK’s VR-Vantage visual product. One of the key new capabilities of this GUI is the ability to work with many different views of the scenario at the same time.
The default behavior of the VR-Forces startup process is designed to get you up and running quickly. However you can customize the process to meet your workflow, as follows:
Pattern-of-Life analysis is becoming increasingly important in today’s military. It revolves around the continuous observation of behavior patterns for a population, town, or street. Most people and populations tend to have very distinct patterns in our lives. We get up, brush our teeth, go to work, go to lunch, go home, kiss the kids, and go to bed. Okay, maybe your life is more interesting than mine, but when you think about it in the big picture people in general are fairly predictable. This gives way to the“See something, say something” signs we see in airports. On a subconscious level everyone recognizes patterns in our lives: we wear winter coats when it’s snowing and shorts when it’s hot. When someone is wearing a winter coat and it’s hot outside, you notice it.
One of the new features in VR-Forces 4.0.1 is support for launching counter measures (chaff and flare) from fixed-wing and rotary-wing entities.
Counter measures are enabled by default, so you don’t have to do anything to take advantage of them. If you run the embark demo scenario that comes with VR-Forces, you will see them being launched by the opposing force helicopters that are attacking the airport.
Okay, so B-HAVE 2.0 is done and most people might think the coolest bit about this release is that path data will generate 60 times faster. Yes, my spelling is often poor, but my numbers are perfect: I said 60 times faster"¦ Yikes SIXTY? Yep.
But let’s not talk about that, the really cool bit is the funky colors:
The title today is a bit of a positive spin on a few problems we have had with VR-Forces. Perhaps, we should say“VR-Forces 4.0.1: were sorry, but we will be better.” It’s important to always be honest, even when you make a mistake. With the introduction to VR-Forces 4.0 we were so excited about new visualization, we left out some important features. You let us know we messed up, and we understand. With VR-Forces 4.0.1 we have started to add the features back in, and have put most of the other features on a priority list where they will show up in VR-Forces maintenance releases later this year.
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.
While FOM Modules and other compelling features are encouraging several major sectors of the HLA market to move to HLA Evolved, many existing federations remain firmly tied to HLA 1.3 or DIS. VR-Forces remains firmly committed to supporting each of these interoperability choices. You can rest assured, whichever simulation interoperability choices you make, MÄK stands behind you.
I am pleased to announce the extension of the VR-Forces 3.12.x maintenance period to December 31st, 2012. While we have seen many customers quickly migrating to the VR-Forces 4.x platform, MÄK understands there are still many other customers who face complex schedules and tight budgets who have not been able to upgrade their VR-Forces 3.x based products yet. As a customer focused company, it’s MÄK’s goal to be as responsive as possible to customer needs. We believe this extension will provide the time needed for many customers to upgrade while still supporting existing systems.
As always, the content of our releases and maintenance windows are highly influenced by your needs and requirements. Please don’t hesitate to let us know any concerns or questions you may have about VR-Forces maintenance issues, or any other issue for that matter. We will use your input to reevaluate the current maintenance window in October 2012 to determine if further extensions are necessary. We look forward to hearing from you!
Today I want to give a sneak peak of a coming VR-Forces feature. When we release VR-Forces 4.0.4 early this summer, users will be able to control aircraft in a new and intuitive way.
Lots of people use VR-Forces to set up complex scenarios with aircraft. Historically this has been done with routes and waypoints. It means you must plan out your routes or set several waypoints, then build plans for your aircraft to move over the routes or between the waypoints. It’s a logical way to script air scenarios, but for pucksters who move a lot of aircraft around in real time, it’s quite complicated.
In our effort to continually make the user experience better, I wanted to show a small feature we are adding to VR-Forces 4.0.4 -- due out in June 2012 -- which allows users to choose what plug-ins to load when they start VR-Forces. This is a pretty simple feature that’s best described with a picture:
It is somewhat axiomatic in the documentation biz that“no one reads the doc&rdquo, unless you make a mistake - then everyone reads that section. In the Entity Editor documentation for VR-Forces 3.12, we described a feature that wasn’t actually in the product: the ability to edit 3D models in the editor. Since then, every now and then someone asks how to find that feature and we’ve had to admit the error. No more! In VR-Forces 4.0.4, you can edit an entity’s 3D model, XR model, and 2D icon in the Entity Editor.
The Entity Editor lets you quickly and easily change the 3D model used to represent an entity. When you change a model in the Entity Editor, the entity’s model definition also gets changed. (In other words, it is fully integrated with the settings in the Visual Model Editor.)
The window that shows an entity’s model is live, so you can manipulate the view of the model using the same keys that you would use to move the observer in the VR-Forces Stealth or XR observer modes.
Radar Modes - Being able to configure named modes for radar systems is an important part of electronic warfare (EW). VR-Forces now allows users to configure multiple named modes for radar systems. A named mode could be “off” or &ldquolow power&rdquo or &ldquosearch”. This is all done through configuration files. The F18 has two modes "Track" and "Search". Users can create new specific modes and then set them through plans. (continued...)
Entity Editor Model Configuration - The Entity Editor has been significantly overhauled to allow users to configure 2D icons and 3D models directly from the Entity Editor GUI. You can also show the bounding volume of the entity in relation to the 3D model. If you select a sensor, you can show where the sensor is placed on the vehicle with relation to the model.
You’ve been hearing a lot lately about the Pattern of Life support in B-HAVE 2.0.4 for VR-Forces 4.0.4. We’ve told you that you can automatically create realistic background traffic in your scenarios without laborious planning and route development. But what does it really mean? In this blog and its successor, I’ll drill down a bit into how POL works.
First of all, it isn’t really the Pattern of Life, it’s the Patterns of Life. When you use the POL feature, entities get created automatically at locations of your choice called spawn points (and we say that newly created entities are being spawned). The frequency and timing of their creation is controlled by templates. We provide templates for civilians and civilian vehicles. However, you can create as many templates as you want for creating any supported entity. You can also create multiple templates for any particular entity type that vary in the pattern of creation that they use. So, you really have multiple patterns at your fingertips. (continued...)
VR-Forces 4.1 introduces significant changes to the Move to Waypoint and Move to Location tasks.
Ever since VR-Forces 3.8 (back in 2005), Move to Waypoint and Move to Location tasks have offered the options to move directly to the destination or to plan a path. When path planning was enabled, if the entity identified a vector road network between the start point and destination, it tried to use the road network for the appropriate segment of the movement task. In VR-Forces 4.0, we introduced Road Following, an improved algorithm for moving along roads. Unfortunately, vehicles often had problems making the transition from off-road movement to moving on roads, which resulted in poor vehicle behavior.
To solve this problem, in VR-Forces 4.1, we have separated the direct movement and road following tasks. The result is better overall vehicle movement at the cost of slightly less realistic transitions from off-road movement to road following. We now have three flavors of the Move to Waypoint and Move to Location tasks:
Once the VR-Forces 4.1 release was completed and uploaded to the FTP site, we decided to have the VR-Forces team relax a little and express their creativity to see what could be accomplished with the new Scripted Task feature of VR-Forces.
If you haven’t already heard about it, Scripted Tasking is a brand new feature in VR-Forces 4.1 that brings scripting to the forefront and allows any VR-Forces user with even just a little programming or hacking skills build their own tasks and behaviors. We’ve incorporated the well known Lua scripting language into the base VR-Forces, and allowed access to much of the VR-Forces API. New tasks that you write can now be saved directly into a scenario, and easily exchanged among users.
Using this feature, it is possible to create all sorts of new tasks and behaviors in VR-Forces by combining any of the existing tasks, passing messages between entities, and inspecting the state of various elements in the simulation. To see just how flexible the scripting interface is, we had one simple rule: Make any behaviors you want!
MÄK is always trying to make VR-Forces easier to use. This means that we are constantly looking for better ways to create and manipulate entity types " specifically, complicated entity types. When we released VR-Forces 4.2, we added many new types of weapon systems and ships to the default VR-Forces model set. As we set out to use these new systems, we realized that most entities hosted not only many diverse weapon systems, but also other entities that could be viewed as an extension of the host ship.
Let’s look at Anti-Submarine Warfare (ASW). Ships don’t just fire torpedoes " they launch a helicopter to fly toward the target, which then drops the torpedo. The helicopter always eventually returns to the ship. We want to enable VR-Forces users to easily create this type of scenario by simply clicking on a ship, telling it to "Deploy torpedo here", and then have the ship automatically 1) deploy the helicopter, 2) have the helicopter fly to the appropriate place, 3) drop the torpedo, and 4) return to the ship. There are many types of scenarios where an entity hosts a separate entity that indirectly performs routine tasks. This is where our newest "Embedded Entities" come into play. Keep reading...
Just because something is faster doesn’t necessarily make it better. We’re here to prove that faster really is better when it comes to creating complex behaviors for a CGF. Scriptable tasks in VR-Forces give you the power to quickly develop complex tasks, easily coordinate group behaviors, and script GUI components in minutes, empowering you to develop better and more compelling simulations.
Rapid development cycles let you take advantage of the often limited time your have with subject matter experts (SMEs). Together you can transcribe the problem into behavior, test it interactively, fine tune it, and make it right. The more reliable information about the problem that you can encode into the behaviors, the more valid your simulation will be " more iterations means a higher quality result.
Let’s say you’ve been tasked to develop a search and rescue mission " you have limited time and know little about the actual search and rescue patterns or protocol. You decide to consult the WSDOT Aircrew Training Text as your expert. After some research, you learn about the different visual search patterns and you throw together a quick script that incorporates a specific pattern, and then you test it out. 20 iterations later, paired with a little feedback from SMEs, and you probably have a pretty good script consisting of several search patterns embedded in one another.
The release of VR-Forces 4.3 is finally here! Version 4.3 is a major feature release that adds many exciting features to MÄK’s leading CGF. Some of these new features include:
VR-Forces 4.3.1 is a major maintenance release that greatly improves VR-Forces 3D visualization while simultaneously fixes a number of important defects.
VR-Forces is built using the VR-Vantage graphics engine. This release incorporates the significant improves to visualization found in VR-Vantage 2.0.1, such as: