Grimes

The old bug of Group.getByName returning dead groups is back in addition to isExist() also returning true on the dead group. I updated mist to adjust for this bug. 

IT
IS
A
WIKI!
They have disabled account creation because it is often a target of spam, but accounts can still be done by someone with admin access on it. All you have to do is ask. People make comments about this or that being missing*, very few of them actually ask for an account to contribute to the greater good, and even fewer actually make edits. 
 
* 95% of the time it is generalities of things missing and not specific examples. If someone links to a wiki page when asking a question or I myself am doing something with scripting and notice the page could use more details then I try to fix it. 

Me being weird I don't like using world.searchObjects for getting a list of objects in an area, especially if that area is larger than a few km radius. However that mostly stems from the very noticeable hitch that can occur when searching for world objects over a densely populated area if the search area is large enough. 
The other way would be to iterate a table of known units, see if they exist, and get the distance from a given point. Depending on your needs you can vary the speed. For example the bubble script on Grayflag has a curated list of units and weapons that it tracks. Objects get added and removed via event handler. It only runs getPosition on each object every few seconds, which means its not ultra precise, but it is precise enough. Each bubble, think of it like a trigger zone typically around sams, will check its distance against the known object list. Depending on that distance it'll reschedule the check to occur slower or faster because the point is to allow a sam to "exist" in the mission by only spawning it in when aircraft are near. Anyway if the bubble is spawning in a short range sam and the nearest unit is 100km away it doesn't exactly need to update at a faster rate just to know the nearest unit is now 99.4 km away.
 
But no I haven't benchmarked it. I suppose it is a question of the distances involved and what information you care about. world.searchObjects on units will return all units, you'd have to sort for coalition and category if that mattered. Whereas if you only want to know which of 10 helicopters are in a zone it'll probably be faster to check the distance with a for loop and adding them to an table of in zone units. 

Right now they are two very different systems in several respects. You can't modify drawings from the editor via scripting, but you have access to their information. However the scripting engine doesn't have the same parameters as what is available in the editor. The two main ones being that line types are not the same and line thickness is not available in scripting. There are several other differences in the form of format, but those can be worked around. Namely:
Scripting color format is {r, g, b, a} in values 0 to 1 while editor is in hex Points for drawings are stored relative to the first point with a mapX and mapY value defining the offset of that first point from map origin Angle of a drawing is often its own value, so similar to mapX and mapY it will offset any points based on that value. Oval and rectangle in drawings are defined as mathematical shapes. In other words a rectangle is height and width instead of being 4 points.  Arrow in the editor is a set of points making up a polygon while the scripting arrow is just between two points.  Easiest would be to use the editor to get the drawing information but actually add the shape via scripting, then changing it however you see fit via scripting again. Might even be easier to use a group's route to define the points and just call trigger.action.markupToAll with the valid parameters. 

Sorry I didn't really answer with full information before... I had just finished a rather intense ARMA mp mission :)
 

In the inner workings of the sim all flags have a number value. The mission editor simply translates it to an easier to understand formatting while still being confusing to those who think about it. :) I used to think of flags having 2 value types, boolean and numerical, but its best to just think of it as numbers with 0 == false and 1 to infinity == true.
 
 

 
Yes.
 
Its a minimum elapsed time, but it depends on the conditions present. With only a "time since flag" condition it will always be evaluated right at 20 or 21 seconds. Additional conditions or having the trigger occur only on certain events would effectively delay the trigger from executing until the conditions are met.
 
A trigger with two "time since flag" conditions both with different time delays and both are set at the same time, would be evaluated true based on whichever condition has the longest time.
 
Continuous>time since flag 1 is 10>Whatever will keep executing the action once a second until flag 1 is set to false.

if var then if type(var) == "string" then -- do string things elseif type(var) == "table" then -- do table things end else -- its nil end Check for its existence and the type. 

Could try engageUnit. https://wiki.hoggitworld.com/view/DCS_task_engageUnit
It doesn't necessarily require the previous task to be completed before the AI is allowed to engage any other valid targets. 
As for the weapon flags, you cannot really tell AI to prioritize one weapon over another if they are both governed by the same waeponType value. 

Generally whenever you see multiple units with "SAM [type of system] Unit Type" then you will need 1 of each of those objects for it to actually shoot. There are additional rules and caveats but that is the bare minimum. 
Make sure the Tor, Tunguska, and Osa aren't in the same group as the main sam system. 
 
Caveats
Some sams have multiple types of search radars that will work with it.  Its fine to have all of them if you want.  SA-10 requires flat terrain to deploy. If the ground isn't flat enough then the search radar, tracking radar, or launchers will not deploy and function as expected.  SA-11 launcher can shoot on its own if it visually detects a target.   Patriot STR cannot rotate to look in a given direction. The direction the unit is facing is about a 90 degree arc that it can see.  Patriot launchers also have a limited FOV, basically can't shoot behind them.   
 
 

There is no function to get the "live" livery_id a unit is currently using. Like cfrag stated you can only access what livery the unit started with. 

Azimuth is in radians, not degrees. 

Anything set to take-off from runway will be moved to take-off from parking area hot when the mission runs in multiplayer. It is a feature of the game you have no control over. Best to airspawn the group or place it take-off from parking hot to begin with so that there aren't any potential issues with it choosing a bad spawn point. 

https://wiki.hoggitworld.com/view/DCS_func_setErrorMessageBoxEnabled
Just run this function once. 
env.setErrorMessageBoxEnabled(false)

AI will only ever shoot a HARM if the target radar is on and the AI unit can detect the target. For instance it needs LOS, it can't loft a HARM over a hill even if the target is emitting. It is unfortunately a behavior limitation. You can make AI use other munitions to shoot at a point or the unit itself like cruise missiles or JSOWs. 

The clearview option is the only way. Try experimenting with timing of the message, it used to be pretty even, but if the flickering is that bad then it might warrant a bug report. 

Use trigger.action.effectSmokeBig instead. https://wiki.hoggitworld.com/view/DCS_func_effectSmokeBig
 
 

Not 100% certain it is a bug. 
In your script you use Unit.getByName():getController():setTask(). I bolded unit because trigger.action.setAITask uses the group controller. If you change your script to assign the task via Group then it will work as expected. 
 
The part I'm not sure about is the behavior of the follow command when tasks get assigned to the unit controller. 
1. 1 ship, task assigned to Lead results in follow task ends
2. 2 ship, task assigned to Lead; Follow unit switches to number 2. 
3. 2 ship, task assigned to no2, Follow unit keeps following number 1. 
4. 2 ship, tasks assigned to both at different times, Follow unit task ends
 
It seems to be similar to the behaviors of when giving multiple tasks via Group and Unit controllers within the same group. Meaning if you used only unit tasks then the wingmen will forget to rejoin when the tasks get complete because the lead unit no longer has a "group" level task for them to rejoin on. 
 
 
Edit, fun fact I only realized this upon remaking the mission on Caucuses for the bug report. Only then did I notice the use of the "unit" controller instead of group because I instinctively wrote a test task and used Group.getByName. 

So delete that task. It isn't required. In fact it is just an obfuscated and renamed "Search Then Engage" task anyway. Anti-ship, CAP, CAS, SEAD, and AFAC are all the same task, they just have different parameters that the mission editor limits you to to make them different. Point is all of these tasks are an uber basic "attack this stuff when you detect it" task and the AI will happily oblige. 
 
Simply put delete the SEAD task, then when the AI are at the waypoint you want them to start attacking things you could assign the task you want. 
You can always click the "Advanced WP Auto Fill" button at the bottom to toggle it automatically adding the default task and options. It kinda sucks we can't customize what it adds, but thats just how it is. I don't know if I'd call it a workaround, more of setting it up how you want. I learned long ago that the default tasks are only good for the passive tasks like AWACS and Tanker. Everything else should be deleted and changed to what works better. Which ranges from the free flow of search then engage in zone for CAP and maybe CAS or AFAC. To SEAD and anti-ship tasking being given explicit search then engage unit tasks which specify weapons to be used and their amount.
 

Yes you can define the blueUnits table however you want. However {"[blue][vehicles]"} is a special thing that a few mist functions use. Otherwise it will do nothing simply because it is looking for a specific unit name "[blue][vehicles]".
local blueUnits = mist.makeUnitTable({"[blue][vehicle]"}) Its checking a list of unit names, you don't have the unit object at all which is what is used to get where that unit is at. If Unit.getByName("whatever") doesn't return anything then that unit is dead. It isn't saving the unit object anywhere so each time its gotta get the object again. 
 
I left the part where it would be used blank, hoping to A. not do all of the work for you. B. You can figure it out.  
local zone = trigger.misc.getZone(cZone.name) if mist.utils.get2DDist(zone.point, pos) < zone.radius then -- whatever your code for checking it is, whether its a circle or polyzone trigger.action.setUserFlag(cZone.flag, 1) --- action to set the flag end I'd just define it in the zones table. 
{zone = 'Red City - 2', flag = 65}, {zone = 'Red City - 1', flag = 64} Toggling it off would be just a simple check at the end for each zone. Put it outside of the loop iterating the units. You could make it smarter to check if the flag is enabled true before setting it to false, but that doesn't really matter all that much. Same goes for setting it to true. 
for i = 1, #cZones do if not cZones[i].found then trigger.action.setUserFlag(cZones[i].flag, 0) end end An optimization. For the sake of argument you have 2000 blue ground units in the mission, how many need to be in each zone for it to set the flag to true? If it is just 1 then you don't need to check that zone anymore once the requirement was reached. If no units are in the zones it is running 8000 checks. If the first unit it checks is in the first zone then it will just need 5999 checks. Which is what the break lower down is for because it occurs if units are found in all zones, it stops checking the remaining units because it doesn't need to. 

AI generally don't like being spawned and then immediately being given a new task. Best to have at least some delay built in. Since you are spawning the group in the same motion you can easily just change the route it starts with. 
local cityIntel = trigger.misc.getZone(city); local ng = mist.getGroupTable('1º Defense Squadron') ng.lateActivation = nil -- group is set to late activate, remove the value so it doesn't spawn late activated ng.route.points[2].x = cityIntel.point.x --- rroute is part of groupTable, but might want to verify that waypoint exists. ng.route.points[2].y = cityIntel.point.z mist.dynAdd(ng) -- spawns the group  

DCS automatically erases a few libraries like io, lfs, and os, but you can re-enable that by manually editing Scripts/MissionScripting.lua. This is required for plenty of missions that have any sort of persistence built in. 
 
Time delays are done by putting what is needed into a function and scheduling it to run at a later time. 
local function myFunction() spawnGroup("gp1") end timer.scheduleFunction(myFunction, {}, timer.getTime() + 120)  

1. Not sure, never used it in a MP mission. It is one of those things where crashes were more common, but a specific crash was never identified. Its possible that the issue has been inadvertently addressed. 
2. Primary use cases are for training missions where you respawn dead units in the same location so that the dead wreck isn't clipping into the live unit. Cleanup of airfields in general to get rid of debris that may cause issues taxiing around. If someone decides to bomb a friendly airfield you can effectively undo the damage of the craters. 
3. I suppose it depends. Larger search area means more time to process it and possibly more objects to cleanup. I haven't actually tested the limits of it that much so I have no idea if it scales as poorly as world.searchObjects does in certain circumstances. I know those that have used it typically just had an area of a few KM and ran the function around airbases for the sake of cleanup. 

Would have to do some digging in the mission editor files to figure out if it could even be modified. The answer is not likely. 

The debriefing screen has never been great at dealing with anything spawned via scripting. It is simply a symptom of that longstanding problem. Initiator being the unique id, without other data for instance. 

Static objects can block a given spawn point from being used if it is close enough the the spawn area. Here is an A-10 assigned to take-off from one parking spot, but the static object effectively blocks it, which results in the aircraft being spawned one parking spot over in the mission itself. Best to move the static objects away from where you want the aircraft to spawn at and gradually move them in until it moves the unit. Then you'll know you've gone to far. 

The AI take-off priority is pretty easy to figure out. For multiple groups the order is based on the taxi distance of the flight lead from the start of the runway. Then each group will taxi based on that order. For example in the screenshot below the top aircraft is closer to the runway, but has a longer taxi distance to get there. In this instance the aircraft with the blue path will taxi first.
 
Additional wingmen add an extra rule, but it is still straight forward. Within a given flight the taxi order is always based on the flight member with it being 1, 2, 3, 4 regardless of location. The next flight will wait until the last wingman of the current flight begins to taxi and is closer to the runway. Using the screenshot again imagine if the blue path AI has a wingman at parking number 5, lets call it "blue 2". The red path AI will taxi almost at the same time as blue 2 because the path of blue 2 is still shorter than the red path AI, and it won't need to wait. 
It gets annoying if blue 2 is parked someplace further away from the flight lead. In one instance lets say blue 2 is at parking 120. The blue path flight lead will taxi, once it passes 120 then blue 2 will start to taxi, and then red path AI will taxi with little delay. Likewise if you put blue 2 way up in the north eastern corner of the base it will taxi at the same time as its flight lead, but the red path AI will wait until blue 2 is closer to the runway than itself. 
 
That said there are plenty of other nuances to AI taxiing behavior that are partly down to general AI rules and even how airbases themselves are setup. You can create a empty mission, slap some AI down, set the wind, and you can easily experiment with how unit placement impacts take-off order.