MIssion Scripting Tools (Mist)- enhancing mission scripting Lua

[chromium]

I tried in a different mission dumping the Db after the teleported Group Was destroyed having the issue. I Will Sent you another version tomorrow evening if i can replicate the issue

 

Inviato dal mio SM-G850F utilizzando Tapatalk

 

Can't replicate, for sure my issue. I will try to understand better.

[Grimes]

definetly the function mist.getUnitsLOS does not accept a variable in its radius argument. I made thousand tests, and it always works with number, but it never work with a variable such as _reconraius = 1000.

 

The variable is passed just fine, its the value that is passed which is creating the problem. Basically the radius value checked is always less than the altitude above ground level, so it is impossible for any ground unit to be within that distance. Since mist.getUnitsLOS already checks to see if the objects are within a "sphere" around the aircraft it would probably be best to just use a hard value to get the units within the distance first. Then you filter that information out by figuring out where those objects are in relation of the recon aircraft. You would have to do trig on the x,y, and z axis and determine if it is within a given range.

[ESAc_matador]

I get it. If the function has cylindrical, it would work...

[SkyCap]

-fixed-

Edited August 13, 2016 by SkyCap

[ESAc_matador]

The variable is passed just fine, its the value that is passed which is creating the problem. Basically the radius value checked is always less than the altitude above ground level, so it is impossible for any ground unit to be within that distance. Since mist.getUnitsLOS already checks to see if the objects are within a "sphere" around the aircraft it would probably be best to just use a hard value to get the units within the distance first. Then you filter that information out by figuring out where those objects are in relation of the recon aircraft. You would have to do trig on the x,y, and z axis and determine if it is within a given range.

 

hello Grimes.

 

I am back from hollydays, and I am again with the Recon Camera Plane...

 

what happen is when I try to combine the getUnitLOS with results gotten from getUnitsInMovingZones it does not work.

 

Separately, they work fine, and I can get the results expected. I am putting all results in a table of units called targets, after the mission I process it, and it works fine.

 

The problem is,

 

I first do:

 

redunitsrec_insidezone = mist.getUnitsInMovingZones(redunits , blueunits, _reconradius , 'cylinder' )

so I get all red units in the moving zone, this works fine.

 

After that, I do

mist.getUnitsLOS(blueunits,2,redunitsrec_insidezone,2,12000)

but seems like he is not using redunitsrec_insidezone. if I put redunits instead of redunitsrec_insidezone

 

redunits = mist.makeUnitTable({'[red][vehicle]'})

instead of redunitsrec_insidezone it works fine, so the problem is localized. Here is all

 

 

it works fine...

 

 

Here is all the script

 

function getUnitsRecon()

local redunits = mist.makeUnitTable({'[red][vehicle]'})-- all red vehicles.
local blueunits = mist.makeUnitTable({'recon1'})  -- this is our recon aircraft

local Position_vec3 = Unit.getByName('recon1'):getPoint()
local _elevation = land.getHeight({x = Position_vec3.x, y = Position_vec3.z})
local _height = Position_vec3.y - _elevation
local _reconradius = math.sin(0.50) * _height --  with this snipet we get the instant height.
--trigger.action.outText(_reconradius,20)

local redunitsrec_insidezone = mist.getUnitsInMovingZones(redunits , blueunits, _reconradius , 'cylinder' )-- i am traying to get all units inside the _reconradius. This works fine... it gets the info

LOSData = mist.getUnitsLOS(blueunits,2,redunitsrec_insidezone,2,12000)-- now I want  to see which of the units in redunitsrec_insidezone are line of sight.       

   for k, v in pairs (LOSData) do -- This works, I have tested. 
       local tabledata = LOSData[k]
       for j, w in pairs (tabledata.vis)do            
           local targetinLOS = tabledata.vis[j]
           targets[#targets+1] = targetinLOS
       end
   end
trigger.action.outText(mist.utils.tableShow(targets),5)
end

Edited August 16, 2016 by ESAc_matador

[ESAc_matador]

never mind!!!

 

I solved with trigonometry... quite easy by the way. Since the radius of getUnitLOS is from the aircraft... i did this.

altitude.bmp

[sea2sky]

Question to MIST devs about teleportInZone. I've noticed groups that have waypoints (set in ME) become stationary after their 'teleportation' is done. Is that intended behavior? If yes - would it be possible to add an extra boolean parameter that would instruct the function to do a setTask with the original route once the group is spawned? Thanks!

[ESAc_matador]

problem is that after teleported, you miss all its orders. You can give orders via script after teleporting.

[sea2sky]

problem is that after teleported, you miss all its orders. You can give orders via script after teleporting.

 

Right, but it would be nice if done on a MIST level. Something like that might work:

 

function mist.teleportInZone(gpName, zone, disperse, maxDisp) -- groupName, zoneName or table of Zone Names, keepForm is a boolean

if type(gpName) == 'table' and gpName:getName() then

gpName = gpName:getName()

else

gpName = tostring(gpName)

end

 

if type(zone) == 'string' then

zone = trigger.misc.getZone(zone)

elseif type(zone) == 'table' and not zone.radius then

zone = trigger.misc.getZone(zone[math.random(1, #zone)])

end

 

local vars = {}

vars.gpName = gpName

vars.action = 'tele'

vars.point = zone.point

vars.radius = zone.radius

vars.disperse = disperse

vars.maxDisp = maxDisp

local newRoute = mist.getGroupRoute(gpName, 'task') -- getting the group's pre-existing route

local newGroup = mist.teleportToPoint(vars) -- teleporting to a new point just like before

mist.scheduleFunction(mist.goRoute, {newGroup, newRoute}, timer.getTime() + 5) -- sending the group over the old route

return newGroup

end

Edited August 17, 2016 by sea2sky

[ESAc_matador]

Exactly, just do an iteration with all groups getting the initial routes.

[Grimes]

The "teleportation" just spawns a new group due to the game not actually having a natural way to teleport stuff. I've never included the route for those functions because they are intended to randomize mostly static threats. It doesn't make a huge different to randomize the spawn only to follow the exact same route, especially when you can easily reassign said route with another function.

[ESAc_matador]

The "teleportation" just spawns a new group due to the game not actually having a natural way to teleport stuff. I've never included the route for those functions because they are intended to randomize mostly static threats. It doesn't make a huge different to randomize the spawn only to follow the exact same route, especially when you can easily reassign said route with another function.

 

Make sense.

 

I add grouptorandompoint for routes.

[chromium]

Grimes, it is possibile to remove the extra information like "table: 000000003974CAA0" from the table dump function? if so, what should I do? thanks!

[FSFIan]

Grimes, it is possibile to remove the extra information like "table: 000000003974CAA0" from the table dump function? if so, what should I do? thanks!

 

This page on the Lua wiki should have a serialization function that fits your needs:

 

http://lua-users.org/wiki/TableSerialization

[chromium]

Ian;2878103']This page on the Lua wiki should have a serialization function that fits your needs:

 

http://lua-users.org/wiki/TableSerialization

 

great, thanks!

[Stonehouse]

I'm having some trouble using mist.DBs.groupsById from mist 4.3.73

I'm doing

local grouptable = mist.DBs.groupsById but then the table returned is a table of tables looking like:

 

grouptable: {

[1] = table: 000000004C368030 {

[1]["country"] = "usa",

[1]["groupName"] = "D_FLAK_HI_06_001",

[1]["units"] = table: 0000000015C15B38 {

[1]["units"][1] = table: 0000000015C15AE8 {

[1]["units"][1]["heading"] = -3.038170561594,

[1]["units"][1]["point"] = table: 0000000015C15C18 {

[1]["units"][1]["point"]["y"] = 637200,

[1]["units"][1]["point"]["x"] = -289828.57142857,

},

[1]["units"][1]["groupId"] = 1,

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

[1]["units"][1]["coalition"] = "blue",

[1]["units"][1]["groupName"] = "D_FLAK_HI_06_001",

[1]["units"][1]["type"] = "AAV7",

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

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

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

[1]["units"][1]["category"] = "vehicle",

[1]["units"][1]["unitName"] = "Unit #1",

[1]["units"][1]["playerCanDrive"] = true,

[1]["units"][1]["country"] = "usa",

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

},

[1]["units"][2] = table: 0000000015C15D48 {

[1]["units"][2]["heading"] = -3.038170561594,

[1]["units"][2]["point"] = table: 0000000015C15DD8 {

[1]["units"][2]["point"]["y"] = 637200,

[1]["units"][2]["point"]["x"] = -289868.57142857,

},

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

[1]["units"][2]["y"] = 637200,

[1]["units"][2]["coalition"] = "blue",

[1]["units"][2]["groupName"] = "D_FLAK_HI_06_001",

[1]["units"][2]["type"] = "AAV7",

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

[1]["units"][2]["x"] = -289868.57142857,

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

[1]["units"][2]["category"] = "vehicle",

[1]["units"][2]["unitName"] = "Unit #001",

[1]["units"][2]["playerCanDrive"] = true,

[1]["units"][2]["country"] = "usa",

[1]["units"][2]["skill"] = "Average",

},

[1]["units"][3] = table: 0000000015C15C68 {

[1]["units"][3]["heading"] = -3.038170561594,

[1]["units"][3]["point"] = table: 0000000015C15B88 {

[1]["units"][3]["point"]["y"] = 637200,

[1]["units"][3]["point"]["x"] = -289908.57142857,

},

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

[1]["units"][3]["y"] = 637200,

[1]["units"][3]["coalition"] = "blue",

[1]["units"][3]["groupName"] = "D_FLAK_HI_06_001",

[1]["units"][3]["type"] = "AAV7",

[1]["units"][3]["countryId"] = 2,

[1]["units"][3]["x"] = -289908.57142857,

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

[1]["units"][3]["category"] = "vehicle",

[1]["units"][3]["unitName"] = "Unit #002",

[1]["units"][3]["playerCanDrive"] = true,

[1]["units"][3]["country"] = "usa",

[1]["units"][3]["skill"] = "Average",

},

},

[1]["coalition"] = "blue",

[1]["groupId"] = 1,

[1]["category"] = "vehicle",

[1]["countryId"] = 2,

[1]["startTime"] = 0,

[1]["task"] = "Ground Nothing",

[1]["hidden"] = false,

},

[2] = table: 0000000032ED7848 {

[2]["groupId"] = 2,

[2]["groupName"] = "E_FLAK_HI_06_001",

[2]["units"] = table: 0000000032ED78E8 {

[2]["units"][1] = table: 0000000032ED7898 {

[2]["units"][1]["type"] = "Dry-cargo ship-1",

[2]["units"][1]["point"] = table: 000000004D3EF6F0 {

[2]["units"][1]["point"]["y"] = 584650,

[2]["units"][1]["point"]["x"] = -315407.14285714,

},

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

[2]["units"][1]["y"] = 584650,

[2]["units"][1]["skill"] = "Average",

[2]["units"][1]["coalition"] = "blue",

 

where in the example DBs it looks like a simple table where each entry is a group:

 

groupsById =

{

[1] =

{

["modulation"] = 0,

["country"] = "usa",

["uncontrolled"] = false,

["groupId"] = 1,

["groupName"] = "AH-1s_1",

["units"] =

{

[1] =

{

["alt"] = 500,

["point"] =

{

["y"] = 631857.14285714,

["x"] = -297857.14285714,

}, -- end of ["point"]

["alt_type"] = "BARO",

["livery_id"] = "standard",

["onboard_num"] = "50",

["category"] = "helicopter",

["speed"] = 55.555555555556,

["type"] = "AH-1W",

["country"] = "usa",

["psi"] = -0.017389551289373,

["unitName"] = "AH-1s_1_1",

["groupName"] = "AH-1s_1",

 

Is there a bug with mist.DBs.groupsById? is the example table returned out of date? or much more likely have I done something wrong?

 

Thanks,

Stonehouse

Edited August 29, 2016 by Stonehouse
mist version

[Stonehouse]

Fiddled around some more with it, doing this:

for i = 1, #grouptable do

local groupelements = grouptable[i]

local Table3 = _mist.utils.tableShow(groupelements)

local msg1 = "groupelements: " .. Table3

trigger.action.outText(msg1, 60000000)

env.info(msg1)

 

Gave me a concatenation error for Table3 being nil but I still produced a listing of the first two groupelements table in dcs.log etc (only two groups of ground units one ships and one tanks) so doesn't that imply that there is one or more nil entries at the end of table grouptable aka the table built by mist.DBs.groupsById ?

 

Anyway the below avoided the error and got what I was trying to do working. Probably can do a pairs type loop instead but the below works. I guess I do want to know if the table returned from mist.DBs.groupsById is going to remain as it is now or not so I know how long my code will be good for.

 

for i = 1, #grouptable do

local groupelements = grouptable[i]

if groupelements then

local Table3 = _mist.utils.tableShow(groupelements)

local msg1 = "groupelements: " .. Table3

trigger.action.outText(msg1, 60000000)

env.info(msg1)

 

Thanks,

Stonehouse

Edited August 29, 2016 by Stonehouse

[Grimes]

Is there a bug with mist.DBs.groupsById? is the example table returned out of date? or much more likely have I done something wrong?

 

Its the your doing something wrong. Table show isn't a serialization function and fundamentally displays its contents in a much different way than the other functions. Its literally only meant for simple text output to see whats in it and to keep track of the contents. Mist uses something like the following to generate the DB tables...

 

mist.debug.writeData (mist.utils.serialize,{'groupsById', mist.DBs.groupsById}, 'mist.DBs.groupsById.lua')

 

So just replace tableShow with serialize to get the same format as the DBs.

 

 

Other than that use code wrappers when posting code on the forums, makes it much more readable, especially with a huge table of text like that.

 

do
   env.info('Hello World')
end

 

verses without the code tag.

 

do

env.info('Hello World')

end

[Stonehouse]

Sorry about the wall of text it did actually cross my mind after I posted it that it wasn't very readable apologies.

Thank you as always for your responses and help.

Edited August 30, 2016 by Stonehouse

[Stonehouse]

Sorry Grimes. The flu I have at present must be making me too stupid to understand. I tried the serialise as you suggested and as you said it would the table written to the file in the logs folder matches the example DB. It appears as a nice simple table where the high level group data is easily accessible. However I am confused then as to why I get a "attempt to index field "?" " error on the following concatenation line:

 

[color=black]local grouptable = _mist.DBs.groupsById[/color]
[color=black]for i = 1, #grouptable do[/color]
[color=black]  [b]local msg2 = "group name: " .. grouptable[i].groupName
[/b]   trigger.action.outText(msg2, 60000000)
   env.info(msg2)[/color]
[color=black]end[/color]

It does output the names of the two groups in the test mission but then bombs with the aforementioned error. Can you provide any clues or insight into why it fails after working ok for the two groups? Is it actually not just a nice simple numerically indexed table after all?

 

<edit> apologies the flu is really making me stupid. There are actually 4 groups in the test mission. 2 of aircraft and 1 vehicles and 1 ships. The vehicle and ship group are reported but the aircraft are not. However looking at the output of the serialise I can see that there are gaps in the index. So you get 1,2,5,6 as indexes. Not sure about 3 and 4 - are they groups that I have placed and then deleted and because the index is the group id and not just a numerical sequence this is the result? Therefore I can't really use #grouptable and must use a pairs for loop?

 

Thanks,

Stonehouse

Edited August 30, 2016 by Stonehouse

[Grimes]

<edit> apologies the flu is really making me stupid. There are actually 4 groups in the test mission. 2 of aircraft and 1 vehicles and 1 ships. The vehicle and ship group are reported but the aircraft are not. However looking at the output of the serialise I can see that there are gaps in the index. So you get 1,2,5,6 as indexes. Not sure about 3 and 4 - are they groups that I have placed and then deleted and because the index is the group id and not just a numerical sequence this is the result? Therefore I can't really use #grouptable and must use a pairs for loop?

 

If you create 10 groups and delete 9 of them, the groupId of the next group you place should be 11. It doesn't go back an fill in values.

 

Groups are indexed by number in the mist.DBs.units table. However they are nested a bit by [coa][country][category] first. Its generally a bad idea to iterate a table of unitId or groupId via number because there can be holes.

[Stonehouse]

Ok thanks. Got it all working using a pairs loop.

 

Cheers,

Stonehouse

[IAF.AssafB]

Can't control a group after mist.teleportInZone

 

Greetings,

I'm working on a mission where ground units are controllable via CA.

In order to simulate a river crossing, I've set up a trigger zone on the river bank, where a vehicle group can arrive, and be teleported to an adjacent zone on the other side of the river.

Problem is, after the group is teleported it can no longer be driven, but only accept changes to ROE , alert state etc'.

I've noticed that groups can be driven if spawned using the mist.respawnGroup and mist.cloneInZone functions.

Is there any way to maintain the group control after a mist.teleportInZone?

I'd also welcome any suggestions for other methods to mimic a river crossing (at least until ED implement any combat-engineering and bridging units…)

Thanks!

Assaf.

Edited September 16, 2016 by IAF.AssafB

[ESAc_matador]

Seems to be brok3n, because I have teleport ed many times and you can move them

[IAF.AssafB]

Seems to be brok3n, because I have teleport ed many times and you can move them

 

Thanks,

Assuming I know very (very!) little about scripting / programming - Is there hope for me to try repair / workaround it myself?

 

Assaf.