Note: the following is using single player mode but most/all should still apply to my knowledge
It’s not terribly difficult to “roll your own” for this singular purpose, basically I would extract the group table from a miz; place it in a separate lua file; on some trigger spawn it by passing the coalition and country and the table defines the group properties, etc. and do it as many times as you want.
AddGroup/addStaticObject are the two functions in the API.
I get a bit more granular to allow for some variety with the type of unit (this requires a specific loadout scheme = a bit more complicated).
I script my own trigger zones so you’d need to acquire the position of, for example all blue side players (I only have to worry about one unit, the player).
However given the first part only: you should be able to have a repeat trigger on the zone and decide (in the above lua file) if/when you want to spawn the new one; call your fxn from the trigger via :
Do Script
SpawnMyThing(arguments)
The arguments can be all kinds of things, or empty depending on any conditions you might want. Most of the things you might want as arguments u can get via the scripting engine API however.
The benefits of my own trigger is, for example, I can call them at a rate of my choosing and not every second (think that’s how the repeat trigger works). U could even call this function (or any other) at a higher rate too but u have watch out here cus you can introduce unwanted delays, depending on what u are doing.
In the end you know how it works (cus you wrote it); You get just the functionality you want without having to load a whole system for that one thing.
NOTE: I’ve skipped the lua syntax details here and the mechanics of loading of the script and extracting the desired table/values.
AND…
[1] with some minor voodoo you can edit this in a text editor and only have to hit “fly” to test changes - OTW you have to unload/save/reload/save again the mission for every freakin change. a PITA
if you look at any of the early DEPLOYED miz files you have you’ll see a trigger that only fires if I set a “debug” trigger, which then uses loadFile(path to your script)-that’s what allows u to edit “on the fly [nearly]. Requires you to ‘unsafe’ your install but for a release version you skip that part and load the final (script) version the normal way.
I only call 1 file but that one then loads all the others.I don’t include that file (or I don’t anymore) as this is ignored for the release version (the end user doesn’t need it; is for my use only while testing). In my case (minus the radio handling) I’d never be able to do as much with page after page of triggers; the entire system only need a few triggers to get the ball rolling. Is for me much easier to organize in separate text files than a huge collection of triggers .
- this “load every other lua file” file has a few branches cuz I do a bunch of other things there on my end
[2] you can attach a debugger to it too to examine things. It’s hit or miss sometimes but it does help greatly when things get complicated
[3] yeah, nobody [when I was teaching myself all this, to include how lua works] tells you this stuff in any one place (the scripting wiki being the one very helpful exception) had to dig for it. But….only have to do it once 
