AI A2A Dispatcher (CAP and QRA)

[132ndNeck]

Would it be possible to set up automated Enemy (RED) CAP and QRA(GCI) in the following way:

CAP
CAP racetrack patterns in the yellow zones

QRA (GCI)
Forward staged aircraft in the yellow airbases + Kerman and Shiraz

(more details to be added later)

[thebgpikester]

I wrote a prototype today and found that there are some bugs with moose code to be fixed that really cause a lot more traffic than needed. The caps wont refuel from tankers, so the 150nm they drive to station ends up them coming right back again. looking at that with FunkyFranky. Otherwise it still works, just not optimally.

[132ndNeck]

If they are able to use AAR , maybe have the AAR track in a racetrack in the intersection between the 4 Air Defence Zones?
I till primarily be the zones in LAR, Shiraz and Kerman that will be used, with Bandar Abbas only for Mission 10. So that can be skipped.

[thebgpikester]

ok, the only problem I really see really is with Lar and Jiroft. It's like Beslan, few parking spots, the planes have to backtrack singley in twoships, thus traffic jams which render the airfield unusable (and creates circling planes and eventually lag).
I'd recommend to fill Lar CAP from Shiraz, but I'll give that a go, and see how the refuelling is.
The "zones" and intercepts are handled automagically by range to the nearest free unengaged fighter on station or handed off to a GCI nearest. So it's a bit more complex than your diagram "sectors".

Previous issue has been overcome.
The network/sstem described is pretty powerful! Beware! :D

[thebgpikester]

So in testing....
I spawned 4 tomcats on the west and the east immediately to see what would happen.

WEST SIDE
Four F-5's attempted scramble from Lar since no one else was closer.Two of the Lar GCI airborne versus 4 incoming tomcats in time, but they take ages because of backtracking. This held up the response of the Shiraz Tomcats close enough by. Tomcats shot them all down and the two Shiraz Tomcat's stepped in. Lar created another GCI in the meantime. This was enough to kill all the blues.

EAST SIDE
The F-4's from Bandar Abbas were airborne so they took on the 4 tomcats that side. They lost badly, then Jiroft began spawning interceptors. The Tomcats got caught up in airdefences, then Kerman CAP (Mig29s) decided to jump in to balance the numbers. and the east blue tomcats all died.

In the end there were about 10 red tasks.

There's nothing I would try to fix. I would probably reduce the numbers if anything, it can get a bit excessive, but it's only doing what it's asked. Air to air refueling is first come first served. When I watched the tomcats won and the Mig29's were unlucky enough to have to go to Bandar Abbas, nearly falling out of the sky on 2% fuel.

[thebgpikester]

Timings.
Takes about 35 minutes to get all the red CAP's on station.
First refuel is about 2hrs in, if no engagements
After the test about, which began very fast, it was 1hr 15mins before all CAP's were back on station again.
I can't seem to slow it down any. I will work on that with Frank. Some combination of the above will certainly automate complete air coverage, the minor details don't really matter, the major detail is that there are plenty of planes to counter incursions and they will.

[132ndNeck]

This looks really promising. Thanks for your effort!

Regarding LAR and JIROFT. What I was meaning with having those 2 airfields, were that the Iranian forces forward staged a 2ship to each airfield. And IF needed it would launch those QRA (Quick Reaction Alert ) fighters. It would not have any other aircrafts there (but of course aircrafts could land there if they were low on fuel.
It is intended for a way for the Iranians to have increased responsiveness, byt having fighters forward staged.

A reasonable alert time, is that it will take 15 minutes from they are alerted until they are airborne.

I am not sure if this is feasible or not with the scripting? But it will alleviate what you wrote:

ok, the only problem I really see really is with Lar and Jiroft. It's like Beslan, few parking spots, the planes have to backtrack singley in twoships, thus traffic jams which render the airfield unusable (and creates circling planes and eventually lag).

Also, it will help reduce the numbers a bit, as it will only be a 2ship at LAR and a 2ship at JIROFT?

[132ndNeck]

I have a tentative enemy squadron setup like this:
https://132nd-vwing.github.io/OPUF-Brief/Docs/Enemy/Enemy.html

But please let me know if you think I should adjust anything. I can both add or remove squadrons as we see needed.

[thebgpikester]

I can set the squadron strengths at Jiroft and Lar to 2 each. Not sure if you want a way to count them all, I could add it, but since the mission is launched weeks apart it's easy to tweak numbers prior to launching. Plus Iran would backfill and move forces around.
The squadrons you setup (thanks for the link) I almost guessed at. Since they can and would move, the best concept is the cheap F-5 interceptors forward deployed and dispersed, and anything valuable sat in Shiraz as it currently is and Kerman. The only thing to note is that i've read in a few places there is a half sqn of F-4 at Bandar Abbas intl.
Forward deploying would be a real thing, I can add two ships to places like Kish, Jask and Abu Musa as GCI only. The existing CAP's are quite hefty for a 24/7 approach but I'm assuming we are in a state of extremely high alert and maximum output. Engineering wise not sure how many days they could keep that up for!
I'll add the squadrons at the top of the script so you can play with numbers and tweak it towards the squadron layout you have. should be done by today and you can watch it.

[132ndNeck]

1. No reason to count them. As the server is not running 24/7, but on a mission to mission basis I think that is good enough.

2. Bandar Abbas will only be relevant for the next mission, after that it will be a blue airfield, so Shiraz and Kerman are most important

3. Yes, I was planning to write some more about the CAP setup, I don't think it would be possible to run with 3 CAP's airborne at any given time. Have 1 or 2 of the CAP's at any given time. And some randomisation of which CAP is active?

4. Why should we use ships for GCI? Is that better than EWR's or other units? (asking because I do not know)

[thebgpikester]

1. OK, figures will be for mission start. You can then tweak the same file for numbers. It could happen later you could reduce numbers to the point of unavailability if you choose.

2. OK.

3. Needs discussion. Yes, it's possible, im wondering though if the caps then have to reposition to cover, which adds a lot more lines. Because it's going to then be not 1-3 caps but also three configurations. Doable, I would just like to know the logic in words.

4. I meant to say "two-ships" :) as in aircraft pairs :)

[132ndNeck]

1. Sounds good.

2. Copy. will answer in next post.

3. Copy. Yes, that is intended for LAR and JIROFT.

• JASK (but then only reacting on activity taking place on the Eastern side and closer to JASK, 100nm within JASK for example? (So basicly only reacting when someone is tasked to do stuff there. So the JASK QRA do not interfere with other activity in the "main" battle area. (Just to make it easier to balance when making missions and setting up events)

[thebgpikester]

Yes, all GCI's work both independently and together in terms of range to an untargetted intrusion across the border
.
If a GCI is available then imagine it's like an invisible CAP. The air defence network will direct GCI launches when they are closer than an existing CAP. So if you are fighting in say Bandar Abbas, draw a line to the closest CAP that is not engaged or GCI that is ready and that will launch. If it only has two fighters and there are four ships, it would launch 2 from the close GCI and pick two from either a CAP or a GCI next nearest. Thus, it's only covering it's own area, according to one setting.

Beware, if Jask is the only GCI and there's no CAP's or other GCI's, it might supply the entire map! So the limit of "2" is good.

[132ndNeck]

Needs discussion. Yes, it's possible, im wondering though if the caps then have to reposition to cover, which adds a lot more lines. Because it's going to then be not 1-3 caps but also three configurations. Doable, I would just like to know the logic in words.

Ok, to put it more in words:
This script is intended to be the basic framework of "standard" Iranian response. So this is intended for something that they will be able to keep for 24/7 operations for some time.

At any given time, 1 CAP is either operational, or aircrafts are enroute to the CAP zone. This CAP can either be manned from Shiraz or Kerman. The two airbases alternates between who is responsible for the CAP duty.
If a CAP is tasked, then 2 additional CAP's will be launched. However, as these are not alert aircrafts, they will need 60 minutes (random between 30-90 minutes) from CAP is tasked until they are airborne and enroute

Quick Reaction Alert
Both Shiraz and Kerman have their QRA fighters aswell. These aircraft are on a 15 minute alert (15 minutes from they are given a task until they are airborne). For randomness (put this between 7 minutes and 25 minutes). If a CAP is tasked, the QRA flights from one of the airfields will be launched (closest one?). The other is a backup, so if the original CAP flight is shot down, or the QRA flight is shot down, the second QRA flight is launched.

Forward staging
In LAR and at JIROFT there is a 50% chance that the airfield will have a 2ship forward staged. If it is forwardstaged it will have on a 15 minute alert to respond to any threats (GCI). For randomness, set time between 7 and 25 minutes.

CAP specific

• CAP's fly in a racetrack pattern, hotleg toward Blue airfields.
• For randomness, at times aircraft can fly with radar off, and turn on radar when they leave CAP orbit to intercept (when they have recived an order from AWACS or GCI)
• Normally a CAP will be flown by a 2ship. However, for randomness, make a small chance for it to be a 4ship (and if possible, have 2 ac fly to do AAR, while 2 stay at the CAP racetrack when they need to refuel)

Objectives

1. The primary objective is to protect Shiraz, Kerman and Lar Air Defence zone as shown on the first picture in this thread.
2. Secondary objective is to prevent any interference with Iranian AWACS or Iranian Tanker activity taking place somewhere Shiraz and Kerman Air Defence Zones.
   Both AWACS and Tanker's are High Value Units so something the Iranians can not afford to loose.
3. Third, the effect is to prevent any Blue air activity over Iranian mainland, preventing BLUE from conducting CAS, AR, SEAD or Strike missions

Alertlevel
Any blue aircrafts taking off and approaching the Iranian mainland increses the alertlevel (detected either by AWACS or EWR). This can have the following reaction: (can be a random thing, set 30 % for any of the things below to happen)

• QRA (GCI): QRA(GCI) aircraft will reduce their alerttime to 5 minutes.
• CAP: A second CAP can be launched (So 2 CAP's are manned)
• A Escortflight from Kerman can be sent to escort AWACS and/or Tanker?

[132ndNeck]

Beware, if Jask is the only GCI and there's no CAP's or other GCI's, it might supply the entire map! So the limit of "2" is good.

Will it be possible to limit this in any way, so the JASK QRA (GCI) is only used in the JASK area? or will it react anywhere on the map if needed?

[thebgpikester]

OK reality bump! :)
Half of that I can't change in the A2A_Dispatcher module :(
Specifically:

• Sharing CAP duties. Consider them on or off.

I could program a random "switch", but it will have no interaction with the actual events, so if a CAP is shot down and there is a switch you might get instant refill, but it's not checking for anything, purely random.

• GCI timed response. It's not configurable, it's started as soon as there is an intruder detected on radar and given to the appropriate station to deal with. The main contributors of delay are Taxiway layout. In practice it's fairly considerable but can be altered by moving the border further or closer. It honestly works out around the times you stated anyway.

• Secondly, the CAP replenishment. It's all handled internally. There is a check once every X seconds to see if there is a missing CAP from what was set. In reality, if you set this to one hour, the way it is coded, you might hit that check in the next second or the last second of the hour. I've set it for one hour so the median is 30 minutes. It's not configurable with a minimum time sadly :( CAP's are refilled from the same squadron.

• Sensors: Can't control that via A2A_Dispatcher. It's a really good feature suggestion though.

• Tasking when one is engaged: Can't change any of that, A2A_Dispatcher does all the tasking of who and when get's tasked for what intercept. This is the core of the Dispatcher logic. The summary is, it will task immediately and without randomness on the nearest available resource, as soon as it's detected. It will replenish CAP's itself, refuel them and maintain it's initial settings. You can switch squadrons on and off though.

What I can do (fairly easily):

• Mixed CAP size. I could probably create a scheduled tasks that swaps these numbers but its a bit of a pain as it's per squadron. So have to rotate through squadrons and roll some dice.Chances are, when the dice fall, it's all four-ships. RNG is usually horrible :)

• Mixed squadrons at certain CAP's. I can allow Dispatcher to randomise who get the CAP, but each Squadron only has one CAP or has a random pick of as many as you like, either or, no further control or granularity or logic with where that is easily done. Basically you set each squadron up with one patrol point or a few randoms. Randomisation usually messes up here, see notes on RNG above :)

• Forward stations "chance": Can be done once only at the start. Not too hard.

[132ndNeck]

No problem with reality orientation :)
I just come with features I would like, and I know not all if it is possible (but hey, racetrack CAP is now possible, so it is worth requesting :) )

Is it possible / makes sense (cost vs benefit) to request some of the features I have made into the AI A2A Dispatcher for MOOSE? I could create requests on the MOOSE github if you think that might be an idea?

Second, is it possible to use other scripts / combine it with other things to achieve the things I want to achieve?

Of course not a problem if they are not, and are happy with the things that can be implemented :)

[thebgpikester]

Radar on/off should be a worthy request. I think it could be straightforward too and not cost too much time.

A GCI inbuilt delay could be another request. There's absolutely no throttling of responses, it's pretty immediate and never accounts for alert levels, or Squadron tiredness and airframe availability over time.

CAP's being spaced out (properly) could be another request. The current method only gives a time interval for checking.

Tasking... that's fundamental to the entire thing. To change it's behaviour would be to rewrite the dispatcher which was months of work afaik. Difficult to know really because the code level isn't well known to me and even FunkyFranky is trying to learn it, it's super complex. At a functional level, each Squadron is it's own entity and tries to perform it's CAP and replenishment. The dispatcher element only gives one of them a job. Changing that would need some heavy thinking.

Having said that, once it's up and doing stuff, it acts in a way that from the cockpit doesn't seem unrealistic.

[thebgpikester]

OK done. features are:

4 caps, can disable individually at top of script
Each CAP has a station and circular 10nm orbit facing hot where you wanted between 5000 and 9000m altitude
They will attempt refuel from a tanker you place (of specific name)

There are 3 GCI's, Jask, Jiroft, Lar and 2 GCI's for Kerman and Shiraz.
Lar and Jiroft have two forward deployed F-5's that have a 50% chance of being there for the mission duration.

Every hour Kerman and Shiraz swap who does the CAP, starting with Shiraz

Every hour the amount of planes in in the cap shuffle from 1,2,3 or 4 planes, weighted heavily towards 2 planes in a CAP.

The rest is just dispatcher working as it does, targeting bandits crossing the border with whatever it has available.

the Red awacs and tanker I put in, and move them a bit further north (blue can rush too early)
You need to check the template names; "Bogey-airport" there is a border called IranBorder which is helicopter drawing the border zone and the four ZONES. Turn the Tactical Display off and delete the F-18's called "deleteme", for production.

[132ndNeck]

Sounds very good!

1. Would it be possible to have the CAP's do racetracks, and not orbits? (20nm legs)
2. Is it possible to change the amount of aircraft so it is either a 2-ship, 3-ship or 4-ship? and not singleship?
3. At JASKm how many planes are there? (Should only be 2 forward staged aswell)

[132ndNeck]

@thebgpikester Where is the file?
Just so I can add it for the mission on Sunday so we can test it :)

[thebgpikester]

OPUF_1.9.0.107-mike.zip

sorry wasn't watching this, too many balls in the air. Rename to .miz.

This has A2A_Dispatcher as requested. I had another look, removed any testing aircraft I was using. Let me know for any questions with a ping pls :)

[132ndNeck]

Thanks!
I have made changes to my .miz file, so I will need to import it into my file.

Can you confirm the only thing I will need to add 132ndFramework.lua
,create the 3 CAP zones, Do Script file (132ndFramework.lua) and stop messaging (Do Script A2A Dispatcher?

[thebgpikester]

Copy and paste all names, case sensitive:

ZONES to check in miz:
"CAPshiraz"
"CAPkerman"
"CAPlar"
"CAPshiraz"

Late Activated Helicopter Group name for the "trespass border" Must make a shape. Works well on the 12nm international border or whatever you want.
"IranColdBorder"

Late activated Plane groups in correct skin/weapons for what you spawn
"Bogey-Shiraz"
"Bogey-Lar"
"Bogey-Kerman"
"Bogey-Abbas"
"Bogey-Jiroft"
"Bogey-Jask"

Check the Iranian refueller is called this:
"IranRefueller"

A2ADispatcher:SetTacticalDisplay( true )
change to :
A2ADispatcher:SetTacticalDisplay( false ) for productuion (line 46)

[thebgpikester]

[132ndNeck]

Thanks!