Grimes

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. 
 

They changed the name of the ROE settings. By assigning a search then engage task it is assigning a target that applies to the "only designated" setting. Basically a "do what you were assigned to do" as the setting. The two settings above it, priority designated and weapon free, allow it to attack other targets. For example if you have a SEAD flight tasking it could more proactively attack air threats. Priority designated simply means it will do SEAD first then worry about air threats.
 
-a means it was automatically added. 
There is an -x that appears when the enabled box is unchecked. 

It is the task queue. The FAC task needs to be completed before the options are set. So move the options to the top. 
https://wiki.hoggitworld.com/view/DCS_editor_FAQ#Why_isn.27t_an_AI_task.2C_option.2C_or_command_working.3F

The kilo doesn't have torpedos in game. You have to use either the WW2 sub or the Chinese sub. 

Deactivate is the same as destroy. 
This is where scripting is helpful because you can "respawn" groups an infinite number of times and get the same desired effect of deactivating and reactivating a group. 

Appears to be bugged. Just spotty with the types of trees it wants to remove and where. Looks like it is also suffering from an existing bug where it treats a sphere as a box to remove objects. 

https://github.com/mrSkortch/DCS-miscScripts/tree/master/ObjectDB
 

My experience with export is limited, but IIRC there is no "schedule function" to make sure something runs in X seconds from now or anything like that. But what you can do is use onSimulationFrame to check the time between it was last run and you can then execute functionality every x seconds rather than every single frame. 
It might aim for 60, but its best to sample the time each time it is run and check the difference. 

Slight omission on my part. It is copying the group as defined in the editor, which means the group still has the "late activation" value applied to it. So it is spawning a group, but the group isn't activated. You have to remove that value. 
local gp = mist.getGroupTable("USAF") gp.clone = true gp.lateActivation = nil local rndAlt = math.random(4, 10) * 1000 for i = 1, #gp.route.points do gp.route.points[i].alt = rndAlt end mist.dynAdd(gp)  

Correct. Though you may have to declare it as a value first. Don't remember if it would like Group.destroy(...)
local gp = ... gp:destroy()

The game really doesn't make it easy to do that. With the threat rings it is a question of whether or not the hiddenOnMFD is checked and when the group spawns relative to the player spawning. Group spawns with hiddenOnMFD, then player spawns, that player shouldn't see the threat ring. Same if the player spawns and then the group spawns with any setting. 
By those rules you just need what you want the player to be seen when the player spawns and then add/change whatever after the player spawns. To make things much easier you can always spawn the player later. This would be the easiest way to do it with just triggers. Force the player to start at 2 seconds into the mission. At mission start set a flag to whatever value. Once time less than 10 seconds, so it runs first thing after mission start occurs, for each sam if my flag is false then group deactivate. Now player spawns. After player spawns then you can activate a group that had hiddenOnMFD checked and deactivate the sam representing the threat ring. 
 
However to utilize the lua condition is a little on the annoying side. The only thing that runs before it is the initialization script found on the trigger panel. You can add something like this to every sam you want to conditionally exist.
if tbl["Ground-1"] then return true end Then in the initialization script you need to define tbl and add the groups you want to add to it. 
tbl = {} local choices = {"Ground-1", "Ground-2","Ground-3","Ground-4","Ground-5"} local rnd = math.random(#choices) tbl[choices[rnd]] = true What this is doing is the initialization code creates the table and adds the group name as a key that gets checked by the condition. Then the condition checks to see if their respective group name is found in the table, if it is then spawn the group.
 
This would be a whole lot easier if we could just draw a threat ring on the MFD and ignore the units. But we can't yet, so here we are. 

You can also use https://wiki.hoggitworld.com/view/DCS_func_get_player_list which should have the player name info available. 

Unfortunately the best that can be done is to create a mission command at a group level and pass the relevant id as one of the values within the command. The example on this page does exactly that. The passed value to the function is the group name. 
https://wiki.hoggitworld.com/view/DCS_func_addCommandForGroup
 
Much to our collective lament ED has yet to add commands for units. The smallest it goes is for groups. This is why CTLD requires the helicopters to be their own group. Its the only way to be 100% certain which player issued a command. 

The skill as saved in the DB is "Client" not "Clients". You should also be able to pass "human" as a skill value and it will include any aircraft set to player and client. 
Me being me not using my own functions that I write you can easily get it from iterating a table yourself. 
local list = {} for uName, uData in pairs(mist.DBs.humansByName) do if uData.coalition == 'blue' then table.insert(list, uName) end end  
 

That is quite astute because that is more or less the default behavior. To get maximum saturation it is best to micromanage the AI. From what you write that appears to be what you are doing with those parameters it should work relatively well. 
I'm gonna guess that the default SEAD task is still assigned. If it is then delete it. If I'm right about that then the problem is that the AI detect a target then leave their route to attack said target. This is a problem because by leaving the route they don't actually pass the waypoint that assigns the attack group tasking. The default behavior for each of the enroute types (CAS, SEAD, Anitship, etc) has an internal calculation for "can this weapon kill the target" to decide how many to shoot at a given target. They don't account for the weapon failing due to be shot down. Thus for SEAD it results in firing 1 missile at 1 radar at a time, hence the need to micromanage. More groups is one solution to it because this rule only applies within a given group.
Assuming you use attack group, attack quantity = 1, group attack = true, and define a weapon release quantity then you should get them all to engage with what you tell them to. I will add that the attack group/unit tasks have a, lets call it a vulnerability, for SEAD tasking where the AI CANNOT engage a sam in a pre-brief type mode. In order to use an anti radiation missile on a target the AI must be actively detecting it. If the radar is off or obscured by terrain then the AI cannot engage with ARMs. This doesn't apply if you tell it to shoot a JSOW or really any non ARM at it. This is one of the bigger advantages of "search then engage" tasks because it allows the AI to attack that target when they detect it. 
Additionally assigning a attack/engage unit task is beneficial compared to the "group" counterparts because that allows you to prioritize the target unit. In a quick and dumb test with the SA-10 missile intercept disabled of 16 HARMs shot by a flight, 12 went to one search radar and 4 to the other. Specifying a unit allows you to equalize the odds of both getting hit. 
 
If removing the default SEAD task doesn't help then post the mission file and I'm sure the problem can be solved. 
 
 
 

Looks like a mission editor bug of some sort where it inserts an extra point into the table. Possibly with double clicking. If you choose "Select" and move the line segment points then you should find the extra point overlapped with the initial point. 
Anyway origin in this case is relative to the origin of the shape. Its more of a vector art way of saving the data. Suppose it is just going about the calculations backwards from what something like how groups are placed. What I mean is you put a group of units down, each unit has coordinates relative to map origin, if you then move the group leader it'll add the +/- XY difference in coordinates to each unit to "move" them. While with shapes each point is XY relative to the first point. if you move the shape as a whole it just updates the mapX and mapY value saying where the shape starts at. Then the renderer takes that information and renders the shape as needed. A group with 10 units needs to update 10 sets of coordinates, a shape with 1 points needs to update 1 coordinate set. 
 

The warehouse is empty. When you spawn aircraft on the ramp it pulls the aircraft from the warehouse, but it doesn't when spawning on the ground. If nothing is available then the unit won't spawn. 
nullIf you were using the warehouse before then it might be best to set to unlimited, save mission, turn unlimited off, and then adjust the values as you desire. Warehouses still get a bit corrupted after objects get added to the game or with mods, so its best to "reset" the values from time to time. 

After watching the track I am of the opinion it is fuel related. I added a script to display its fuel value, and though time acceleration changed the results of the track enough of the dogfight progressed for me to think it is fuel. For starters the Su-33 gets assigned 50% fuel so it can take off from the Kuznetzov short ramps, its gonna make it to bingo faster. First un-modified track it just gave up and flew to the last waypoint. Second run with the fuel output it got down to 20% fuel and shot you down after extending north. First track went on for a bit more so it is safe to assume it had somewhere less than 20% total fuel capacity. 
 
It helps the AI if it has a takeoff or landing base assigned as part of the flight plan. IIRC without an airbase assigned it doesn't know or think about where it can RTB to in an emergency until that happens. Think of it as the AI know they have a route of X distance, but ultimately know they are going to a specific destination that is Y distance from their current location. Giving it more fuel and adding a landing waypoint would help. 

You can't specify which units are invisible to others. The option is on/off and applies to all AI. However invisible units can still broadcast their own datalink to a network. 
Tanker set to invisible: AI AWACS can't "see" the tanker, thus it isn't on datalink. *
AWACS set to invisible, has EPLRS (datalink) task: AWACs broadcasting its position to datalink network. 
AWACS set to invisible, EPLRS (datalink) task disabled: AWACS not visible on datalink. *
* Being the caveat that player controlled aircraft should still share their datalink radar contacts. So in the example of the tanker if a player had their radar on and detected it then other players on the datalink network should see it as long as the player sharing it still detects it. 

2021-07-17 04:40:57.515 ALERT   LUACOMMON: Error: GUI Error: [string "./MissionEditor/modules/me_aircraft.lua"]:923: cart has no default task!
 
cart is the unit typename. It is something from one of the mods you have installed. Probably best to figure out which mod is at fault and alert whoever made it and uninstall it in the meantime. 

You have historical mode on. Its a filter that limits the available units for a given country based on the year. Combined Task Forces don't have dates setup for any unit, thus it is empty except for the unit you placed. Click the watch icon at the bottom to turn off historical mode.