I've tried both of those already, even with small numbers it's the same, and the server reports only 15% CPU usage at peak.

I'm sure it could be integrated though, perhaps expanding the scope of C2ISTAR into a "Commander's Tablet" that allowed for group management functions as well as intel and tasking.

Github would be handy, I can see this becoming very useful as a feature, and making it easier to update can only be a good thing.

Oh I see, that clears up the difference and why there are two options, thanks.

I've put an onPlayerRespawn.sqf in with that command, as your interface is only meant to be available to a unit named "s1" I've changed it to "s1 addAction ["Tactical Command Interface","CreateDialog 'Spyder_TacticalCommand'"];" and added the line "removeAllActions s1;" in front of it, this should ensure that I don't end up with duplicates every time a player dies.

Looking forward to the updates, I think you should approach the developers about including this in C2ISTAR.

I've been making a large-scale mission with the intention of it being a near-perpetual battle, with both sides on a dynamic reinforcement pool.
I've hit a snag though, it's taken a while to confirm it, but after a number of hours (two or three) both sides OPCOMs stop assigning objectives. With Virtual AI debug on I can no longer see movement crosses after this time, and all forces sit stationary.
I've tried all permutations of force sizes and balancing, but the problem seems to be that after a while OPCOM just gets bored and goes home.
Any ideas? Is this a setup issue? A bug?

This is excellent. I think I know the answer already, but are requested units put back at the disposal of OPCOM once they've finished your requested mission, or do they just stay there?
Also, what is the difference between request assault and request reinforcement? As in both you set a location for the groups to move to, is there any difference in behavior between them?

I'm noticing that upon respawn the addaction is removed. I know it could be worked around easily enough but I thought I'd let you know in case it's an issue with what you've created, rather than a regular scripting issue.

C2ISTAR has an auto-generation feature for task where you pre-set the friendly and enemy factions, so you don't have to set the type manually every time. You don't actually have to do anything as it will just send the missions to you.

If you want to restrict it to certain types of missions it's a bit idiosyncratic, but I've found a way to do it. I'll post it here if you like.

Just a quick one, if I change the marker name to a global instead of local (so "_marker" to "marker", would that restrict it to one marker at a time? That would actually be quite handy.

I'm looking forward to this. It sounds like a feature that would be integral enough to be integrated into ALiVE.

Yeah, I can confirm that that works as well, and as you say it's a more efficient way of doing it.
It's also nice that the two radii can be different if desired, so you can remove the markers if the player is within 1k but detect troops in contact with enemy within 300m.
Running it every 1s makes for a fantastic flashing effect that really draws attention to the marker, and I like the fact that it can be active at multiple locations simultaneously. It could also be used as a FLOT indicator easily by changing the marker type and duration.

As I said, thanks a lot for this, it's going to add a lot to my scenario (which I really should post here somewhere if I ever stop fiddling with it!).

Ok, I think I've got it. I moved the player detection part to make the entire code this:

private ["_factions"];
_factions = _this;

//-- Get profile id's
_profileIDs = [];
{
	_profileIDs = _profileIDs + ([ALIVE_profileHandler, "getProfilesByFaction",_x] call ALIVE_fnc_profileHandler);
} foreach _factions;

//-- Define delete function
_fnc_deleteMarkerTimer = {
	_marker = _this;
	sleep 0.5;
	deleteMarker _marker;
};


//-- Get profile position and execute check
{
	//-- Get profile and it's position
	_profile = [ALIVE_profileHandler, 'getProfile', _x] call ALIVE_fnc_profileHandler;
	_position = [_profile, 'position', []] call CBA_fnc_HashGet;

	//-- Check for enemies
	if (((count ([_position, 300, ["EAST","entity"]] call ALIVE_fnc_getNearProfiles)) > 0)) then {
		_marker = createMarker [(format ["%1", random 200]), _position];
		_marker setMarkerType "mil_warning";
		_marker setMarkerText "Troops In Contact";
		_marker setMarkerColor "ColorOPFOR";
		_marker spawn _fnc_deleteMarkerTimer;
		if (({_x distance (getMarkerPos _marker) < 300} count ([] call BIS_fnc_listPlayers)) > 0) then {
		deleteMarker _marker;
		};
	};
} forEach _profileIDs;

It works like that. The markers display correctly (flashing) when the player is outside 300m. When the player moves to within 300m all markers are removed. That's exactly what I wanted.

Thanks a lot for this, it's going to be really helpful in my mission for helping players get into the action.