IADS Hierarchy and EMCON (Full Version)

All Forums >> [New Releases from Matrix Games] >> Command: Modern Operations series >> The War Room


SeaQueen -> IADS Hierarchy and EMCON (6/1/2021 10:26:10 PM)

Have any of you experimented with changing EMCON states based on where a radar fell in the IADS hierarchy? For example, at the highest level might be a sector. It might have a few EW/GCI radars associated with them. If they detect something, they might only turn on the radars of the SAM sites near the target, or if they're destroyed or drawn down to a certain level, that might cause the SAMs to turn on their acquisition radars to search for targets.

I'm trying to think of ways to improve SAM site survivability, and was thinking that limiting their emission to the minimum necessary for them to acquire targets is the way to go.

PN79 -> RE: IADS Hierarchy and EMCON (6/2/2021 7:19:30 PM)

For SAM survivability I was detaching acquisition radar from SAM unit and made it as separate unit. So SAM battery with just engagement radar could stay silent till missile launch. But this needs to be done in mission editor during mission creation.

SeaQueen -> RE: IADS Hierarchy and EMCON (6/2/2021 10:56:48 PM)

That's a good idea too. I know in some cases there are already detached acq radar units but not all cases.

ExNusquam -> RE: IADS Hierarchy and EMCON (6/4/2021 2:00:09 PM)

Will the site break EMCON if you give it an engagement command via AttackContact? Determining which site to engage might be a mess but it would result in the correct IADs behavior of the SOC assigning specific batteries to engage.

PN79 -> RE: IADS Hierarchy and EMCON (6/4/2021 6:28:55 PM)

If SAM unit has EMCON passive but is allowed to fire then it will break that EMCON for engagement but once the engagement is over it will get back to passive. This behaviour is fine to me as I usually want SAMs to behave this way.

Forbidding automatic fire and starting all engagements with manual attack can simulate proper IADS like was in Warsaw Pact where command centre was assigning targets to SAM batteries. But in large scenarios it is too much micromanagement.

For SAMs I am using weapons setting where I can define that specific SAMs will engage only specific targets (and ignore others) and also setting max range and number of missiles per engagement.

SeaQueen -> RE: IADS Hierarchy and EMCON (6/5/2021 11:32:57 PM)

Yes, but I'm less worried about trying to get it "exactly right," I'm just trying to work on "better." In general I've found the software does a fairly good job on its own of deconfliction, I don't really need to worry about that. I'm thinking purely about acquisition radars, not engagement radars, putting some code in so that they only emit when they really have to. If someone else can pass you the track, then you only want to light up your engagement radar when you have to in order to guide the missile. In that case, it makes sense to just rely on the surveillance radars for your area. If, on the other hand, maybe those radars are being jammed, or they're destroyed, maybe it makes more sense to light up some subset of the acquisition radars on the SAM sites themselves, since the IADS is at least degraded.

I was wondering if anyone had done anything like that before.



Will the site break EMCON if you give it an engagement command via AttackContact? Determining which site to engage might be a mess but it would result in the correct IADs behavior of the SOC assigning specific batteries to engage.

stww2 -> RE: IADS Hierarchy and EMCON (6/5/2021 11:49:04 PM)

The second scenario from Kashmir Fire ("Escalation") has the Pakistani ground-based air search radars switch on if the AEW platform in their sector is destroyed (or at least I assume they're split into sectors; there are two separate AEW patrols and I've only destroyed one of them so far). If that's the kind of thing you're looking at doing, it might be worth taking a look at that mission's scripting to see how it's accomplished.

AndrewJ -> RE: IADS Hierarchy and EMCON (6/6/2021 1:39:20 AM)

I think some of Gunner98's Northern Fury series had this aspect built in. As I recall, it was one or more of the ones covering the NATO counterattack on occupied Iceland. Initially there were only a couple of surveillance radars operating, but as those got killed a successive series of other radars would come on line. It certainly made it difficult to hit the hidden SAMs, since they weren't obligingly emitting in the initial stages.

SeaQueen -> RE: IADS Hierarchy and EMCON (6/6/2021 1:39:55 AM)

Huh, that sounds like a start. I was hoping for something maybe, more extensive?

LORDPrometheus -> RE: IADS Hierarchy and EMCON (6/10/2021 5:34:13 PM)

Sorry for the 4 day necro but this was too interesting to pass up.

When it comes to an IADS the best way to make it more capable is to make it more diverse and complex. In general a region will be defended by three layers of SAMs. Short range SAMs surround assets such as ground formations and airbases and are meant to act as point defense. I like to set my short range SAMs up with zones so they only turn on when an enemy aircraft or weapon is within about 40nm. The second layer are medium range SAMs. Those will be spread out and defend access points IE areas where the terrain favors attacks. I usually place mine where I would attack if target A is over a mountain range and a nice valley runs through it and gives a good path for an attack plop a medium range system on a hilltop that can see deep into the valley and make it stay silent until the enemy plane gets close. That way they have limited room to manuever. The third layer is long range SAMs. These are more of a deterrent and distraction really. I often keep them ON at all times. I want the enemy to see them and focus on fighting them and in doing so be drawn into the traps set by my medium and short range systems. A few capable short range systems near the long range ones can make them very survivable as well.

As for Radars a similar hierarchy applies. Short range radars are for gap filling and should be turned on alongside near by SAMs for augment their tracking. You can also use them as bait by turning them on to try and draw in enemy aircraft. Medium range radars are your primary platforms for actually finding enemy units. I like to place a good scattering of them about and link them to simple timed events to turn on and off by switching EMCOM. Long range radars are for early warning and general surveillance. As such they really need to be on at all times. Usually I set them up with backups which is super easy with an event

Conditon- unit damaged
Action - change EMCOM active.

PN79 -> RE: IADS Hierarchy and EMCON (6/10/2021 8:44:32 PM)

Such event for EMCON change is really good recommendation.

LORDPrometheus -> RE: IADS Hierarchy and EMCON (6/11/2021 1:14:09 PM)



Such event for EMCON change is really good recommendation.

While Lua is extremely useful if you can do soemthing for a third the effort with events always use the event

KnightHawk75 -> RE: IADS Hierarchy and EMCON (6/12/2021 8:55:31 AM)


Huh, that sounds like a start. I was hoping for something maybe, more extensive?

I was hoping for something maybe, more extensive?

How much rambling do you want? [:D] I too was sitting on this for a couple days.

As usual I'm probably gonna be more long winded here than need so I'll put the bottom line at the top. [;)]
Unfortunately often at present one can't pull the information needed from a contact\unit like that is displayed in the contact status screen via Lua. This makes life difficult in trying to accomplishing anything too advanced\too extensive in a reliable and performant way because you can't (consistently\reliably) associate a contact with who's actually got relatively recent tracks on it upon which to make more informed decisions logic upon what you may want to do (or not do). The information exists,can't get at it. Don't get me wrong I know the devs only have so much time to allocate to enhancements like this, particularly in retail.

I raised this some time ago, http://www.matrixgames.com/forums/fb.asp?m=4911711 the limitation and what access to that data would help enable seemed to be acknowledged, as for any priority give too it vs 1000 other requests who knows, and it's my guess there aren't a ton of people trying to script their own little ai's in retail... but there are a few. ;)

That's my TLDR Version.

The Extensive\Advanced things you generally can't do in retail:
Some of things I've wanted to do (context here mainly AI side) but can't.
If sensor s1(or just the unit) on unit A is tracking contact X and it's <= range y from unit A (say a EWR) or some other arbitrary point, then enable specific sensor s3 on unit F (be that fcr, search radar, ir tracking, whatever, otherwise don't activate). That would apply to things involved with IAD hierarchy. You can do the contact range part relative to a unit, but you can do it based on who's tracking\has the track on it.

Getting even more advanced like checking if unit A is tracking contact X at rate of every 12sec, and unit B is also tracking contact X at every 5sec or less and B's track is from a FCR radar and at certain range and B has weapons available, and unit C is <= N nm from unit B then maybe there is no need to fire up it's radars yet. Additionally maybe that gets overridden in cases and you do want to fire up the radar still - say if unit B is actively firing on something at it's max firing rate (ie B's weapon table shows 16 missiles outbound,12 more available,but only has once instance of a 16 channel missile command comms) and the contacts that B's is tracking in missile range exceed 16, and said 'extra' contacts are inside C's fcr and missile range such that turning on C might help. etc..etc..
You simply can't do a lot of this advanced logic even if you wanted to spend the time atm without reliably knowing exactly who (which units) and sensors have tracking on what contacts.

BUT if one had access to the contact status screen level of data one could if one wanted create all kinds of logic (good or bad lol) for a given specific scene setup, or maybe even develop some more broadly usable logic toward specific sorts of setups\desires. Even having just the last 20 or 25 or so I think per contact that it keeps would be incredibly useful and we could build our own extended tables based on the ever changing last ~20 provided. Alternatively I suppose a sensor detection trigger type (not to be confused with the generic detection trigger that exists that doesn't cover what is needed) would let one build and maintain their own tracking and association tables. The first strikes me as more modest request to implement be it on the unit or the contact wrapper (or both) as all the info at least preexists.

Types of things you CAN do today if you want to spend the time scripting it, some are heavier lifts than others:

-If X destroyed or damaged > Y% (or checking particular sensor(s) on unit X for damage\destruction) then Do\activate Z.

-If weapons of type Q are exhausted on Unit A or B or Group D or inventory < Y on unit A or Unit B then dosomething\like activate unit C.

-If unit A or B looks overwhelmed (firing x amount of missiles exceeding it's comm lines) and y amount of contacts marked posture H are in a given area and they look like they are in range of Unit C then activate unit C (flip him off passive and to tight).

-Contact range based things broadly - ie If contact X of type Y <= Zrange from UnitA (no matter who is actually tracking it and if this unit would know that) then activate or deactivate desired sensor(s) on one or more units. Just be careful to check\measure contact.areaofuncertainty size first though cause you often don't want to go turning things on due to a widely uncertain readings. This can give you at least some control when dealing with layered IAD's and knowing went to flip off hold or not, so at least things far-in aren't turning on well before you may need them too. I have a customizable per unit\sensor form of this in my YARC for example but after the passive not really being passive anymore have to go back and adjust for release doctrine to actually restrict things.

-You can apply some logic based on if the unit\sam in question is already a contact on another side, and grab that contact wrapper and see what the detection level is (assuming it's accurate - it isn't always and I've reported it) and if the areaofuncertainty is greater than x, or what types of tracking they have on you. If you determine they have only a vauge fix on your unit maybe that plays into if you really want to activate your emissions more. If your unit is mobile, maybe it's time to scoot to a new location if they do have a good fix on you, or if static-fixedfacility maybe go hot because they already know you're there. Using unit.ascontact is however more on the "cheat" since unless your weaving info-warfare into the scene as it's info the unit\side may not realistically know. But often it's still worth doing. You can always make it degrade or turned off with the destruction of particular or groups of particular things, or maybe is only active during certain times, or the human gets certain things exposed or give if balance is needed.

-You can apply some logic based on entries in unit.weapon, unit.firingAt, unit.targetedBy, and unit.firedOn tables (should data exist and timing is right) as to if "now" is really a good time to turn off one's emitting sensors (or for that matter to turn on). This can be useful if randomizing sensor activities for periods of times and you want over-rides to the randomness (like I know I told you to turn off now.. but ignore my orders for at least 30 extra seconds cause you have weapons in the air that need your guidance...check back again in 30 seconds).

-Though firedOn and targetedBy can be a little cheat'ish in certain circumstances depending if the unit being fired on actually really knows it yet (ie cruise missiles 400 miles away that are not yet detected as I recall will still turn up -which isn't always a bad thing, rather have the data and choose when not to use it,than not have it). That said giving an AI opponent a bit of an edge in information there in CMO I rarely consider bad in most scenes because of all the other limitations\disadvantages it has vs a human player - especially one who may know how to 'game' usual behaviors. Even when applied on the human side it's often less a cheat and more just a time\focus saver more than anything. ascontact is definitely more on the cheat side.

-Here and there QueryDB can help but it really needs to be extended more in it's coverage to be more useful but one can overcome that by embedding one's own databases of capabilities.

Side note - Also wish there was a way to determine "jammed" status of a unit (or even better at the sensor level on that unit) as it could be optionally be used as a factor applied to certain implementations of logic related to emissions control.

Side side note - Still after all these years you can't simply query the state of a units\groups\mission\side EMCON, sure you can set it, sure you can override it with what you want now, and in 1146.x+ you can query and flip the override state at unit level, but you can't actually query the current state\doctrine setting. I don't understand why there is no corollary such as a ScenEdit_GetEMCON() to ScenEdit_SetEMCON (request posted). Makes it problematic when trying to dynamically return something to a prior original state since you can't record what that was, or determine if you even need to waste some calls to do something that may already be set. I have added it to the list of requested features, also there was some discussion some time back about making a 3rd emcon state such that active was on, passive like it used to be was off and the new default was current behavior of passive not really passive but FC coming on when the system thinks it should.

In addition to all the scripting solutions you also have the basic of separating things to search unit and firecontrol based unit like pn79 mentioned (and if us\uk and few other pieces - cec related trickery\deception you can setup sometimes), and adding a whole lot of WRA range settings (which you have to do anyway now) so that things (now..at least - I preferred the old system when passive actually really meant passive) don't expose themselves earlier than needed, though the new system has is upside cases too. What others have mentioned already are all good suggestions with very little to no scripting needed.

Hopefully there was something useful to someone somewhere in all that.

Page: [1]

Valid CSS!

Forum Software © ASPPlayground.NET Advanced Edition 2.4.5 ANSI