Upgrading Simulation Model Sets to VR-Forces 5.2

Purpose

This article is for customers who have custom simulation model sets and want to upgrade them to the VR-Forces 5.2 format.

The VR-Forces User Guide describes how to upgrade simulation model sets in section 68.5.5 “Running the SMS Upgrade Tool”.

This article includes some additional things to consider when upgrading.

Guidance

Rebuild your plugins for Simulation Object Editor first.

Sometimes customers write custom components for VR-Forces Simulator. That process involves registering those components with VRF Sim. The Simulation Object Editor (SOE) should also know about these custom component descriptors. When the SOE reads the files in the simulation model set (SMS), it needs to know how to instantiate the descriptors that read the parameters for custom components.

Without the plugins to read the custom parameters, the process can result in an upgraded sms that is missing information. Worst case, missing descriptors can cause the SOE to crash.

Enumerate ammunition types in ammunitionParams.mtl.

SMSs have a file called “ammunitionParams.mtl”. For any custom weapon system that uses a named ammunition, if that ammunition is also a custom type, please add it to ammunitionParams.mtl. Chances are, you have already done this if the custom weapon system is actually firing. But it is good to thoroughly check before running the upgrade process.

Make a custom extension for SISO enumerations.

We changed the way resources like ammunition and fuel are managed in VRF 5.2.

The first big change is that they all must have a SISO enumeration for the resource.

The second is that our GUI and SOE display a label for these resources based on a lookup into the SISO enumerations file. In other words, we no longer use the ammo name from the system definition or ammunitionParameters.mtl in the GUI or SOE display for that resource.

We look for extensions to the SISO enumerations here: “appData/settings/enumerations”.

Extension files may already be present such as VRF-Enums.xml or VRE-Enums.xml.

If you are adding ammunition or other resource types to your model set, and those enumerations don’t already appear in “appData/settings/enumerations/SISO-REF-010.xml”, then you can extend them with your own file.

Let’s say our file is called “CustomEnums.xml”.

The head of the file should contain:

<?xml version="1.0" encoding="utf-8"?>
<?xml-stylesheet type="text/xsl" href="SISO-REF-010-spreadsheetml.xsl" title="SpreadsheetML" alternate="yes"?>
<?xml-stylesheet type="text/xsl" href="SISO-REF-010-c99h.xsl" title="C99 Header" alternate="yes"?>
<ebv>
  <copyright>Copyright (c) 2025 [YOUR-COMPANY-HERE]
             All rights reserved.
  </copyright>
  <pocName>[YOUR-POC-HERE]</pocName>
  <pocOrg>[YOUR-ORG-HERE]</pocOrg>
  <pocTelephone>[YOUR-NUMBA-HERE]</pocTelephone>
  <pocEmail>[YOUR-EMAIL-HERE]</pocEmail>
  <revisions uid="1" name="Revision History">
    <revision title="Custom Enumerations" date="[TODAY]">
      <cr value="1" />
    </revision>
  </revisions>
  <loadPriority>4</loadPriority>

The body of your enumerations should start with this tag:

<cet uid="30" name="Entity Types">

The format for a particular enumeration scheme is as follows:

    <entity kind="<SISO-KIND-ENUM-GOES-HERE>" 
      domain="<SISO-DOMAIN-ENUM-GOES-HERE>" 
      country="<SISO-COUNTRY-ENUM-GOES-HERE>" 
      uuid="f3ee84b0-5269-11df-a5df-080069138b88"
      uid="<CUSTOM-UID-INTEGER-GOES-HERE>">    
      <category value="<SISO-CATEGORY-ENUM-GOES-HERE>" description="Ballistic" uuid="f3ef91ca-5269-11df-abd6-080069138b88" uid="<CUSTOM-UID-INTEGER-GOES-HERE>">
        <subcategory value="<SISO-SUBCATEGORY-ENUM-GOES-HERE>" description="5.56 mm" uuid="f3f09c64-5269-11df-9279-080069138b88" uid="<CUSTOM-UID-INTEGER-GOES-HERE>">
          <specific value="<SISO-SPECIFIC-ENUM-GOES-HERE>" description="5.56x45 NATO" uuid="f3f1ac44-5269-11df-b3ac-080069138b88" uid="<CUSTOM-UID-INTEGER-GOES-HERE>" />
        </subcategory>
      </category>
   </entity>

Here is an excerpt from SISO-REF-010.xml:

<entity kind="2" domain="8" country="225" uuid="f3ee84b0-5269-11df-a5df-080069138b88" uid="19809">
  <category value="2" description="Ballistic" uuid="f3ef91ca-5269-11df-abd6-080069138b88" uid="19810">
    <subcategory value="1" description="5.56 mm" uuid="f3f09c64-5269-11df-9279-080069138b88" uid="19811">
      <specific value="1" description="M193" uuid="f3f1ac44-5269-11df-b3ac-080069138b88" uid="19812" />

That means for any weapon system that shoots “2 8 225 2 1 1 0”, the display value will be “M193”.

The system uses a best match method. So if you see in the GUI or SOE a bunch of ammunition names called “Ballistic”, then they don’t understand the enumeration type beyond the “category” level. Meaning, they could not find a “subcategory” or “specific” entry for that ammunition enumeration.

Lastly, close out the XML file:

  </cet>
</ebv>

One more point, you may have noticed this value in the head of the example, above:

<loadPriority>4</loadPriority>

That indicates the order in which the enumeration tables should be loaded and searched.

For our particular installation, the “appData/settings/enumerations” directory has these files:

SISO-REF-010.xml

VRF-Enums.xml

VRE-Enums.xml

We are adding:

CustomEnums.xml

That means with

<loadPriority>4</loadPriority>

We are saying “load and merge CustomEnums.xml after VRE-Enums.xml”.

Why after VRE-Enums.xml? Because in VRE-Enums.xml, here is load priority:

<loadPriority>3</loadPriority>

For More Help

At MAK, we are standing buy to help: support@mak.com

Cheers!