Sean B.

If you say so. Good luck.

What is "A"? Everything I mentioned will work for MP missions. Mission commands are ones you create in the F10 menu. Chat commands are ones players type into the chat.

Without any script needing to be downloaded/installed by the client to enable the functionality, you're pretty much limited to deep nested mission commands, or chat commands. If you want to advertise a "better experience" with a link to download scripts in your mission briefing, then you have plenty of options.

Ah, gotcha. You could always try an force your way by using Controller.knowTarget(). I'm not sure if it overrides a target being invisible, but it might. Mission builders may not appreciate it though hah. Best of luck! P.S.: Not sure why I didn't think of this in my last post, but luasocket would be an easy option for getting information from either the hooks or export env's as well.

It may be more of a pain to access that table than it's worth for you, as the unit object table isn't accessible from the mission environment. There would be 2 ways to get the value of that invisible variable: One would be via the io package, using temp files to read/write info back and forth from/to either the hooks or export env. This wouldn't be difficult, and would be fine if the mission will only be run on a dedicated server instance. But it makes the mission non-portable sense, by default, the io package is sanitized from access by the mission env on client installations. The other would be to have a hooks script monitor a specific user flag that, when populated with the object ID of a unit ( NOT the unit ID ) by the mission env, gets the table from Export.LoGetObjectByID(ID), and send a true/false result back to the mission via a different user flag. In either case, access to LoGetObjectByID is dependent on the server export settings. Unless something about your mission prevents it, I would suggest setting the units to invisible via scripting ( as opposed to selecting the option on the units in the ME ). This would allow you to keep track of what units have been set invisible simply by setting their ID's into a table when you set them invisible, then reference that table later as needed.

My apologies if this has already been discussed, I attempted to search the forums but got a mile long list just using "export" as a keyword and no results trying to narrow it down. The apparent convention for loading export scripts in DCS is to use WriteDir\Scripts\Export.lua as a communal loader. Various sources ( Tacview, SRS, LotATC etc ) all add a line to load their specific export script into the export environment.. local Tacviewlfs=require('lfs');dofile(Tacviewlfs.writedir()..'Scripts/TacviewGameExport.lua') local TheWayLfs=require('lfs'); dofile(TheWayLfs.writedir()..'Scripts/TheWay.lua') pcall(function() local dcsSr=require('lfs');dofile(dcsSr.writedir()..[[Mods\Services\DCS-SRS\Scripts\DCS-SimpleRadioStandalone.lua]]); end,nil) The code loaded for Tacview, TacviewGameExport.lua, implies that the scripts loaded by Export.lua are loaded sequentially into the same environment ( IE: all sharing the same global space ), rather than having loading functions that provide a sandboxed copy of the export environment for each load. do local PrevLuaExportStart=LuaExportStart; LuaExportStart=function() tacview.ExportStart() if PrevLuaExportStart then PrevLuaExportStart(); end end end Prior to creating its own LuaExportStart function it saves the variable locally. Then at the end of its own code, upon a previous version existence returning true, executes the previous code. This "daisy chaining" of export scripts into the same global space, while risky and completely reliant on creators of these scripts to pay close attention on not trampling others ( in start, stop, and the coroutine table ), does work. Except, from what I can see, for one export function.. function LuaExportActivityNextEvent(t) local tNext = t -- Put your event code here and increase tNext for the next event -- so this function will be called automatically at your custom -- model times. -- If tNext == t then the activity will be terminated. tNext = tNext + 1.0 This function appears to be the analog to timer.scheduleFunction() in the mission environment. The timer will repeat based on the returned time value from the function it executes. A function that relies on context based return values cannot be daisy chained as described above. Scenario: Scripts 1 creates this function with a +1 return value, then script 2 wraps function 1 with a +5 return, and finally script 3 wraps function 2 with a +10 return. All functions will execute as essentially one chunk at the +10 frequency returned by script 3. Causing anything time sensitive from scripts 1 and 2 to fall behind, or fail completely. Am I missing something? Is there another way to go about this, or is this an oversight in the API? I see no way to return time values for multiple contexts via the one function call. And yes, I'm aware I could use LuaExportAfterNextFrame(), as many do. However, that would be orders of magnitude faster than I need, creating an egregious amount of unnecessary network traffic adding latency to the queue. If needed I can create a global variable counter and only send traffic once the counter reaches a certain value, but the above function is perfectly suited to my task, if it doesn't risk collision with others.

My bad. Too many "invisible"'s to choose from. The Flags table of the unit object table provided in the export environment has it: Flags = { RadarActive = true if the unit has its radar on Human = true if the unit is human-controlled Jamming = true if the unit uses EMI jamming IRJamming = -- same for IR jamming Born = true if the unit is born (activated) AI_ON = true if the unit's AI is active Invisible = true if the unit is invisible <<--------*******----- Static - true if the unit is a static object }

DCS.getUnitProperty(unitID, DCS.UNIT_INVISIBLE_MAP_ICON) or DCS.UNIT_HIDDEN, depending on which invisible you're referring to, from the server env ( hooks ).

env.getMissionName() from the mission environment will return the full path and filename of the mission ( IE: C:\user\name\saved games\DCS.openbeta\Missions\mymission.miz ).

Add center point and angle as values to the param table of world.VolumeType.BOX when used with world.searchObjects. This would allow for the volume to be rotated the same as a quad point box in the GUI, allowing for precise detection in relation to map objects ( such as a runway ).

Not sure if this is a bug or an oversight: trigger.misc.getZone("NAME") , where NAME is the name of a quad point trigger zone, only returns the vec3 for the center of the zone along with a radius value ( like it was a circular zone ), not the vertices table for the 4 corner points of the quad. The vertices can be found from the simulator side under _current_mission.mission.triggers.zones[x].vertices , but I cannot find them accessible anywhere from the scripting side.