MIssion Scripting Tools (Mist)- enhancing mission scripting Lua

I'll look into it.

:cheer3nc:

mist.msgBRA
{
units = {gUnitNames},
ref = "Pilot #001",
displayTime = 10,
msgFor = {"Pilot #001"},
}

gUnitNames is already a table. By placing it in {} you are nesting it within another table. Remove the table identifiers and that should fix the issue.

Also message for needs to follow the message rules.

msgFor = {units = {"Pilot #001"}},

I'm in the process of fixing that other bug you showed with the optional text. Check for it on the development branch on gitub.

Hi Grimes,

I'm happy to be wrong and be told it's my lack of scripting skill in the GCICAP script at fault but it is starting to look like there is an issue with mist.getGroupData or perhaps something wrong in DCS that is sometimes causing getGroupData to return the wrong value. I had a report (http://forums.eagle.ru/showpost.php?p=2310757&postcount=396) that red template aircraft were chosen as Russian but spawning as Turkish.

The user uploaded their mission and I've done a debug run and found that the table returned from getGroupData is bringing back countryId = 3 which is Turkey as far as I know but checking the mission in the editor the red template aircraft are all Russian so I expected getGroupData to bring back countryId = 0. Funnily it seems to work ok for the blue side and you can see the country name returned is "russia" even though id =3

It may be my paranoia but Turkey is after Russia in the red coalition countries and the only other user of the particular airframes chosen in this mission. Could there be a bug somewhere in getGroupData or below in DCS that is looping through the countries for a given mission coalition for a particular aircraft and not getting a match on whatever the condition is and so returning the last country?

The relevant bit of the GCICAP code is lines 2684-2701:

cap_country is eventually passed to coalition.addGroup

debug entry in dcs.log:

The mission is available at the forum post link above and the issue seems to be 100% reproducible.

Thanks,

Stonehouse

Is there somewhere I can find documentation on the mist.DB's?

The main thing I want to find out is what functions are available to be used with these databases. for example in the code:

for _, u in pairs(mist.DBs.aliveUnits) do

unit_names[#unit_names+1] = u.unit:getName()

what attributes might u have and what other information can I get about the unit using something like :getName()?

The changelog for v3.0 references a mist.dbUpdate function but it no longer seems to be there. Is there any way that I can update a database without adding any units?

The DBs are just tables of data

The unit databases fall into 3 main categories.

1. ME prefix. These databases are static and won't ever be edited after the mission starts. Contains data directly from the mission file.

2. Standard DBs. Items are not removed, but if units are spawned into the mission the relevant DBs will be updated accordingly. Thus data can be overwritten if you teleport a group with the same names or Ids.

3. "Live" databases. Alive, dead, and dyn_add DBs. These get updated in real time as units are killed or spawned in via scripting engine.

The changelog for v3.0 references a mist.dbUpdate function but it no longer seems to be there. Is there any way that I can update a database without adding any units?

dbUpdate was changed to a local function to speed up the process of updating the DBs when new units were added. Thats all it was used for.

what attributes might u have and what other information can I get about the unit using something like :getName()?

Any unit member function should work with it.

http://wiki.hoggit.us/view/Part_2#Unit

@Stonehouse, I was out of town for a few days. I'll have a look at it.

Thanks Grimes!

Not sure if this is a bug, but if I try to access any of the realtime databases using witchcraft, DCS slow down to 1fps and witchcraft never gets a response.

Not sure if this is a bug, but if I try to access any of the realtime databases using witchcraft, DCS slow down to 1fps and witchcraft never gets a response.

Please clarify what you mean by "access" and provide exact steps to reproduce.

I have dumped _G with witchcraft before ("return mist.utils.tableShow(_G)"), which of course implicitly accesses the real-time DBs. If you request a lot of data, it is normal for DCS to slow down (freeze) while witchcraft is serializing all that data to JSON to send to the browser. For a complete _G dump, that can take one or two minutes, but there will eventually be a response.

(And then it takes a while for your browser to actually render that data, but at that point, DCS should be back to normal.)

try: return mist.DBs.aliveUnits.

After doing this I've waited for 10 minutes and dcs never speeds back up. I'm very new to lua and how lua is setup in DCS so I'm not really sure what _G, JSON, etc. are.

Nick, Ian shows the correct technique for returning and displaying LUA table *in the Witchcraft LUA console*. mist.utils.tableShow(table)

*As I understand it your question is more about Witchcraft LUA console than MIST but MIST provides a good solution AND DCS Witchcraft Thread is STILL not stickied so ...*

In the DCS Witchcraft console you can "return" a string, number or a boolean but to return a table you need to write your own function OR use one that is already written like mist.utils.tableShow

*Thanks Ian for providing a great explanation of the JSON properties that cause the behavior. I learn stuff around here.*

You will use this a LOT.

*Nick you should also make a new thread. This thread is for MIST announcements and support.*

It helps to understand the context of how you are using a function.

I was able to reproduce it here.

Before sending it to the browser, the result of a Lua snippet is encoded in JSON format (see json.org). The problem is that the unit DB has numeric keys, and the only way to represent those in JSON is with an array, so you end up with an array with lots of null entries. The resulting JSON string is so huge (JSON-encoded mist.DBs.aliveUnits is about 14x larger than the result of mist.utils.tableShow(_G)!) that witchcraft simply chokes on it. I could not find out why exactly, but I assume there are a few algorithms behind all the string handling that run in at least O(n^2).

Workaround:

return mist.utils.tableShow(mist.DBs.aliveUnits)

This uses MiST's own serialization function which actually knows how to properly serialize Lua objects.

In the DCS Witchcraft console you can "return" a string, number or a boolean but to return a table you need to write your own function OR use one that is already written like mist.utils.tableShow

Returning objects works, too, as long as the object can be represented as JSON, which will work in most simple cases.

The following things cannot be represented in JSON and require the use of mist.utils.tableShow or similar:

• tables that have both string and numeric keys
  
• functions
  
• userdata
  

For tables with numeric keys which are not consecutive (i.e. mist.DBs.aliveUnits), mist.utils.tableShow is strongly recommended.

By the way, _G is a special variable that represents the "global environment". It includes everything your script has access to. If you have not already, try "return mist.utils.tableShow(_G)", wait half a minute and be amazed :)

Thanks Vicx. I can't believe I missed that function, that makes things much simpler.

I'm hoping to make a script that can track the status of MP clients (e.g. in cockpit, in slot but not yet loaded into cockpit, dead, etc.) does anyone have any advice on how a script can ascertain this information?

P.S. Sorry to be coming to you guys with what I'm sure are trivial questions, I'm just trying to get started and the documentation is a little sparse.

It may be my paranoia but Turkey is after Russia in the red coalition countries and the only other user of the particular airframes chosen in this mission. Could there be a bug somewhere in getGroupData or below in DCS that is looping through the countries for a given mission coalition for a particular aircraft and not getting a match on whatever the condition is and so returning the last country?

Update the mission to run with Mist 3.5.37. The mission basically needs the hotfix 3 in order to work correctly because that version specifically fixed that bug.

Next release I'm going back to having the version number in the mist file name so it is easier to keep track of it.

I'm hoping to make a script that can track the status of MP clients (e.g. in cockpit, in slot but not yet loaded into cockpit, dead, etc.) does anyone have any advice on how a script can ascertain this information?

Well that falls partly into the 'net' lua environment which runs outside of the 'mission' lua environment. Within mission we can see if a specific aircraft is alive or dead, and we could get the clients name for whoever is in that aircraft. But it can't see if a player has connected, joined a slot but hasn't spawned, or disconnected from the server. Those capabilities are strictly available within the net lua environment which is a whole separate beast.

To get the data that you can within mission scripting it is pretty straight forward and as simple as this:

local alivePlayers = {}
for name, data in pairs(mist.DBs.humansByName) do
if Unit.getByName(name) and Unit.getByName(name):isActive() then
	alivePlayers[name] = data
	alivePlayers[name].playerName = Unit.getByName(name):getPlayerName()
end
end

Doh sorry Grimes I should have checked the Mist version before posting but yes definitely easier when the file name gives the info rather than having to actually open it to see. Thanks for looking at it. Apologies for taking a chunk of your day without real cause.

Cheers,

Stonehouse

When using respawnGroup the unit keeps getting spawned about 3000m higher than it was before. Has anyone else experienced this?

What type of unit is it? I tried to do it with an A-10, but I couldn't reproduce it. Can you post a mission file where the bug occurs?

I had it happening in this mission for both the AI and the player.

headontrain.miz

The altitude type is accidentally getting switched to radio instead of baro. The fix is up on the development branch on github.

I had tested it over a relatively flat part of the terrain where AGL and MSL have the same basic value. In the mountains, like in your mission, these two values are vastly different.

Thanks for the quick fix! Works perfectly. One other minor issure that I just noticed is that if a plane is respawned more than once it loses it's assigned initial speed. In my case the flanker will have an IAS of 800kmh initially and after the first respawn, but after the second respawn it will have an IAS of 350kmh. Maybe it's best to explicitly assign a route each time rather than just tell the respawn function to clone the initial route?

Mist 3.6 released

https://github.com/mrSkortch/MissionScriptingTools/releases/latest

I have re-added the mist file with a version number. It should be what you see when you download the files.

Bunch of Fixes

-Teleport To Point related functions now check the altitude of a given point if specified for teleporting aircraft

-fixed bug with mist.flagFunc.group_alive_less_than and mist.flagFunc.group_alive_more_than

-fixed bug with optional variables for coordinate messages not actually being optional

-added mist.getRandomPointInZone. Function uses mist.getRandomPointInCircle.

-fixed bug with altitude switching to radio if baro was specified

-added the speed to DBs if a unit is dynamically spawned in

-added extra checks in case Group/Unit.getByName returns dead objects

Mission file searching functions now search by Id instead of group or unit names.

The name input variable hasnt changed, value gets converted to Id automatically if found.

Functions now also accept a numerical groupId or unitId

getPayload

getGroupPayload

getGroupPoints

getGroupRoute

DB files were not updated as the contents didnt change.

I was going to make some sizable changes to how messages are handled, but I think I'll save it for "mistv4" which will coincide with DCS 2.0.

Hi Grimes,

I'm finding that the current release version of CAPGCI is having problems with 3.6.42 and the symptom is that CAP and GCI aircraft are not spawning. I've not had time to analyse and debug things to find the root cause yet (my hunch is getPayload but it is just a hunch) but wanted to ask if you had the expectation that your changes in 3.6.42 were backward compatible or that we definitely needed to make changes to/review our scripts to ensure they comply with Mist going forward?

Thanks,

Stonehouse