Lua - Export Mission Details | Briefing

[Spotterday]

Is there the possibility to export the mission details via Lua. [Example Description Missionname and so on].

 

Background

 

Want it on a server where a mission is launched - can this information [such as mission briefing aircraft number, etc.] lead to a TCP port and tap on a Web site

 

 

Problem

 

Find anywhere any informations about a function or something like that do get mission details ... of an running mission !

[Speed]

Sure, what details do you need?

 

Now, I don't do Luasocket, which is the Lua module you'll need (and is already included with the game) to export data over TCP/UDP, but I have a pretty good idea of how to get started with it though. You can always get working programming examples from working mods that use Luasocket, and there are some examples ED has done too, somewhere. I've just never needed to do Luasocket for any mods myself.

 

Now getting the mission data itself is pretty easy, there are multiple ways I can think of right off hand-

 

First off,

 

"mission" table - a Lua table containing all the mission's triggers, units, waypoints, loadouts, weather settings, options, bullseyes, briefing text, etc. A Lua table is an associative array- it's an object in your computer's memory (RAM).

 

"mission" file - a text file of the mission table in a serialized form (serialized == converted to a string in Lua syntax so that a future loadstring call on that string will create a function that re-creates the table).

 

.miz file - a zipped archive containing the "mission" file, plus any other sounds/pictures/various scripts that might be included with the mission

 

Anyway, net.dostring_in (a "net" environment function) can access the "mission" environment, where the "mission" table is (with the triggers compiled as well). You can return whatever data you want from the "mission" environment to the net environment, after which you can send that data where ever you want with Luasocket.

 

Also, the debriefing module in the "server" aka "main simulation" environment has a function that is passed the mission file (as a string),; you can potentially make a modification to this function to store whatever information you need (which is what I did in the "Radio Patch" mod).

 

Finally, any unsecured Lua environment in DCS has the lfs (Lua File System) module, and with the lfs module you can create a function that is able to deduce which file in C:\Users\<user name>\AppData\Local\Temp\DCS Warthog is the real mission file. The following is some Lua code I wrote to do just that:

 

 

Getting the unzipped mission file in Lua (hopefully that might help trigger the search engine on future forum searches on the same subject).

 

function GetUnzippedMission(t_window)

t_window = t_window or 3600 -- default: if t_window not specified, look at all files newer than 1 hour.

local run_t = os.time()
local mis_path, mis_t
local path =  lfs.tempdir()

for file in lfs.dir(path) do
	if file and file:sub(1,1) == '~' then
		local fpath = path .. '/' .. file
		local mod_t = lfs.attributes(fpath, 'modification')
		if mod_t and math.abs(run_t - mod_t) <= t_window then
			local f = io.open(fpath, 'r')
			if f then
				local fline = f:read()
				if fline and fline:sub(1,7) == 'mission' and (not mis_t or mod_t > mis_t) then -- found an unzipped mission file, and either none was found before or this is the most recent
					mis_t = mod_t
					mis_path = fpath
				end
				f:close()
			end
		end
	end	
end

if mis_path then -- a mission file was found
	local f = io.open(mis_path, 'r')
	if f then
		local mission = f:read('*all')
		f:close()
		return mission
	end
end	
end

 

t_window is the time search window... basically, there are a lot of files in the C:\Users\<user name>\AppData\Local\Temp\DCS Warthog folder, and some of them can be very large. To avoid opening lots of huge files, and causing a noticeable pause, t_search allows you to narrow the search to files that were only modified in the last t_window seconds. It defaults to the last hour.

 

Still, even with t_window, one should use this function sparingly.

 

Also note: In the net, main simulation, and export Lua environments (probably config environment too but who cares about that one), lfs.tempdir() returns the temp directory path, which is C:\Users\<user name>\AppData\Local\Temp\DCS Warthog. If you're going to use this outside of DCS's Lua, you'll need to change the local path variable to explicitly be C:\Users\<user name>\AppData\Local\Temp\DCS Warthog.

 

Anyway, I haven't really tested this function much more than a dozen or so times, under similar conditions, but it's simple enough. There may be some ways to further optimize it... for one, maybe I should match the first part of the file name to "~m" rather than just "~"- I think whatever random temp naming system they are using for file names is always going to give the mission file a "~m......" name, but I'm not 100% sure on that. One might also notice I do end up opening the same file twice, but the first time, I just carefully look at the first line to try to determine if it's a mission file. I didn't want to go about reading more if it's some 100MB behemoth track file. I suppose I could do a read('*all') after that though, if the first seven characters match "mission", and avoid having to reopen the same file, but whatever- that's not the point of this example.

 

Damn though, life would have been so much easier if they had just left the name of the unzipped mission file as "mission", like it was in A-10C beta 1 through beta 4.

 

 

[Spotterday]

Hey Speed thx for Replay.

Yea that is it " "mission" table - a Lua table containing all the mission's triggers, units, waypoints, loadouts, weather settings, options, bullseyes, briefing text, etc. A Lua table is an associative array- it's an object in your computer's memory (RAM). "

Do you have some Script sniped ? I mean the export to udp or tcp is not so difficult. But i want to reduce the cpu load for unpack the miz files or something else. I want grap it directly from ram or something like that. I mean your sniped unzip some miz file and that is "cpu lazi". Please you search for that mission" table - a Lua table containing :D

[Speed]

Hey Speed thx for Replay.

Yea that is it " "mission" table - a Lua table containing all the mission's triggers, units, waypoints, loadouts, weather settings, options, bullseyes, briefing text, etc. A Lua table is an associative array- it's an object in your computer's memory (RAM). "

Do you have some Script sniped ? I mean the export to udp or tcp is not so difficult. But i want to reduce the cpu load for unpack the miz files or something else. I want grap it directly from ram or something like that. I mean your sniped unzip some miz file and that is "cpu lazi". Please you search for that mission" table - a Lua table containing :D

 

The script I posted doesn't unzip anything, it only opens files that are already unzipped. It is a decent option for getting the mission file from just about any Lua environment, when computation time is not a concern (such as, when you are opening a mission, computation time is not really a concern- if running this script causes it to take an extra 300ms to open a mission, no one is really going to notice or care). The script I linked is also a good option for getting a mission file that includes the triggers in a string format- as the actual mission table, in the mission environment, has the trigger conditions and actions compiled into functions, and thus you can't inspect what's really going on in them.

 

Like I said, to get the mission table through memory, you need to either modify debriefing.lua to save a mission table in the main simulation environment and export it from there, or use net.dostring_in to bring the data from the mission environment into the net environment, where it can be exported.

 

If you're worrying about wasting CPU cycles, why are you trying to bring in the whole mission table? It can be very huge. Why not just grab the parts that you need?

 

Also, if you're going to serializing the mission table, you need to be aware that the mission table utilizes cycles- table references to other tables that contain references back to the original table. So many/most serialization functions will enter an infinite loop when attempting to serialize the mission table. The table serialization function I use in Slmod for the serialization of tables that may contain cycles is shown below. It's mostly out of Programming in Lua, but I think I made a modification to the string concatenation to enter the strings I want to concatenate into a table and then run table.concat on that table when I'm done (which makes a HUGE difference for very long strings- for very long strings, the standard Lua string concatenation operator is MASSIVELY inefficient):

--mostly straight out of Programming in Lua
function serialize_wcycles(name, value, saved)
local basicSerialize = function (o)
	if type(o) == "number" then
		return tostring(o)
	elseif type(o) == "boolean" then
		return tostring(o)
	elseif type(o) == "string" then
		return string.format("%q", o)
	end
end

local t_str = {}
saved = saved or {}       -- initial value
if ((type(value) == 'string') or (type(value) == 'number') or (type(value) == 'table') or (type(value) == 'boolean')) then
	table.insert(t_str, name .. " = ")
	if type(value) == "number" or type(value) == "string" or type(value) == "boolean" then
		table.insert(t_str, basicSerialize(value) ..  "\n")
	else

		if saved[value] then    -- value already saved?
			table.insert(t_str, saved[value] .. "\n")
		else
			saved[value] = name   -- save name for next time
			table.insert(t_str, "{}\n")
			for k,v in pairs(value) do      -- save its fields
				local fieldname = string.format("%s[%s]", name, basicSerialize(k))
				table.insert(t_str, serialize_wcycles(fieldname, v, saved))
			end
		end
	end
	return table.concat(t_str)
else
	return ""
end
end

 

Anyway, come to think of it, if you take the main simulation, modify debriefing.lua approach, you don't need to do table serialization at all. You merely need to save the relevant data within the relevant function in the debriefing module. More specifically, the debriefing module is in ./Scripts/UI/debriefing.lua. Modify the updateMissionData function, which is passed the missionStr (mission string, from the mission file) at the start of every mission, to save the missionStr variable to the global environment. Or, if you prefer a mission table, over a string then save the env.mission local variable that is created.

 

Edit: Modified the serialization function, I just realized I left a "safestring" call in there. I replaced it.

Edited April 26, 2012 by Speed