No cookie for

Migration Support

VR-Forces Migration Support Policy

This migration information provides a high-level review of changes to the major classes in the GUI API. However, it is not a comprehensive guide to changes. MAK has decided not to release a comprehensive porting guide because we believe the upgrade experience is likely to be highly specific to individual customer use cases. As such, a comprehensive porting guide would be unlikely to fully explain the process no matter how much we wrote. Instead, MAK has pledged to work with customers on a one-on-one basis during their upgrade process. That will include help through technical support, customer specific webinars and possibly on-site support and training. Please contact us a This email address is being protected from spambots. You need JavaScript enabled to view it. or through your MAK salesperson or reseller for help with porting to VR-Forces 4.0.

Migrating from VR-Forces 3.x to 4.x (API Changes)

Before migrating from VR-Forces 3.12 to 4.x, you should understand the major areas that have changed:

  • The front-end was completely redesigned. In VR-Forces 3.12, the 2D and 3D interfaces were separate executables. VR-Forces 4.x has a completely integrated 2D/3D graphical user interface (GUI) based on the VR-Vantage toolkit. As a consequence, the GUI API has changed dramatically.
  • The Simulation API and Remote Control API have incremental improvements to support new features, but are largely similar to previous releases.
  • The Terrain API has been updated to support the terrain agility features used in VR-Vantage and to support synchronization of the front-end and back-end views of the terrain.

 

VR-Forces Migration Support Policy

This migration guide provides a high-level review of changes to the major classes in the GUI API. However, it is not a comprehensive guide to changes. MAK has decided not to release a comprehensive porting guide because we believe the upgrade experience is likely to be highly specific to individual customer use cases. As such, a comprehensive porting guide would be unlikely to fully explain the process no matter how much we wrote. Instead, MAK has pledged to work with customers on a one-on-one basis during their upgrade process. That will include help through technical support, customer specific webinars and possibly on-site support and training. Please contact us a This email address is being protected from spambots. You need JavaScript enabled to view it. or through your MAK salesperson or reseller for help with porting to VR-Forces 4.0.

Migrating to particular versions:

 

Migrating Simulation Model Sets

VR-Forces has a tool for upgrading simulation model sets (SMSs). However, this tool is primarily designed for upgrading from the SMS format used in VR-Forces 4.1 and earlier to the format adopted in VR-Forces 4.2. For customers upgrading from more recent releases, the tool attempts to do the right thing, but many aspects of upgrading must be done manually.

MAK is working to improve the upgrade process starting with the next release of VR-Forces (4.6). In the meantime, there are steps you can take to make upgrading easier. The most important is this:

******Do not edit the SMSs provided with VR-Forces (base.sms, EntityLevel.sms, and AggregateLevel.sms).******

If you want to add new simulation models or change existing ones, create a new SMS and include the SMS you want to edit. For example, if you want to change the characteristics of the M1A2 Abrams tank:

1. Create a new SMS that includes EntityLevel.sms.
2. Promote the M1A2 Abrams entity to the new SMS.
3. Change the characteristics of the M1A2 as desired.

Why take this approach? Why not just edit EntityLevel.sms?

Suppose that you edited 25 entities, not just 1. And suppose that you added some additional entities. When you upgrade to a new release of VR-Forces, you would have a new version of EntityLevel.sms. If you wanted to keep your changes, you would either have to edit those same entities again and add your new entities again, or you would have to keep track of the changes you made and copy them from the old SMS to the new one. The more complex your changes, such as changes to system definitions, lua scripts, and so on, the more you would have to remember what to move or re-edit.

If you create a new SMS that includes EntityLevel.sms, when you upgrade to the new release of VR-Forces, you would copy your SMS into the new VR-Forces directory structure. It would automatically include the new SMS and all its changes. Your SMS would automatically override the .entity files for the entities that you had edited. Your SMS would also have any changes you made to system definitions, scripts, and so on. The process would be much more organized and easy to manage.

You might still have to do some editing of your customized entities if VR-Forces introduced new platform level variables, but the amount of work would be easier to characterize than if you had edited EntityLevel.sms or simply copied it to a new SMS.

VR-Forces gives you the flexibility to edit SMSs however you choose. However, we strongly recommend that you take this approach to customizing SMSs.

For complete details about how to create, edit, and upgrade simulation model sets, please see VR-Forces Users Guide.