MIssion Scripting Tools (Mist)- enhancing mission scripting Lua

[HiJack]

Yes at least 20 minutes. The same goes for aircrafts AI parks. Implementing code to deactivate units that get stuck is needed if you run random spawned aircraft starting cold and parking. Code to disable AI aircrafts with speed 0 for 5 minutes.

[eric963]

mist.teleportInZone with MIST 3.4.26 works fine for me in my test mission but is giving an error message when using 3.5.35

teleportInZone.miz

[Grimes]

That one slipped through the cracks. It has been fixed. Thanks!

[HiJack]

I get extreme loss of fps in a mission that is updated with MIST 3.5.35 are there known issues Grimes? It's a mission sitting on my disk since early 2014 so there can be other issues as well. I was down to 5 fps when viewing a mission editor spawn B52 bomber :( and the low fps did not go away, had to stop the mission and start over.

[Grimes]

Hmmm. I can't think of anything that may cause that off the top of my head. Its something I'd have to reproduce and investigate on my end. Can you send me the miz file?

[chromium]

Question about dynAdd (I'm aware for the lag but I really can wait for fixes :) )

 

I'm adding a CAP flight with a dedicated function, and for adding units I have separated waypoints table from the Group info variables that are in dynAdd (like is done in helicopterScript)

 

I have those as points table:

 

  local points = {
    [1] =     {
          ["alt"] = 0, -- set a quarter of the climb altitute
          ["type"] = "TakeOffParking",
          ["action"] = "From Parking Area",
          ["alt_type"] = "RADIO",
          ["formation_template"] = "",
          ["properties"] = 
          {
           ["vnav"] = 1,
           ["scale"] = 0,
           ["angle"] = 0,
           ["vangle"] = 0,
           ["steer"] = 2,
          }, -- end of ["properties"]
          ["ETA"] = currentTime,-- REVIEW
          ["airdromeId"] = airfieldId,
          ["y"] = AFBy,
          ["x"] = AFBx,
          ["speed"] = 0, -- REVIEW
          ["ETA_locked"] = true,
          ["task"] = 
          {
           ["id"] = "ComboTask",
           ["params"] = 
           {
            ["tasks"] = 
            {
             [1] = 
             {
              ["number"] = 1,
              ["auto"] = true,
              ["id"] = "EngageTargets",
              ["enabled"] = true,
              ["key"] = "CAP",
              ["params"] = 
              {
               ["targetTypes"] = 
               {
                [1] = "Air",
               }, -- end of ["targetTypes"]
               ["priority"] = 0,
              }, -- end of ["params"]
             }, -- end of [1]
            }, -- end of ["tasks"]
           }, -- end of ["params"]
          }, -- end of ["task"]
          ["speed_locked"] = true,
         },
    [2] =     {
          ["alt"] = FlightAltitude/4,
          ["type"] = "Turning Point",
          ["action"] = "Turning Point",
          ["alt_type"] = "BARO",
          ["formation_template"] = "",
          ["properties"] = 
          {
           ["vnav"] = 1,
           ["scale"] = 0,
           ["angle"] = 0,
           ["vangle"] = 0,
           ["steer"] = 2,
          }, -- end of ["properties"]
          ["name"] = "T/O",
          ["ETA"] = currentTime+600, -- REVIEW
          ["airdromeId"] = airfieldId,
          ["y"] = wp1pos.z,
          ["x"] = wp1pos.x,
          ["speed"] = 155, -- REVIEW
          ["ETA_locked"] = false,
              ["task"] = 
              {
               ["id"] = "ComboTask",
               ["params"] = 
               {
                ["tasks"] = 
                {
                 [1] = 
                 {
                  ["number"] = 1,
                  ["auto"] = false,
                  ["id"] = "WrappedAction",
                  ["enabled"] = true,
                  ["params"] = 
                  {
                   ["action"] = 
                   {
                    ["id"] = "Option",
                    ["params"] = 
                    {
                     ["value"] = 1,
                     ["name"] = 3,
                    }, -- end of ["params"]
                   }, -- end of ["action"]
                  }, -- end of ["params"]
                 }, -- end of [1]
                }, -- end of ["tasks"]
               }, -- end of ["params"]
              }, -- end of ["task"]
          ["speed_locked"] = true,
         }, -- end 2
    
       (OTHER WAYPOINT, POST TOO LONG)

    [6] =     {
                                           ["alt"] = 0,
                                           ["type"] = "Land",
                                           ["action"] = "Landing",
                                           ["alt_type"] = "RADIO",
                                           ["formation_template"] = "",
                                           ["properties"] = 
                                           {
                                               ["vnav"] = 1,
                                               ["scale"] = 0,
                                               ["angle"] = 0,
                                               ["vangle"] = 0,
                                               ["steer"] = 2,
                                           }, -- end of ["properties"]
                                           ["ETA"] = FlightStationTime+FlightETA+1800,
                                           ["airdromeId"] = airfieldId,
                                           ["y"] = AFBy,
                                           ["x"] = AFBx,
                                           ["speed"] = 138.88888888889, --REVIEW
                                           ["ETA_locked"] = false,
                                           ["task"] = 
                                           {
                                               ["id"] = "ComboTask",
                                               ["params"] = 
                                               {
                                                   ["tasks"] = 
                                                   {
                                                   }, -- end of ["tasks"]
                                               }, -- end of ["params"]
                                           }, -- end of ["task"]
                                           ["speed_locked"] = true,
                                       }, -- end of [6]
      }

 

 

And Those as spawning function (Every variables has its reference)

 

   mist.scheduleFunction(mist.dynAdd,
   -- table vars
   {{ 
    ["units"] = 
     {
      [1] = 
      {
       ["alt"] = 100, -- change for test
       ["alt_type"] = "RADIO",
       ["skill"] = "Random",
       ["speed"] = 200, -- change for test
       ["type"] = flightAirframe, -- is F-5E
       ["y"] = AFBy,
       ["x"] = AFBx,
       ["name"] = unitName,
       ["psi"] = 1.4896291831607,
       ["payload"] = 
       {
        ["pylons"] = pylonData, -- is PylonData table
        ["fuel"] = FlightFuel,
        ["flare"] = FlightFlare,
        ["chaff"] = FlightChaff,
        ["gun"] = FlightGun,
       }, -- end of ["payload"]
       ["heading"] = -1.4896291831607,
       ["route"] = 
       {
        ["points"] = points,
       }, -- end of ["route"]
      }, -- end of [1]
     },
    ["country"] = "USA",
    ["category"] = "AIRPLANE",
   }},
   timer.getTime()+1)

 

Well, the log doesn't report any Issues, the F-5E is spawned but:

 

1. If I use alt = 0 and speed = 0 in the initial spawning position the Group die at runway start (AFBx and AFBy are taken from airport position, not parking position)

 

2. the spawned Aircraft fly away from the airport and then come back and land, ignoring the waypoints (even if delete and sobstitute the first one that should be "start-up".

 

 

So:

 

-Can you help me understanding what I'm doing wrong about the route?

-How can I get to have an uncontrolled plane spawned on a parking spot as initial wp?

 

Thanks so much :)

[chromium]

Ok, rewriting the function a couple of times i got to spawn it, but still I can't spawn it on a parking spot.. any ideas? :(

[Shadow KT]

Hey guys, I am new to this and I think I''ll need a lot of time to get the hang of it so I want to ask for a favour. Could it be done that if you have a group of vehicles and it dies it automatically respawns again. It's for trainign purpose and I know I can make it the normal way by putting a lot of groups which would have late activations and spawn with triggers. But I don't want to be limited to the number of groups I have and don't want to make the groups be from thousand of units so they just fill the map. So, would anyone be kind enough to help me out

[Wizard1393]

mist.respawnGroup or mist.clonegroup

 

Hi all,

 

When using mist.respawnGroup or mist.clonegroup on a Huey group the new group always seem to spawn with callsign Enfield 1-1. Another Huey "Client" group in the editor has callsign Enfield 1-1.

 

If this client is used by someone. The script crashes DCS.

 

If not, everything works, although I assume if the client was to connect once the AI group has respawned as Enfield, I suppose it would crash also.

 

How do I tell mist what callsign the "respawned" group should have?

Or is there a was to make mist.respawnGroup/clonegroup to "copy" the groups callsign also?

 

:helpsmilie:

[Grimes]

mist.respawnGroup and cloneGroup are supposed to copy the callsigns. Make sure you are using the latest mist version, see github link in my signature. I tested it in single player and the correct callsign was used. However there could be a clientside issue not correctly syncing the callsigns. I'll test this later to verify.

[Wizard1393]

mist.respawnGroup and cloneGroup are supposed to copy the callsigns. Make sure you are using the latest mist version, see github link in my signature. I tested it in single player and the correct callsign was used. However there could be a clientside issue not correctly syncing the callsigns. I'll test this later to verify.

 

Thanks Grimes! I'll check it with latest from GitHub. I was using 3.4...

It shouldn't matter if the group I'm cloning is created with MIST or within the mission editor right?

[Grimes]

I did fix something related to callsigns with 3.5 so that alone might fix your problem.

 

To answer you question,

I think it might depend on whether or not you set the callsigns correctly. If the group was created within the mission editor it will simply use that groups callsign again. But if it is created with mist and you don't specify a callsign then the callsign will default to Enfield 11. But within mist it doesn't explicitly define that, so that could be causing an issue. In other words the sim defaults to Enfield 11 as the default callsign. I suppose it might be time I look into a callsign management script.

[HiJack]

The AWACS respawn script is a good example on how to use the callsign database

 

do

local groupName = 'BAWACS' -- Name of the group in the ME
local country = 'USA' -- Country for Tanker, like 'USA' or 'RUSSIA'
local callsign = 5 -- 1 = Overlord, 2 = Magic, 3 = Wizard, 4 = Focus, 5 = Darkstar or First Number for IL-78M
local callsign2 = 1 -- Second Number for IL-78M, irrelevant for KC-135

local oldName = groupName
if blue_respawn_awacs == nil then
   blue_respawn_awacs = {[groupName] = 0}
elseif blue_respawn_awacs[groupName] == nil then
   blue_respawn_awacs[groupName] = 0
else
   oldName = groupName .. blue_respawn_awacs[groupName]
end
blue_respawn_awacs[groupName] = blue_respawn_awacs[groupName] + 1
local newName = groupName .. blue_respawn_awacs[groupName]

local group = Group.getByName(oldName)
if group then
   group = group:getController()
   Controller.setCommand(group, {id = 'DeactivateBeacon', params = {}})
   Controller.setTask(group, {id = 'NoTask', params = {}})
end

group = mist.getGroupData(groupName)
group.route = { points = mist.getGroupRoute(groupName, true) }
group.groupName = newName
group.groupId = nil
group.units[1].unitId = nil
group.units[1].unitName = newName
group.country = country
group.category = 'AIRPLANE'

mist.dynAdd(group)

group = Group.getByName(newName)
group = group:getController()
Controller.setCommand(group, {id = 'SetCallsign', params = {callname = callsign, number = callsign2}})
blue_awacs_respawn = true -- variable to identify that the tanker just have respawned
ba1_counter = 0

end;

[Stonehouse]

I've been doing some more work on the CAP GCI script and been running into issues with getGroupData and retrieving the countryID. I've set up some FW190s with country Germany as my red CAP template aircraft and ditto for my red GCI template planes. Similarly I have some USA P51s for the blue CAP and blue GCI template planes. These are all set late activation single plane groups with no spawn trigger. Anyway the script picks up payload, skin, skill etc - which all works fine and I'm now adding picking up the countryId using mist.getGroupData.

 

What I am seeing is that the countryId seems to be returned with the wrong value. So I see Russian P51s and USA FW190s. Below is the returned group table for one of the red FW190 cap spawns. As you can see it has the country as Germany but countryid = 2. Which I believe is USA. So all the spawns get the wrong country. I've double checked that the mission has red countries Germany and Ukraine and Blue is UK, Georgia, USA and Australia so it's not due to me setting Germany on the blue side and the showtable info below seems fairly conclusive that for once it isn't my screwed up scripting. Using the 3.5.36 version of Mist.

 

Is this a Mist bug? or a DCS issue?

 

Thanks for any help someone can give.

 

Cheers,

Stonehouse

 

00210.973 INFO SCRIPTING: red groupdatatable: {

["modulation"] = 0,

["groupId"] = 24,

["hidden"] = false,

["frequency"] = 38.4,

["groupName"] = "__CAP__red2",

["units"] = table: 00000000A2315390 {

["units"][1] = table: 00000000A16FE9B0 {

["units"][1]["alt"] = 2000,

["units"][1]["type"] = "FW-190D9",

["units"][1]["unitId"] = 54,

["units"][1]["callsign"] = table: 00000000A2315690 {

["units"][1]["callsign"][1] = 1,

["units"][1]["callsign"][2] = 2,

["units"][1]["callsign"][3] = 1,

["units"][1]["callsign"]["name"] = "Enfield21",

},

["units"][1]["livery_id"] = "2",

["units"][1]["skill"] = "Random",

["units"][1]["onboard_num"] = "052",

["units"][1]["y"] = 714000,

["units"][1]["x"] = -308457.14285714,

["units"][1]["heading"] = 0,

["units"][1]["payload"] = table: 000000005DFEAD80 {

["units"][1]["payload"]["pylons"] = table: 000000005DFEADD0 {

["units"][1]["payload"]["pylons"][1] = table: 000000005DFEAE70 {

["units"][1]["payload"]["pylons"][1]["CLSID"] = "FW109_FUEL_TANK",

},

},

["units"][1]["payload"]["fuel"] = 388,

["units"][1]["payload"]["flare"] = 0,

["units"][1]["payload"]["chaff"] = 0,

["units"][1]["payload"]["gun"] = 100,

},

["units"][1]["speed"] = 138.88888888889,

["units"][1]["unitName"] = "__CAP__red2",

["units"][1]["alt_type"] = "BARO",

},

},

["countryId"] = 2,

["radioSet"] = false,

["country"] = "germany",

["category"] = "plane",

["coalition"] = "red",

["startTime"] = 0,

["task"] = "CAP",

["uncontrolled"] = false,

}

[FSFIan]

Seems to be a MiST bug.

 

My test mission has an australian "bluecap" group.

 

Country ID:

return Group.getByName("bluecap"):getUnit(1):getCountry()
=> number
21

 

 

Country Name:

return country.names[Group.getByName("bluecap"):getUnit(1):getCountry()]:lower()
=> string
australia

 

MiST data:

return mist.utils.tableShow(mist.getGroupData("bluecap"))
=> string
{
["modulation"] = 0,
["groupId"] = 2,
["hidden"] = false,
["frequency"] = 124,
["groupName"] = "bluecap",
["units"] = table: 0000000050303370     {
   ["units"][1] = table: 000000005042C8F0         {
       ["units"][1]["alt"] = 2000,
       ["units"][1]["type"] = "P-51D",
       ["units"][1]["unitId"] = 5,
       ["units"][1]["callsign"] = table: 000000005243C760             {
           ["units"][1]["callsign"][1] = 1,
           ["units"][1]["callsign"][2] = 1,
           ["units"][1]["callsign"][3] = 1,
           ["units"][1]["callsign"]["name"] = "Enfield11",
           },
       ["units"][1]["livery_id"] = "Bare Metal",
       ["units"][1]["skill"] = "High",
       ["units"][1]["onboard_num"] = "010",
       ["units"][1]["y"] = 635540.57142857,
       ["units"][1]["x"] = -318187.14285715,
       ["units"][1]["heading"] = 0,
       ["units"][1]["payload"] = table: 0000000050A4CB88             {
           ["units"][1]["payload"]["pylons"] = table: 0000000050A4CBD8                 {
               },
           ["units"][1]["payload"]["fuel"] = 497.76,
           ["units"][1]["payload"]["flare"] = 0,
           ["units"][1]["payload"]["chaff"] = 0,
           ["units"][1]["payload"]["gun"] = 100,
           },
       ["units"][1]["speed"] = 138.88888888889,
       ["units"][1]["unitName"] = "Pilot #001",
       ["units"][1]["alt_type"] = "BARO",
       },
   },
["countryId"] = 7,
["radioSet"] = false,
["country"] = "australia",
["category"] = "plane",
["coalition"] = "blue",
["startTime"] = 0,
["task"] = "CAS",
["uncontrolled"] = false,
}

[Stonehouse]

Thanks for confirming that Ian. Since I have the group name at that point in the script I will use the alternative method you've displayed so I can release the next version of the script. It was just that I'd already done a getGroupData for the other stuff so picking up countryId off the same function call was the easiest way.

 

Although knowing Grimes he'll fix it pretty quickly anyway.

 

Cheers,

Stoney

[Grimes]

The problem is with the initial database creation code where it is using the coalition index for the country instead of the country ID.

 

Should be fixed: https://github.com/mrSkortch/MissionScriptingTools/releases

[Stonehouse]

Great (and very quick) news! Thanks Grimes!

[LFCChameleon_Silk]

can you start adding version number to the MIST filename? I got like 8 mists laying around and its a pain to try and remember which one is the newest one.

 

other then that great work.

[HiJack]

Inside the mist file there is a build number at the top.

[Fishbreath]

I'm having some trouble with the teleportToPoint call at the end of this function:

 

function bvr_spawn()
   -- Groups e.g. bvr.template.far.modernfighter have standard orders
   -- for a given type and spawn zone    
   local orders_template = "bvr.template." .. bvr_current_location .. "." ..             bvr_template_argument
   
   -- Group names e.g. bvr.phantom.ir_missile for cloning
   local group_name = "bvr." .. bvr_current_type .. "." .. bvr_current_armament
   
   local template_route = mist.getGroupRoute(orders_template)
   env.info("template_route\n" .. mist.utils.tableShow(template_route))
   local template_position = mist.getLeadPos(orders_template)
   env.info("start position\n" .. mist.utils.tableShow(template_position))
   
   for i=1,bvr_current_count do
       local vars = {}
       vars.groupName = group_name
       vars.action = 'clone'
       vars.point = template_position
       vars.disperse = true
       vars.maxDisp = 3000
       vars.radius = 3000
       vars.innerRadius = 100
       local new_group = mist.teleportToPoint(vars)
       
       mist.goRoute(new_group, template_route)
       
       env.info(i)
       env.info("spawned new unit " .. new_group .. " after template " .. group_name .. " with orders " .. orders_template)
   end
end

 

There are two template groups interacting here: the plane template (group_name in the code above), which controls type and armament, and the orders template (orders_template), which has orders and behaviors. Both templates start deactivated and are never actually activated at all. The intention is to keep one copy of the plane template out of the way, to avoid cluttering up the map, teleporting/cloning it to the orders template's position and orders as needed.

 

teleportToPoint works correctly in that it teleports the groups to the orders template's location, but it doesn't change their altitudes—they start at the plane template's altitude. Is that intended behavior?

[Stonehouse]

Just reporting back Grimes that the fix to the database population you did this morning fixed the issue. GCI CAP script now working well.

 

Cheers,

Stoney

[Fishbreath]

Looking at the MIST source, it seems to me that teleportToPoint calls getRandPointInCircle, which returns a vec2 no matter what you pass it, so the behavior where teleportToPoint doesn't preserve altitude is expected, at least.

 

Edit: this change preserves altitude for aircraft and helicopters, if teleportToPoint's vars.point is a vec3.

 

-- Start: 3.5.37 line 5012
for unitNum, unitData in pairs(newGroupData.units) do
       if disperse then
           if maxDisp and type(maxDisp) == 'number' and unitNum ~= 1 then
               newCoord = mist.getRandPointInCircle(origCoord, maxDisp)
           --else
               --newCoord = mist.getRandPointInCircle(zone.point, zone.radius)
           end

           newGroupData.units[unitNum]['x'] = newCoord.x
           newGroupData.units[unitNum]['y'] = newCoord.y
       else
           newGroupData.units[unitNum]["x"] = unitData.x + diff.x
           newGroupData.units[unitNum]["y"] = unitData.y + diff.y
       end
       
+       if string.lower(newGroupData.category) == 'plane' or
+               string.lower(newGroupData.category) == 'helicopter' then
+           if point.z then
+               newGroupData.units[unitNum]["alt"] = point.y
+           end
+       end
   end
-- End: 3.5.37 line 5033

Edited October 2, 2014 by Fishbreath

[Grimes]

can you start adding version number to the MIST filename? I got like 8 mists laying around and its a pain to try and remember which one is the newest one.

 

I started doing that when I added mist to github. If I saved as a new file, github doesn't really recognize any of the differences between the two files, which is incredibly usefull. I might be able to just change the name of the file, but I'm not entirely sure. At the very least I can update the the forum download to contain the version number.

 

 

 

Fishbreath, aircraft aren't meant for use with the teleport/'spawnInZone" functions. Namely because the difference in spawning an igla randomly in a .5km radius has more impact on what could happen than spawning an aircraft randomly within a 50km radius . But also because individual aircraft can be controlled via scripting and aircraft in itself have way more possibilities than ground units.

[Fishbreath]

Fishbreath, aircraft aren't meant for use with the teleport/'spawnInZone" functions. Namely because the difference in spawning an igla randomly in a .5km radius has more impact on what could happen than spawning an aircraft randomly within a 50km radius . But also because individual aircraft can be controlled via scripting and aircraft in itself have way more possibilities than ground units.

 

It seems like there's no way, though, to copy one deactivated instance of an aircraft within a small radius of a designated point, at a given altitude distinct from the deactivated group's altitude. My change allows that. Doesn't have to make it into the main release, but it doubled the possibilities for me in my shooting range mission.

Edited October 5, 2014 by Fishbreath