MIssion Scripting Tools (Mist)- enhancing mission scripting Lua

Yes it is backwards compatible. All the change does is search for the groupId or unitId corresponding to the group/unit name passed and then use the Id to return the data from the mission file.

Ok thanks. Work is pretty crazy at present so it'll probably be a few days before I get any real time to investigate but will let you know how it goes. Hoping it is my end of things but basically just changing versions of Mist initiated the problem and reverting to 3.5.27 made the problem go away so logically it seems that Mist 3.6.42 is somehow the cause.

Thanks,

Stonehouse

Hi Grimes,

Managed to find half an hour while waiting for dinner to cook which wasn't expected. Put a debug line directly before the call to mist.getPayload and one directly after. The one before turned up in the log but not the one after so it seems it is calling the mist function but not returning. Do I need to change the syntax for my call to mist.getPayload when using the new version?

My call is like the below and hasn't changed for months since using late activation aircraft as templates was implemented. The value of interceptorside will be blue or red and give you a string like "__GCI__blue1" and on the template aircraft this is the unit name. This works fine with 3.5.37.

local RandomInterceptor = math.random(1,4)

 

--template logic >>

local bluegcitemplate = "__GCI__"..interceptorside..RandomInterceptor

 

if debuggingmessages == true and (interceptorside == debuggingside or debuggingside == 'both') and (funnum == 0 or funnum == 3) then

Debug("bluegcitemplate = "..bluegcitemplate,interceptorside)

end

payloadtable = mist.getPayload(bluegcitemplate)

Stonehouse

I noticed a minor bug: The boolean option to avoid roads doesn't not appear to work for groupToRandomZone. They always use the road.

Hi Grimes,

Was working from home today and had a VPN outage so while waiting for it to get fixed I had a go at finding the problem with getPayload. I ended up with the following code which seems to work for me with GCICAP and flights are now spawning and taking off with different payloads as per the template aircraft. GCICAP calls the function using the unit name so I have not tested how this will work with passing the unit id instead but think it will be ok. Anyway hope it helps you somewhat.

mist.getPayload = function(unitIdent)

-- refactor to search by groupId and allow unitId and unitName as inputs

local unitId = unitIdent

if type(unitIdent) == 'string' and not tonumber(unitIdent) then

unitId = mist.DBs.MEunitsByName[unitIdent].unitId

unitName = unitIdent

else --unit id passed in so only need to get unit name

unitName=mist.DBs.MEunitsById[unitId].unitName

end

 

local gpId = mist.DBs.MEunitsById[unitId].groupId

 

if unitName and type(unitName) == 'string' then

for coa_name, coa_data in pairs(env.mission.coalition) do

if (coa_name == 'red' or coa_name == 'blue') and type(coa_data) == 'table' then

if coa_data.country then --there is a country table

for cntry_id, cntry_data in pairs(coa_data.country) do

for obj_type_name, obj_type_data in pairs(cntry_data) do

if obj_type_name == "helicopter" or obj_type_name == "ship" or obj_type_name == "plane" or obj_type_name == "vehicle" then -- only these types have points

if ((type(obj_type_data) == 'table') and obj_type_data.group and (type(obj_type_data.group) == 'table') and (#obj_type_data.group > 0)) then --there's a group!

for group_num, group_data in pairs(obj_type_data.group) do

if group_data and group_data.groupId == gpId then

for unitIndex, unitData in pairs(group_data.units) do --group index

if unitData.unitId == unitId then

return unitData.payload

end

end

end

end

end

end

end

end

end

end

end

else

env.info('mist.getPayload got ' .. type(unitName))

return false

end

env.info('mist.getPayload, payload not found')

return

end

<edit> Just clarifying that the above was meant as me trying to be helpful and not anything else and I guess my point with the above work is that the getPayload function appears to have a bug in 3.6.42 and that passing it the unit name no longer works or at least no longer works as it did in 3.5.37. As far as I can tell the function does not return from being called. Honestly hope it is helpful to you Grimes. If you need me to test or supply more info very happy to.

quick one -

According to the documentation and to the MIST lua script, cloneGroup and respawnGroup should return a table of the group that is being created.

When I tried it, it returns nil, anyone have any ideas?

simple test -

local nGroup = mist.cloneGroup("SU-27",1)
trigger.action.outText(mist.utils.tableShow(nGroup), 10)

Thanks in advance.

EDIT - NVM, looks like in line 699 of the latest build, in dynAdd function it tries to -

return newGroup.name

changing it to -

return newGroup

will fix it.

Yeah I screwed up on the getPayload function. I thought I had tested it via use of other functions, but it turns out those functions used getGroupPayload instead. Which brings me to xcom's issue in that things get a little broken if you just change one value, especially when functions call and rely on the returned value of other functions.

Fixes are up on github.

Thank you! Will grab the new version and give it a go. I know exactly what you mean about common functions. I've got a common pension calc module at work that I am changing and the change is pretty simple but you wouldn't believe the resulting test scope. Sort of 1.5 day build and unit test = 20-30 days system and acceptance testing.

Sorry Grimes there still seems to be a problem with getPayload. With 3.6.43 I now see the aircraft spawn but they don't move they just sit there. I saw something similar when the template aircraft were set with 0 fuel so my guess is that calls to getPayload now return control back to the GCICAP script but are not returning the actual payload info.

I've attached two copies of the same mission so you can see what I mean - it's my test bed mission for GCICAP.

The only difference is that I've changed the version of Mist from 3.5.37 to 3.6.43 in the second one. The 3.5.37 one works fine but the other is as described above.

<edit> getting reports from users that the flak script gets broken by the latest version as well. Not sure what function is involved and will have to do some digging and report back.

<update> testing with 3.6.43 shows that the flak script is fine. User reports are due to timing - they were using 3.6.42 and that one did have issues when running the flak script. 3.6.43 is ok for the flak script and just the GCICAP script still has problems

CAPGCI Mist 3537.miz

CAPGCI Mist 3643.miz

addEventHandler appears to be missing the line that returns an id number. Is there a different way that I am supposed to get this number to be used with removeEventHandler?

Also teleportToPoint is attempting to access a nonexistent object called terrain.

@Stonehouse check dev branch on github. It should work, but I'm holding off on patching for now to get confirmation on your end. Admittedly it is kind of strange that the animations of the engine were running, but obviously they didn't have fuel. I suspect that is a factor of starting on the runway.

addEventHandler appears to be missing the line that returns an id number. Is there a different way that I am supposed to get this number to be used with removeEventHandler?

No, it was an omission that seemed to exist since the first release of mist somehow. Goes to show how often I tried to remove an event with mist. :music_whistling:

Also teleportToPoint is attempting to access a nonexistent object called terrain.

Fixed.

Hi Grimes,

Initial quick tests are looking good. The aircraft spawn in much quicker than with 3.6.43 and right away you can see different stores (eg drop tanks) are appearing on planes as well. So I think it looks ok now but will do some more tests this evening and post up an all clear or not tomorrow morning.

Thanks,

Stonehouse

Grimes, would it be possible to add to mist.dynAdd the option to clone client planes?

I added the following lines and they seem to work, but there's definitely better ways to do it -

Line 631:

if not unitData.skill then 
newGroup.units[unitIndex].skill = 'Random'
[b]elseif unitData.skill == 'Client' and newGroup.clone then
newGroup.units[unitIndex].skill = 'Random'[/b]
end

As far as I can tell the getPayload function seems to work fine now.

Cheers,

Stonehouse

Grimes, would it be possible to add to mist.dynAdd the option to clone client planes?

I added the following lines and they seem to work, but there's definitely better ways to do it -

 

Line 631:

if not unitData.skill then 
newGroup.units[unitIndex].skill = 'Random'
[b]elseif unitData.skill == 'Client' and newGroup.clone then
newGroup.units[unitIndex].skill = 'Random'[/b]
end

You can just change the skill level for the group before using mist.dynAdd.

local clientGroup = mist.getGroupData('clientGroupx')
for i = 1, #clientGroup.units do
clientGroup.units[i].skill = 'Random'
end
clientGroup.clone = true
mist.dynAdd(clientGroup)

Yes, but I'm using it this way with clonegroup which is easier as I don't have to input all the other data.

I guess there's no REAL necessity for it, just a shortcut.

anyone getting crazy lag with

if not Group.getByName('groupName') then

mist.respawnGroup('groupName', true)

end

There has always been some pause whenever a group spawns in. Usually though it is caused from having to load the model and textures, especially if those objects and textures aren't already active on the map and therefore in your ram. For instance running the clone script has a jitter when its first used, but if you clone the same group again there is virtually no pause.

I guess the question is what type of object you are respawning?

There has always been some pause whenever a group spawns in. Usually though it is caused from having to load the model and textures, especially if those objects and textures aren't already active on the map and therefore in your ram. For instance running the clone script has a jitter when its first used, but if you clone the same group again there is virtually no pause.

 

I guess the question is what type of object you are respawning?

This is an interesting information

I have a problem with MIST 3.6. Whenever I use the teleport command to teleport a unit into a zone (mist.teleportInZone), in the debriefing screen the teleported units are somehow renamed and loose their nationality, so they are not counted for points. What am I doing wrong? Thanks for answers. The debriefing screen looks like this:

I have a problem with MIST 3.6. Whenever I use the teleport command to teleport a unit into a zone (mist.teleportInZone), in the debriefing screen the teleported units are somehow renamed and loose their nationality, so they are not counted for points. What am I doing wrong? Thanks for answers. The debriefing screen looks like this:

You aren't doing anything wrong. Dynamically spawned objects do not show correctly on the debrief screen, its a game bug.

You aren't doing anything wrong. Dynamically spawned objects do not show correctly on the debrief screen, its a game bug.

Thank you very much for your answer and keep up the good job with MIST :) I hope it gets sorted sometime in the future.

I have an issue and some questions about the function "mist.ground.patrol('myGroup', nil, 'diamond', 10)"

1. What other formations are there except 'diamond'?

2. Is nil an accepted value to send as formation e.g. mist.ground.patrol('myGroup', nil, nil, 10)?

3. It seems mist.ground.patrol('myGroup', 'doubleBack') is working as intended, but

mist.ground.patrol('myGroup', nil, 'diamond', 10) is causing unexpected behaviour. Seems like the unit is sometimes skipping waypoints and sometimes only going halfway to e.g. wpt3 and then keeps going to wpt4.

What is "best practice" use of this function? I've tried putting the function call in the "mission start" event and in the last and first waypoints as waypoint actions. Regardless of where from the function is called, it seems to end up with unexpected movement patterns.

Is the function broken in the latest (non beta) version of DCS World or am I implementing it wrong? Anyone know?

what would be the best way to get a random point in a polygon or along a line?