Jump to content

MIssion Scripting Tools (Mist)- enhancing mission scripting Lua


Recommended Posts

Yes I believe there is, check out "mist.getGroupData(groupName)". I believe this will also give every units loadout.

 

Edit: Something like this:

local myGroupData = mist.getGroupData(myGroupName) -- gets all data for the referenced group name
trigger.action.outText(mist.utils.tableShow(myGroupData), 25)  -- will show data on screen
env.info(mist.utils.tableShow(myGroupData))  -- will show data in log

Yes I looked into this and does not return the payload of spawned units. The way they get the payload is by getting the group and unit IDs then matching them to a group within the mission file. But does not work if you spawn multiple units as their group ids and unit ids are different. So im seeing if there is possible another way to do this.

Link to comment
Share on other sites

Payload is tricky. We have Unit.getAmmo() which returns an itemized list of the ammo, but its not a breakdown of which weapon is on which pylon. The pylon data is whats needed to spawn the unit with an appropriate payload. So that data is only accessible to units placed in the mission file. Come to think of it, I have never tested spawning AI with weapons defined by anything other than the CLSID that defines the weapon.

 

 

 

The best I could do within mist is to also search mist.DBs.dynGroupsAdded for payload data. But that only would work for dynamically spawned groups using mist because I cannot derive the payload data.

The right man in the wrong place makes all the difference in the world.

Current Projects:  Grayflag ServerScripting Wiki

Useful Links: Mission Scripting Tools MIST-(GitHub) MIST-(Thread)

 SLMOD, Wiki wishlist, Mission Editing Wiki!, Mission Building Forum

Link to comment
Share on other sites

Payload is tricky. We have Unit.getAmmo() which returns an itemized list of the ammo, but its not a breakdown of which weapon is on which pylon. The pylon data is whats needed to spawn the unit with an appropriate payload. So that data is only accessible to units placed in the mission file. Come to think of it, I have never tested spawning AI with weapons defined by anything other than the CLSID that defines the weapon.

 

 

 

The best I could do within mist is to also search mist.DBs.dynGroupsAdded for payload data. But that only would work for dynamically spawned groups using mist because I cannot derive the payload data.

 

Damn but you would think by now ED would have some functions for us to return a units current payload. So if I start with 4 jdams and drop two and I run this functions it will return 2 jdams ect and which pylons they are on.

Link to comment
Share on other sites

Question regarding the teleportGroup function:

 

I’m trying to set up a trigger that causes a carrier to teleport back to its original waypoint so that the player never has to deal with the carrier turning downwind. It sort of works, but static objects I placed on the deck despite being linked to the unit don’t show up when it respawns. Also I put true for the second parameter in teleportGroup, but the new ship isn’t findable on the same TACAN channel.

 

Any way to make these two things happen?

Link to comment
Share on other sites

Waypoints/route

 

Hey guys.

I'm having a bit of trouble with route following using mist.goRoute. (Fixedwing waypoints)

 

The trouble is that the aircraft doesn't make clean turns the wayt tyhey do using ME routes or even those created with CA.

 

CA created Route:

EwJQeyn.jpg

 

MiST Route:

BLnunlU.jpg

 

Results are about the same whether using 'turningpoint' or 'flyoverpoint' as the type in mist.fixedWing.buildWP.

Link to comment
Share on other sites

Results are about the same whether using 'turningpoint' or 'flyoverpoint' as the type in mist.fixedWing.buildWP.

 

 

Thats a longstanding bug of the scripting engine. AI given tasks via the scripting engine, for one reason or another, defaults to the flyoverpoint waypoint type for any task assigned during the mission. It works when you spawn an aircraft with that route assigned. But when you give it a new task after the aircraft spawns is when the bug occurs.

The right man in the wrong place makes all the difference in the world.

Current Projects:  Grayflag ServerScripting Wiki

Useful Links: Mission Scripting Tools MIST-(GitHub) MIST-(Thread)

 SLMOD, Wiki wishlist, Mission Editing Wiki!, Mission Building Forum

Link to comment
Share on other sites

If you spawn a group with their route, it works.

 

If you spawn a group then give them any route, its broken and uses fly over points. (as in having to use pushTask or setTask to give it to them.

 

 

I don't know if CA routes are effected by this bug or not.

The right man in the wrong place makes all the difference in the world.

Current Projects:  Grayflag ServerScripting Wiki

Useful Links: Mission Scripting Tools MIST-(GitHub) MIST-(Thread)

 SLMOD, Wiki wishlist, Mission Editing Wiki!, Mission Building Forum

Link to comment
Share on other sites

  • 2 weeks later...

Here's a question for Grimes, hope you have time to check if is true or not. I am writing the next sequence:

 

local groupData = mist.getGroupData('MyGroup')
groupData.groupID = newGID
groupData.groupName = 'New Name'
groupData.units[1].unitId = newUID
groupData.units[1].unitName = 'New Unit'
groupData.units[1].groupName= 'New Unit'
groupData.units[1].groupId=newGID

mist.dynAdd(groupData )

 

Everything works beautiful, checking on F10 map group name is the new name. I can't see the unit name but I can extract it and it looks ok. Problem comes when I want to pick up the group coming from the unit itself

 

local findGroupName = Unit.getGroup(myUnit):getName()

 

This returns the name of the initial group MyGroup and not New Name. Is there something I missed here?

Ta

[sIGPIC]OK[/sIGPIC]

Link to comment
Share on other sites

Right, I see there's no answer to my question above which probably is my fault being too specific. I have played more with dynAdd function and noticed that if I add a new group based on a

 

model = getGroupData('MyGroup') 

 

model and then dumping the mist.DBs to the log both mist_DBs_groupsByName.lua and mist_DBs_MEgroupsByName.lua I notice they are identical. Moreover, mist_DBs_dynGroupsAdded.lua is empty. That despite the fact that I see the new groups on the F10 map and funny enough they have the new group name I have assigned them using model["groupName"] = 'NewGroup'.

Which brings me to my question: what does clone supposed to do in the function call? Is this what I need to see the new group being created in the mist.DBs.groupsByName?

 

mist.dynAdd{ units = table unitsTable, country = string/number countryName/countryIndex, category = string/number categoryName/categoryIndex, name or groupName = string groupsName, groupId = number groupId, clone = anything clone, }

 

If so, how do I do that? Simply by assigning model["clone"] = true? I am asking because there's no example in the mist.DBs.groupByName

 

Thanks in advance!

[sIGPIC]OK[/sIGPIC]

Link to comment
Share on other sites

Clone acts as a flag to automatically generate a new groupName, groupId, unitNames, and unitIds if present. Usually it'll rename it USA GND 1 for groupname and USA GND 1 unit 1 for units.

 

Can you upload the miz file so I can experiment with it directly instead of having to recreate it and potentially doing something slightly different that I don't get the same result.

The right man in the wrong place makes all the difference in the world.

Current Projects:  Grayflag ServerScripting Wiki

Useful Links: Mission Scripting Tools MIST-(GitHub) MIST-(Thread)

 SLMOD, Wiki wishlist, Mission Editing Wiki!, Mission Building Forum

Link to comment
Share on other sites

Thanks Grimes. Figured it out myself through many tries that clone gives a new name and a real new group in the mission. Basically that was what I missed from my function call. While we are at it, assigning a route to a newly created group is possible only through goRoute() function? WHich means that the group must be spawned?

[sIGPIC]OK[/sIGPIC]

Link to comment
Share on other sites

You can spawn a group with a route or assign a new one after it spawns. mist.goRoute() is assigning a new route after it spawns and is done slightly differently by getting the groups controller and setting it as a new task.

 

Spawning a group with an existing route is probably the best way to do it, at least for aircraft.

One of the table entries for adding a group is called "route" and has quite a few entries possible for it. Here is the documenation on it: https://wiki.hoggitworld.com/view/DCS_task_mission

 

The only difference as far as the formatting of that table is concerned is that spawning a group with a route, you just start it with the route entry. If you are assigning the task after it spawns you need the following at the start. This is more or less what the goRoute function does, it just creates that corrected formatting and assigns the task immediately.

Mission = { 
 id = 'Mission', 
 params = { 

 

 

Here is a small bit of code of a route I just had laying around. Pretty much copied it directly out of a miz file.

["route"] = 
   {
       ["points"] = 
       {
           [1] = 
           {
               ["alt"] = 2000,
               ["action"] = "Turning Point",
               ["alt_type"] = "BARO",
               ["speed"] = 138.88888888889,
               ["task"] = 
               {
                   ["id"] = "ComboTask",
                   ["params"] = 
                   {
                       ["tasks"] = 
                       {
                           [1] = 
                           {
                               ["enabled"] = true,
                               ["auto"] = true,
                               ["id"] = "WrappedAction",
                               ["number"] = 1,
                               ["params"] = 
                               {
                                   ["action"] = 
                                   {
                                       ["id"] = "EPLRS",
                                       ["params"] = 
                                       {
                                           ["value"] = true,
                                           ["groupId"] = 1,
                                       }, -- end of ["params"]
                                   }, -- end of ["action"]
                               }, -- end of ["params"]
                           }, -- end of [1]
                       }, -- end of ["tasks"]
                   }, -- end of ["params"]
               }, -- end of ["task"]
               ["type"] = "Turning Point",
               ["ETA"] = 0,
               ["ETA_locked"] = true,
               ["y"] = 648400.296,
               ["x"] = -291732.52314285,
               ["name"] = "DictKey_WptName_8",
               ["formation_template"] = "",
               ["speed_locked"] = true,
           }, -- end of [1]
       }, -- end of ["points"]
   }, -- end of ["route"]]

The right man in the wrong place makes all the difference in the world.

Current Projects:  Grayflag ServerScripting Wiki

Useful Links: Mission Scripting Tools MIST-(GitHub) MIST-(Thread)

 SLMOD, Wiki wishlist, Mission Editing Wiki!, Mission Building Forum

Link to comment
Share on other sites

i would like to thank Grimes/Speed for the hard work put in creating MIST. im sure you have been thanked a 1000 times over. but i'll make it 1001 :-)

on the GitHub repository "ReSpawn_example" was a life saver. reduced a wall of code to barely nothing.

can someone point me in the right direction to make the unit hidden until called upon with an F10 command, but still remain an unlimited number of spawns?

Sample miz attached

.

respawn_example.miz


Edited by july865
including Speed

Asus x99, i7 5930k, 32g mem, MSI 1070GTX, 970 Samsung M.2, LG 35in Ultra-Wide, TrackIR 4

Thrustmaster Warthog HOTAS

[sIGPIC][/sIGPIC]

Link to comment
Share on other sites

Unfortunately you can't make it hidden, only invisible to AI. I could not access hidden property of an object already spawned.

Yes, thousand thanks to Grimes/Speed for MIST. I would like to repay them somehow, maybe enhancing the documentation which is really brief, maybe adding some working examples for the functions and so on. MIST saved me writing many lines of code as well, many functions I wanted to create were already there.

[sIGPIC]OK[/sIGPIC]

Link to comment
Share on other sites

my apologies to Speed for not including him.

I had tried "Late Activation" with the script but it only worked for 1 respawn. Changing the Time function just wouldn't work at all.

Cant recall where, but i had play on a server that went on for hours with respawning units at will, using the radio menu. all units where invisible until called upon.


Edited by july865
typo

Asus x99, i7 5930k, 32g mem, MSI 1070GTX, 970 Samsung M.2, LG 35in Ultra-Wide, TrackIR 4

Thrustmaster Warthog HOTAS

[sIGPIC][/sIGPIC]

Link to comment
Share on other sites

  • 2 weeks later...

Can you upload the miz file so I can experiment with it directly instead of having to recreate it and potentially doing something slightly different that I don't get the same result.

 

Hi Grimes,attached the mission for test. I am having one group with late activation and getting the group model from it. Then I assign the route on the fly and modifying the route points in the process. Group spawns alright but at the initial location of the group I take the model from even if the route points is different. Group just spawns , moves for about one minute and then stops, mind you from the initial location not the one I gave it in the route table.

tst.miz

[sIGPIC]OK[/sIGPIC]

Link to comment
Share on other sites

They aren't moving in that sample file at all. Mostly because it looks like the spawned group never gets the route.

 

An important thing to note about route building is that.

 

A. Its best to set the start waypoint at roughly the coordinates of the first AI in the group. In the past the AI have just decided to ignore routes if the WP wasn't like that.

B. Ground AI might "give up" on orders if they can't reach the destination by a given ETA. Basically a minute after they fail to reach a WP at the specified time they just stop and give up. Its a noticeable problem with amphibious units where the ETA is often based on a speed the units can't reach over water.

The right man in the wrong place makes all the difference in the world.

Current Projects:  Grayflag ServerScripting Wiki

Useful Links: Mission Scripting Tools MIST-(GitHub) MIST-(Thread)

 SLMOD, Wiki wishlist, Mission Editing Wiki!, Mission Building Forum

Link to comment
Share on other sites

Route is given by using group.route = table route at the time the the table needed to dynAdd the group is created. Basically I am passing before dynAdd is created. Basically, this is the function

 

local groupPrefix = 'XGRP'
local unitPrefix = 'XUNI'


function DeepPrintTable(e)
   -- if e is a table, we should iterate over its elements
   if type(e) == "table" then
       for k,v in pairs(e) do -- for every element in the table
           print(k)
           DeepPrintTable(v)       -- recursively repeat the same procedure
       end
   else -- if not, we can just print it
       env.info(e)
   end
end

function generateVehiclesRoute()
   local startPoint = {}
   local endPoint = {}
   -- Decide if they will move off(0) or on(1) road 
   local routeChoiceRandom = mist.utils.round(mist.random(0,1))
   -- Pick one zone to spawn the group
   local pickedZone = 'SpawnGround_' .. mist.utils.round(mist.random(1,6))
   
   if routeChoiceRandom == 0 then
       startPoint = mist.getRandomPointInZone(pickedZone)
       endPoint = mist.getRandomPointInZone(pickedZone)
       routeChoice = "Off Road"
   else
       local nearestRoadStart_x, nearestRoadStart_y = land.getClosestPointOnRoads('roads',mist.getRandomPointInZone(pickedZone).x, mist.getRandomPointInZone(pickedZone).y)
       local nearestRoadEnd_x, nearestRoadEnd_y = land.getClosestPointOnRoads('roads',mist.getRandomPointInZone(pickedZone).x, mist.getRandomPointInZone(pickedZone).y)
       startPoint = {nearestRoadStart_x, nearestRoadStart_y}
       endPoint = {nearestRoadEnd_x, nearestRoadEnd_y}
       routeChoice = "On Road"
   end
   
   local vehiclesRoute = {
       [1] = 
       {
           ["alt"] = 66,
           ["type"] = "Turning Point",
           ["ETA"] = 0,
           ["alt_type"] = "BARO",
           ["formation_template"] = "",
           ["y"] = startPoint.y,
           ["x"] = startPoint.x,
           ["name"] = "STA",
           ["ETA_locked"] = true,
           ["speed"] = 5.5555555555556,
           ["action"] = routeChoice,
           ["task"] = 
           {
               ["id"] = "ComboTask",
               ["params"] = 
               {
                   ["tasks"] = 
                   {
                   }, -- end of ["tasks"]
               }, -- end of ["params"]
           }, -- end of ["task"]
           ["speed_locked"] = true,
       }, -- end of [1]
       [2] = 
       {
           ["alt"] = 64,
           ["type"] = "Turning Point",
           ["ETA"] = 164.7057218182,
           ["alt_type"] = "BARO",
           ["formation_template"] = "",
           ["y"] = endPoint.y,
           ["x"] = endPoint.x,
           ["name"] = "END",
           ["ETA_locked"] = false,
           ["speed"] = 5.5555555555556,
           ["action"] = routeChoice,
           ["task"] = 
           {
               ["id"] = "ComboTask",
               ["params"] = 
               {
                   ["tasks"] = 
                   {
                       [1] = 
                       {
                           ["enabled"] = true,
                           ["auto"] = false,
                           ["id"] = "GoToWaypoint",
                           ["number"] = 1,
                           ["params"] = 
                           {
                               ["fromWaypointIndex"] = 2,
                               ["nWaypointIndx"] = 1,
                           }, -- end of ["params"]
                       }, -- end of [1]
                   }, -- end of ["tasks"]
               }, -- end of ["params"]
           }, -- end of ["task"]
           ["speed_locked"] = true,
       }, -- end of [2]
   }
   return vehiclesRoute
end

function generateVehiclesModel(modelType)
   local vehiclesGroupId = mist.getNextGroupId()
   local vehiclesGroupName = groupPrefix .. '-' .. vehiclesGroupId

   if modelType == 'easy' then
       groundModel = mist.getGroupData('easyGroundModel')
       env.info('Easy Ground:' .. #groundModel.units)
   elseif modelType == 'medium' then
       groundModel = mist.getGroupData('mediumGroundModel')
       env.info('Medium Ground:' .. #groundModel.units)
   elseif modelType == 'hard' then
       groundModel = mist.getGroupData('hardGroundModel')
       env.info('Hard Ground:' .. #groundModel.units)
   end
   
   groundModel["clone"] = true
   groundModel["route"] = generateVehiclesRoute()
   groundModel.groupId = vehiclesGroupId
   groundModel["groupName"] = vehiclesGroupName
   

   local vehiclesUnitId = mist.getNextUnitId()
   for i = 1,#groundModel.units do
       groundModel["units"][i]["name"] = unitPrefix .. '-' .. vehiclesUnitId
       groundModel["units"][i]["groupId"] = vehiclesGroupId
       groundModel["units"][i]["groupName"] = vehiclesGroupName
       vehiclesUnitId = vehiclesUnitId + 1
   end

   return groundModel
end


Edited by Zayets

[sIGPIC]OK[/sIGPIC]

Link to comment
Share on other sites

That code is different from the one from the attached mission file. Which the new code didn't work with the old mission. I figured it out and modified as needed.

 

By the looks of things it works when given the off road tasking. The AI go to the first waypoint and then loop their route accordingly. What is interesting though that it appears that the AI completely ignore objects, speed, and group formation to get to and return to the initial waypoint. Best guess is that is a DCS bug that needs investigating.

 

The on road tasking is what is causing the strange result. Using CA to select the group it appears they are wanting to go to the tip of land near the Kerch Straits in the far western side of the populated map. Did some experimenting and figured out the issue.

 

       local nearestRoadStart_x, nearestRoadStart_y = land.getClosestPointOnRoads('roads',mist.getRandomPointInZone(pickedZone).x, mist.getRandomPointInZone(pickedZone).y)
       local nearestRoadEnd_x, nearestRoadEnd_y = land.getClosestPointOnRoads('roads',mist.getRandomPointInZone(pickedZone).x, mist.getRandomPointInZone(pickedZone).y)
       --startPoint = {nearestRoadStart_x, nearestRoadStart_y}
       startPoint = {x = nearestRoadStart_x, y = nearestRoadStart_y}
       --endPoint = {nearestRoadEnd_x, nearestRoadEnd_y}
       endPoint = {x = nearestRoadEnd_x, y = nearestRoadEnd_y}
       routeChoice = "On Road"

 

The commented out part is your code. Basically the table looked like {[1] = xValue, [2] = yValue} instead of {x = xValue, y = yValue}. So I think the scripting engine didn't know what to do with that and tried to create a waypoint from the nearest road at map origin.

 

Worth mentioning is that your code to assign the point is running the mist.getRandomPointInZone twice.

 

local nearestRoadStart_x, nearestRoadStart_y = land.getClosestPointOnRoads('roads',mist.getRandomPointInZone(pickedZone).x, mist.getRandomPointInZone(pickedZone).y)

 

So it is generating an X, Y coordinate and using the X value, then generating another coordinate to use the Y value. Technically there is nothing wrong with that, its just doing the work twice for a random result.

The right man in the wrong place makes all the difference in the world.

Current Projects:  Grayflag ServerScripting Wiki

Useful Links: Mission Scripting Tools MIST-(GitHub) MIST-(Thread)

 SLMOD, Wiki wishlist, Mission Editing Wiki!, Mission Building Forum

Link to comment
Share on other sites

Thanks Grimes for your time. Did the necessary change and a slight difference in units behavior occurred. Group is not stopping and it looks like it goes to point 1 in route. Unfortunately it does not spawn in point 1 as I wanted, it acts like the group receives a go to route command from the point in which is spawned (which is not point 1). Well, i guess I will have to go for other approach, I am thinking to use clone in zone and then assign a go to route command. Maybe this will work better in this case.

As for the function being called twice, I got lazy when testing and leave it that way. Again, thanks for the check. It looks like I modified the script but not reloaded in the mission, that's why you ended up with the wrong file.

[sIGPIC]OK[/sIGPIC]

Link to comment
Share on other sites

Yeah you gotta iterate through the units table within the group to create a new spawnpoint for them. The first waypoint for the group is just its waypoint, the units have their own coordinates that are used. The mist.teleportToPoint() function uses something like this where newCoord is the coordinate generated and newGroupData is the group table. It creates an offset point and changes the spawning position for the group.

 

local diff = {x = (newCoord.x - newGroupData.units[1].x), y = (newCoord.y - newGroupData.units[1].y)}
for unitNum, unitData in pairs(newGroupData.units) do
   newGroupData.units[unitNum].x = unitData.x + diff.x
   newGroupData.units[unitNum].y = unitData.y + diff.y
end

The right man in the wrong place makes all the difference in the world.

Current Projects:  Grayflag ServerScripting Wiki

Useful Links: Mission Scripting Tools MIST-(GitHub) MIST-(Thread)

 SLMOD, Wiki wishlist, Mission Editing Wiki!, Mission Building Forum

Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...