Autogenerated AI SEAD flights are not doing SEAD

[SnappyComebacks]

I made a package of DEAD + SEAD + Escort with player as DEAD and package leader. When SEAD reached the ingress waypoint it turned directly towards the egress waypoint and slowed down, not providing SEAD support, and ultimately letting the package get destroyed.

I have enabled Skynet in the campaign as well.

The campaign map:

The SEAD flight highlighted:

End result:

[DanAlbert]

I wonder if the game's AI isn't smart enough to play with skynet. Maybe they only engage active SAMs and aren't getting close enough for them to turn active?

[Mustang-25]

I wonder if the game's AI isn't smart enough to play with skynet. Maybe they only engage active SAMs and aren't getting close enough for them to turn active?

I just reviewed a couple of my tacviews. In one of them, the AI SEAD engaged SAMs that were in the area but not their fragged target. In another, they performed similarly to the OP where they just turned straight for their egress point. I'll do more testing to see what happens.

Would making it a strike target using a SEAD loadout remedy the problem?

[SnappyComebacks]

Would making it a strike target using a SEAD loadout remedy the problem?

Would doing this prevent the SEAD flight from attacking SAMs along the way? As you can see in the map, the target is an SA-11 sat behind an SA-6. I'm thinking that the ideal solution would have the SEAD flight attack both the SA-6 and SA-11 (SAMs along the ingress path and the target)?

[DanAlbert]

I just reviewed a couple of my tacviews. In one of them, the AI SEAD engaged SAMs that were in the area but not their fragged target.

That's the difference between SEAD and DEAD. If you want to hit a target, use DEAD. If you want to protect the package from potential surface to air threats, that's what SEAD is supposed to do.

Would making it a strike target using a SEAD loadout remedy the problem?

Won't hit the target if it moves. Works fine for stationary SAMs.

[DanAlbert]

I'm thinking that the ideal solution would have the SEAD flight attack both the SA-6 and SA-11 (SAMs along the ingress path and the target)?

SEAD probably shouldn't waste ammo on targets that are already suppressed because then they may not be able to suppress targets that actually are threats. Apparently they aren't doing that anyway, but I think we need a different fix.

[Mustang-25]

That's the difference between SEAD and DEAD. If you want to hit a target, use DEAD. If you want to protect the package from potential surface to air threats, that's what SEAD is supposed to do.

Ah ok, noted. I must have overlooked the update where you guys started differentiating between SEAD and DEAD within Liberation.

What about adding a short orbit time that overlaps with the package TOT? So instead of just hitting the ingress waypoint and immediately pivoting to egress, it will stay on station for say 5 minutes to engage SAMs that pop up when other elements of the strike package trigger them.

[DanAlbert]

I must have overlooked the update where you guys started differentiating between SEAD and DEAD within Liberation.

Have been doing my best to keep https://github.com/Khopa/dcs_liberation/wiki/Mission-planning up to date, btw :)

[SnappyComebacks]

I'm thinking that the ideal solution would have the SEAD flight attack both the SA-6 and SA-11 (SAMs along the ingress path and the target)?

SEAD probably shouldn't waste ammo on targets that are already suppressed because then they may not be able to suppress targets that actually are threats. Apparently they aren't doing that anyway, but I think we need a different fix.

My thoughts were if SAM A is surrounded by SAM B and SAM C, where SAM A is the target of DEAD, a SEAD flight should try to suppress A, B and C. If it only suppressed A, the B and C can fire, and if you suppress just B and C, then A can still fire; both cases seem bad for the packages health, which is why I was thinking that you would want to suppress A, B, and C.

[walterroach]

Tasking I've tried so far: Search and Engage Search and Engage in Zone Attack Group SEAD Escort Follow with an Attack Group trigger.

The only effective SEAD method I have found so far is DEAD with SkyNet enabled.

Possible solution is to route the SEAD tasking to DEAD when SkyNet plugin is on. Not ideal, but may be the best option unless DCS provides a means to engage groups with radar off with SEAD weapons.

[DanAlbert]

What did escort actually do? I assume it wandered off and became useless? Wondering if https://forums.eagle.ru/forum/english/digital-combat-simulator/dcs-world-2-5/dcs-wishlist-aa/7121311-options-for-alternate-ai-escort-behavior would fix the problem.

[walterroach]

What did escort actually do?

Just reviewed my notes on this, I didn't use escort, it was strictly. SEAD task (I had it written down as SEAD/Escort). It depended on the run, sometimes they engaged and wandered off, sometimes they went to the egress waypoint directly. I think an ED fix from that thread would fix it, the issue starts for both case behaviors once the escorted flight is engaging units and off it's flight plan.

[jeetsukumaran]

I've got a couple of ideas of how we might be able to help the AI do their job with skynet enabled. Ideally, the fix would come from ED. But in the mean time, maybe we can think of something like the following:

Right now, the ingress waypoint is the where the action to attack target is given. If the SAM site radars are not active when the flight reaches the ingress waypoint, the flight just continues on their route and goes home.

Could we have, at least as an option, the ability for the SEAD/DEAD flights to orbit at their ingress points until some conditions are met:

(1a) duration >= T (e.g., 20mins); Can be selected to coordinate with TOT or ingress time of different package. It is easy enough to coordinate based on TOT. But what we have to coordinate here is TOT of one flight with the "ingress" waypoint time of the other. (1b) All missile ordnance expended. (1c) Bingo fuel

I think this might work to for the SEAD/DEAD flight to stay on station until the strike flight ingress triggers the SAM site radar activation, which the SEAD flight can then react to and suppress.

Might need to consider SEAD's CAP escort if any have the same orbit conditions.

[DanAlbert]

(1a) duration >= T (e.g., 20mins); Can be selected to coordinate with TOT or ingress time of different package. It is easy enough to coordinate based on TOT. But what we have to coordinate here is TOT of one flight with the "ingress" waypoint time of the other.

I think the way to do this would be to match patrol departure time to the egress time of the package.

I'm not sure how much good it would do, since the SEAD flight might be too far away to actually protect a strike flight, but won't know until we try.

[jeetsukumaran]

I think (or, actually, hope) if the SEAD flight is at their ingress holding point (which is currenlty ~40nm? from the target) while the strike is at or close to their target waypoint (which will be on top of the target with most munitions), then the strike will trigger SAM's radars and the SEAD will "see" the target and launch the HARMs. With skynet, that should I think do the job of suppression if the radars then shut down because the of the HARMs in the air?

For this, the SEAD ingress time + orbit duration must span/cover the time that for BOTH the strike ingress time and the strike TOT.

So if the strike route has the following times:

join: t+10 ingress: t+20 target: t+28 egress: t+30

The SEAD/DEAD must have:

join: t+9 ingress: t+19, orbit until t+30 egress: t+30

[jeetsukumaran]

Setup

So, I spent the whole afternoon experimenting with SEAD vs DEAD and trying ways to set it up so that it all works with Skynet enabled.

[DISCLAIMER: Yes, in an ideal world, this fix would come from the DCS side, as the problem is on the DCS side with how escort/SEAD taskings are executed. But honestly, I don't expect the DCS fix to happen anytime soon ... or maybe at all. So I thought it might be worth investigating on how to get it to work with the hand that we are playing with!]

Target was an SA-10 site.

Base package was:

• 4-ship Viggens as STRIKE
• 2-ship F-16's as ESCORT
• 2-ship F-16's as SEAD
• 4-ship F-16's as DEAD

(0) Base Liberation Generated Mission

• Results:
  • 2-ship SEAD launched all their HARMs
  • 4-ship DEAD went home will full ordnance
  • All strike killed by SAM's

(1) Modifying with DEAD Flight Orbiting

• This picks up on my idea I posted on the GitHub Issue #374. For the DEAD flight:
  • hold orbit removed,
  • ingress time fixed to ingress time of strike (10:17:02)
  • orbit at ingress point to cover ingress-egress time span of strike: 10:17:02 to 10:29:09 (i.e., set stop condition = time > 10:29:09)
• Results:
  • Same as previous: DEAD flight did not fire missiles
• Remarks:
  • Main reason seems to be that DEAD flight was too far away and facing the wrong direction when the SAM site went active.

(2) Modifying with DEAD Flight Orbit Routes

• Instead of orbiting at HOLD or any other waypoint, use "switch to waypoint between "ingress1" + "ingress2" (new waypoint). Should probably be called "SEAD racetrack start" "SEAD racetrack end" and 2. Made sure to orient the "SEAD racetrack end" in direction of SAM site. Note that:

  • Both waypoints have "attack group" as a waypoint action, so the AI is "always looking" for targets
  • I did not create a way to break out of the waypoint loop. Some simple Lua should do it (if time > egress time of strike OR missiles remaining < 0, then switch to egress waypoint)

• Results:

  • WORKS! .... most of the time!
  • Again depends on whether or not the aircraft turn or are otherwise facing the SAM site while it is active. By making sure the racetrack points are close enough to each other, so that it switches to the SAM-site direction often enough, this is a decent bet, but still a gamble.

Analysis

• So basically, with (2) an AI package wiped out an SA-10 site a lot of times, whereas with (0) and (1) it did so NONE of the time. Until DCS fixes it's AI's, it might be worth for Liberation to generate mission plans for DEAD flights to use special orbits such as these? Still not very reliable, as sometimes the radars come on and go off while the flight is facing away so when they turn back they do not see the radars. Other times, even if they do, by the time they have turned back in to see the radars, it's too late for the strike package --- they've been shot down!
  • Maybe some creative orbits using multiple points that place the route so that the SAM site is in view most of the time might work?
  • Alternatively, but far more complexly, setting up the flight to do "chainsaw" pattern (which would REALLY help CAP AI's as well) would be good.
• What I find curious is why the 2-ship SEAD flight usually fires its HARMs?
  • I thought it might be because the 2-ship is turns around more quickly? But even reducing the DEAD to a 2-ship has no effect.
  • What's weird is that if I set the 4-ship DEAD to SEAD (in Liberation) instead, they STILL do not fire the HARMs!
  • So I think this is just luck of timing, based on when the flights take off with respect to each other. In all variations, the package takes off in the same order: strike takes of first, followed by the CAP etc. I think that the 2-ship SEAD just happens to be always facing the right direction at the right time to pick up the SAM radars when they go active.
  • Another possibility is that the DEAD flight is waiting for the SA-10 radars to go active whereas the SEAD reacts to any radar so the SA-15/19 SHORAD triggers it? (I don't think this is it, though, because the orders are to attack the group and the SHORAD are part of the group.)

Another Idea

• I think this will work, but the cost in aircraft might be high: have the DEAD flight set up as "STRIKE" with HARM's (and a TARGET waypoint over the SAM's that they are flying toward). So they will close in on the radar site, and be both the trigger and the hammer. I would make this a different mission type, and call it "Wild Weasel".

[walterroach]

589 places a waypoint over the target for SEAD flights. This greatly improves their behavior with Skynet enabled.

DEAD flights still sometimes do not engage with SkyNet enabled, but in my testing behave well with it off.

[jeetsukumaran]

Note that you will have to change the ingress waypoint action from "start task / engage group" to "start enroute task / search for and engage group".

This works for DEAD. Even with skynet.