cfrag

The "valet" module in DML can do that for you. It's simple enough to use - check out the zone's attributes, the entire magic is contained therein. 

And, yeah, it supports dynamic text and other helpful stuff if you want. Oh, and typos are of course intentional 🙂
 
Miz attached.
 
Zone WarningsEnter and Leave.miz

It seems that I have no such issues:

Perhaps ensure that you have the disabled the 'chrono' (time period planes only) option at the bottom of the editor

Yes. See below 🙂 
Now it does! 😎

Long story short, based on my ramblings in previous posts, here's a proof of concept that populates the Suez canal with 21 ships. 20 of them are spawned dynamically, based on the route that the one original ship (the Roosevelt in the demo) is taking, and they all spawn somewhere in front of the Roose, in one of five different types (dry cargo 1/2, Elnya, harbor Tug, Handy Wind). Each time you run the mission, the resulting ship positions are randomized 
To modify, look at the script 'lineTraffic'. lineTraffic.makeTrafficBasedOn() is the call that you invoke to create a new ship in front of the reference ship, based on that ship's route.
To control the number of ships in the canal, change the 'passes' value. Each pass, 5 ships (one each of the types listed above) is added at a random path location.
Here's the miz for your perusal. 
Enjoy,
-ch
Suez Populated.miz

There are a couple of facets here that contribute to this.
First, AI / potentially AI controlled (i.e. non-static, so they can be activated) units are managed differently from statics. Static objects are regarded as stage props. They are disregarded by AI. This does not apply to inactive AI, they will be attacked by enemy AI, and therefore have to be considered in the AI's decision tree. And this has consequences: The more units you have on your map, the more unit-unit checks need be performed for the AI to decide what to do. And this count rises near exponentially with each new unit that you add (2 units: 2 checks; 3 units: 6 checks, 4 units: 12 checks, 5 units: 20, n units: n * (n-1)). Now, as long as the unit is uncontrolled, the overhead rises linear (they still have to be checked, but since their AI is not yet active, inactive AI units don't check for all others). But each AI unit adds to the number of units that need be checked, and this effort rises for every additional unit. It does not for statics, "they don't count". 
Of course, like statics, these uncontrolled flights also require to be drawn, and they will impact the GPU (AI impacts mainly CPU). Uncontrolled planes may use more GPU power than static objects because they are often drawn with the armament that you have chosen, requiring more polygons and textures. Unless you overdo it, this should not create a heavy toll, but uncontrolled AI planes can demand more from the GPU than a static.
Late Activation flights are less resource intensive because they - up to the point that they are activated - do not exist in the game. The AI does not check against them until they become active (neutral to CPU), and they have no model representation, so they also don't hit the GPU. They do demand a tiny amount of CPU for simple housekeeping, but other than that, Late Activation flights should be neutral to performance as long as they aren't activated. Once they activate, they count like any other AI does. Also note that not all units are alike, and some active AI require more from your CPU than others: an M4 Soldier's "AI" does not require as many cycles as, for example a Flanker's AI. Generally speaking, aircraft AI requires more CPU than ground or naval AI.
 

Here's the script, simply paste it into a DOSCRIPT Action on MISSION START. It will monitor all your landings, and if you (a player) land on an airfield that does not belong to your faction, it puts an infantry soldier close to your touch-down point in an attempt to capture the base. You'll see a message appear when you were successful.
Script:
 Demo mission and script as file below. You many need to change to A-10 to any aircraft that you currently fly and can land reliably.
 
grab'em now.miz grabber.lua

I was lazy - you'd have to trawl the mission data structure for the livery of the unit because (as it seems), the information is for - reasons unexplained - not in the desc structure that the script queries from the unit. Getting that information from the mission is tedious to code, but quite possible.
That should be doable - make the replacement part into its own function, then use timer.scheduleFunction with the unit as argument and you should be all set. 

This is currently allowed for all planes, with the restriction that the plane in question must be player controlled (i.e. Skill Level is "Player" or "Client"). AI planes can't take off from ground cold, they must use a slot at an airfiled/carrier

Don't. You end up spending more time than trying to do it yourself. These chat bots are party novelties, created to talk to you, unfit for coding.
Below please find what I hope you were looking for. 
 
random-group-spawn DML.miz

When you resort to scripting, it's one of the rather basic things. Here's a video tutorial on how you can do it with DML. Instead if aircraft, simply place the SAM units inside the clone zones.
I hope this helps,
-ch
 

They all have unique id, yes. The ID is returned as a result, similar to when you call a function like math.random(100) (except random numbers aren't unique). You receive a number, and that number uniquely identifies the entry in DCS's table of future invocations, something like a 'ticket number' that you draw when you are waiting in a queue, or handing off a coat at a valet service. The number on the ticket has no intrinsic information for you, you only can use it to get your coat back. Similarly that ID ('ticket number') says nothing about when the invocation will happen, but it identifies it so you can later tell the system: "hey, delete scheduled ticket number <xyz>, it's no longer needed".  It's that ticket number that you feed to timer.removeFunction()
Since you choose to ignore the result, you lose access to the id. When you write 
the ID that is returned from timer.scheduleFunction is simply discarded. To retain the value, you need a variable to store it, something like 
mySavedID = timer.scheduleFunction(F_ACTIVATE_LAG, i, timer.getTime() + GRP_Spawn_TSS*60) Now, when the function invocation is scheduled, it hands you back the 'ticket number' for you to do with as you see fit.
 
The current implementation uses numbers, but that may change any day. Treat it as an opaque, abstract 'nubbin'. It contains no valuable information inside, other that it allows you to later cancel the invocation. You cannot (read must not) change that ID yourself
That would be nonsensical to the system. Like the valet service, it alone knows how to match the ID that it passed to you back to the scheduled item. So if you change it, there is no way it will later be able to match the changed number to the invocation. It would be like drawing a number for your coat, and then changing that ticket number to some other value yourself. When you try to turn in an altered number, the valet doesn't know what to do with it. Best case: you get the wrong coat. 
So, if you need to to know which ticket you received relates to which invocation, built a key system for yourself, and store the scheduled ID's in an array that uses the key as index, e.g. 
myIDTable["groupKappa03"] = timer.scheduleFunction(...) That, of course, requires that you feel comfortable with arrays. If you aren't already, this would be the ideal time to get acquainted with one of Lua's best features 🙂
 

Please ensure that your historical filter (bottom center of screen) is turned off.

There is the Luv Tigr that (as unit, not static) has active lights.
 

I believe that ROE are intended for all units of the group for which you issue the ROE (you may have noticed that you issue all orders on group level, so this somewhat stands to reason). Whether or not if works for said group may depend on other strange factors like the dilithium-activational state of your flux compensators.

That is mainly because the "DCS" api is available only to the server part of the game, not the mission itself. DCS separates the server and client parts of the game, and each part has access to different API. 
For security reasons, some parts of the Lua API (namely io, lfs and os) are disabled. If enabled for all DCS installation, malicious people would be able to use missions to attack your computer. So each and every DCS installation is 'sanitized', meaning that io, lfs and os are disabled for Lua, and it requires your active participation (you need to edit a text file in DCS) to change that. To get good instructions on how to do that, you can google 'unsanitize DCS' or similar.
Start the mission as multiplayer (server), and click the "Resume on Load" radio button in Advanced Options.

Can you try with a vertical resolution of 1200? 768 seems awfully small.