FlightControl-Master / MOOSE

Mission Object Oriented Scripting Environment (MOOSE) for lua mission scripting design in DCS World
http://flightcontrol-master.github.io/MOOSE/
GNU General Public License v3.0
290 stars 95 forks source link

AI_A2G_DISPATCHER: AI air to ground offense dispatcher. #1048

Closed FlightControl-User closed 4 years ago

FlightControl-User commented 5 years ago

Let's discuss a new module, called the AI_A2G_DISPATCHER.

I see the scope of the mobule as follows. This would work also with detection, just like the AI_A2A_DISPATCHER. But this time, it would dispatch air forces to engage with ground detected targets. This is a bit more complicated, because now there are essential complexity factor to be taken into account. Let's list them below.

FlightControl-User commented 5 years ago
  1. Payload composition based on threat level and target type. As you know, the detection will report an important element; the threat level, where 10 is a high threat and 0 no threat. However, we wanna make sure that the right payload is defined for the right threat level. For this I suggest we allow the dispatcher to define different template types, based on threat level (ranges). For example,
    • If threat level would be from 8 till 10, we engage with Kh-58 or other anti radiation missiles.
    • If threat level would be from 7 till 3, we engage with anti-tank payload composition.
    • If threat level is from 0 to 2, we engage with mass destruction bombs payload composition.
FlightControl-User commented 5 years ago
  1. Another complexity is air superiority. It is a waste of resources to dispatch helos or ground attack planes to a target when the threat to be shot down is high. The concept of air superiority is a parameter in the equation. Depending on the distance to target, distance of nearby airborne threats, type of airborne threat (threat level) and most importantly, tactical urgency to eliminate and clear target areas to ground attackers, the dispatcher may or may not allow to dispatch an A2G attack.
thebgpikester commented 5 years ago

Constraints are, as I see, the DCS "role" eg CAS, anti runway, bombing, pinpoint strike, SEAD and then Loadout. You would have to be able to task based on a template that is capable of performing the specific action. If the template doesn't have the required loadout there is trouble. So as you say, matching template to response. Perhaps this could be manually decided by the User? SEAD, CAS templates would not go up against true fighters?

You could call distances from target on detected air presence, it get's quite complex here. What type of air presence? is it known? Is it realistic to know exactly how to scale that threat because 1 Hornet CAP might have radar missiles, another might not, as is the nature of multirole aircraft now in DCS.

I think any approach could never be fully automated so an element of User acceptance to threat could be built in with functions...some sort of risk acceptance, like "Allow CAS to launch whilst CAP is within 20nm" as a user setting? I'm spitballing thoughts without solutions.

FlightControl-User commented 5 years ago

Good points. The challenge is indeed to match the correct templates based on the detected target composition, air superiority, distance and most of all, tactical urgency.

FlightControl-User commented 5 years ago

Would you suggest the players to influence the dispatcher decisions using some sort of menu?

FlightControl-User commented 5 years ago

We could locate the menu on the command center.

Delta-99 commented 5 years ago

You can have the user define different template sets for the different threat levels or roles types required.

If you have a menu for the players to influence I would design it so that it still works without. So, maybe dispatcher makes default decisions but the uses has a way to modify those defaults or influence them in some way via menu commands.

Mechanist11 commented 5 years ago

Few thoughts that might worth to look into.

So we have 3 main types of A2G warefare, strategic, tactical and "operational" Strategical is usually 1 week ahead of current events Tactical is 1 day ahead of current events And "operational" is reacting to current events.

Looks like we might need the last two as strategical decisins will require servers that runs for month which will not be a case in the near future.

Therefore the two main types of A2G events will be prepalnned and on-call events.

Preplanned is pretty straight, you got recon data, schedule a strike and go. Usually takes place 50 kms behind the actual frontline. This cound be pinpoint strike, or aerial bombardment for staic targets like infrastructure or force massing grounds, or could be armed recon aginst trains, or columns. Also it is constantly replanned usually based on resources and recon data updates. Operational events might lead to divert the strike package from a pre planned target to an on call target if there are torrop in contact but no on call assets to respond. Also the flight are never leave without a secondary target which are in a low intensity area or have lower tactical value. If the primary target is no reachable due to air supperiority, air defence or weather conserns they need to have a target to drop their ordenance as usually they are loadaed with more ordenenca that they can land with.

"Operational" or on call A2G events are also simple. You got flight round o clock airborne with different munitions and profiles. Like SEAD or CAS. These planes take of, loiter and waits fro the call with troops in contact. Those flight are never diverted to preform preplanned strikes or BAI behind enemy lines. However loiter times can be defined in two ways. In an open hot conflict when you expect several troops in contact situation if the loiter time is expended then they need to return to the base. In this case the weapon load is lighter allowing the flight to carry home ammunition. If you don't expect to have troops in contact because you either not attacking or in a low intensity conflict then the loiter time is shorter and then the flight is diverted to a frce recon or killbox type of mission on the frontline to search for argets of opportunity. Usually they are loadid with more munition they need to drop before returning to home.

Question of air supperiority: Now that is a tricky one, air supperiority is a multi level topic but can devided into several states: (From friendly point of view) - No air supperiority: Enemy has the ability and resources to provide to control the total amount of airspace over the entire conflict area including frontline, tactical battlespace and stratigical battlespace. - Partial air supperiority: The enemy has the ability and resources to provide and maintain control over limited area of airspace. - Contested air supperiority: The enemy does not have the resources to maintain control over a limited area, They can only take or maintain control for a limited ammount of time. - Total air supperiority: The enemy does not have the ablity to take control a limited amount of space overt the entire operational area.

Also air supperiority incorporates elements like air defence cover so not just fighters.

The above mentined are very hard to implement.

Planing of A2G is simple if you can define the air supperiority level:

Mechanist11 commented 5 years ago

What to avoid:

Avoid on call strike for troops in contact package spawns from ground. Mission planning and preparation, loading fuel, munition, programing mission computer, preflight checks briefings takes hours. Can be done in DCS but entirely unbelievable. Always shoot for takeoff patrol and then on call.

Preplanned strike always use one pass, even PGM and guided munition drops. Drop and go.

Loiter time is associated with employ radious. Empoly radius is usally the distance the planes can reach in 10 minutes. So loiter time is 25 minutes shorter than the bingo fuel level from the loiter area.

FlightControl-User commented 5 years ago

This is exactly the inputs I needed. I'll go with that this evening to try to get something implemented. So for airborne defenders, hold position, then attack upon command. Target to be reachable in 10 minutes. I'll see what I do with takeoffs from airbase. Your comments on the needed prepare time depends. In a cold war yes, but what on a scramble situation and when targets are known to be coming? Just a thought ...

Mechanist11 commented 5 years ago

You don't really scramble CAS. In hot war scenarion you have like 10 CAS flights on station in the air near the frontline and order them to attack on call. If they don't get tasked in their station time they go home, and they have another flight to rotate them. So Takeoff-Loiter(on station)-CAS(on call)-RTB. You need to define how much CAS flights needs to be on station at one time and you need to rotate them.

Mechanist11 commented 5 years ago

Also about helicopters, there are entirely different breed. So we need a dedicated logic flow for attack helies.

Ever wondered why there are like 5 types of attack helos in the past 50 year? Beacuse they are not so flexible... In DCS they are stripped from their bigest advantage. Hiding. If an attack heli is detected in a 80s, 90s environment they are good as dead.

However there are two kinds of missions in DCS they are still usefull:

Escort offensive groups is prety self explanatory, you assign the choppers to offensive groups Battlefield survailence is a bit trickier. It is basically defence combined with recon area. The area is very limited due to their speed and replacing and rotating of these groups are more difficult to scheduled based on their base location.

Mechanist11 commented 5 years ago

Sven,

I read throught the documentation for A2G Dispatcher.

The overhead concept is not suitable for CAS activity.

Difficulties with overhead concept for dispatching groups:

CAS squadrons can be depleted within an hour whit that concept, every detected groups or sets will trigger a takeoff or a depart from patrol zone. This means if enemy is making advances in waves the first wave will be over handle and the second or third wave will have no units to respond.

I'll explain how to set up and effective CAS squadron in the example above.

I have 24 F-16s armed with 6 mavericks each and 2 fuel tanks for extended loiter time. The F-16s have 30 minutes loiter time on patrol I have 4 AO-s to cover I have 1 patrol zone The patrol zone is 10 minutes away from the AO-s The patrol zone is 60 minutes away from the Airbase I have the F-16 squadron. Enemy is attacking in wave in all AO-s simultaniusly to scatter my resources. Refuel and rearm takes 1 hour

How to set up the patrol?

The weakest point i have is the time I have to spend to reach the patrol zone. 60 minutes so I need to plan for this weakness. First i need to calculate the worst case mission time consumption: To patrol zone + Max loiter time + max reaching the AO + Execution of mission + back to the patrol zone + back to base 60+30+10+10+10+60+60 = 240 minutes This is the time I'll retrieve my planes With rearm and refuel I can dispatch these planes again in 4 hours. This is my weakest point.

Now I have 24 planes, each group consist of 2 planes so I need to rotate 12 groups. The equation is then simple: I have 30 minutes to cover this is the useful time. I got 12 flights, 12*30 = 360 minutes to provide and i can rotate the flight is 240 minutes I have 360/240 time ratio which is 1,5.

What is this 1,5 means?

A group can enter and leave every 15 minutes so theoretically I have 2 flight always at my disposal which is not so bad. BUT! There is a bug BUT. I'm not counted with casualties, or failures so I need to add to the equation some room for safety and replacement. I'll count with 75% rate then.

So I only have 9 groups to schedule and not 12. In this case I only have 270 minutes of useful loiter time and I need 240 to provide the constant present of at least one group.

In conclusion. It sounds great to have 24 F-16s at my disposal for some CAS, but in reality I can only provide 2 planes for 30 minutes of action with only 12 missiles and that can destroy about 8 targets, and I can only loose or otherwise disrupt 6 planes to provide this round o'clock. That is pretty weak figure...

This is pretty easy math not counting with lot of things but can be used as a base model.

What parameters could be useful for Moose usage:

LoiterOnCallTime - define the availability for missions in seconds ToPatrolZoneSpeed: - define the speed the aircraft use to reach the patrolzone ToEngageZoneSpeed - define the speed the aircraft use to reach the AO PlanesPerGroup - define the quantity of aircraft in a CAS group AvailabilityRate - define the rate of available aircraft 1 is 100% 0 is 0 % RefitTime - Time it takes to refit the aircart with ammo and fuel and to be available to dispatch again

The rest can be calculated, and the Moose will calculate a solution. It will define the time based on set speed and calculated distance, and then give you a solution.

In the info menu you'll see a message that XY squad can provide 1 group at every 30 minutes over Z patrol zone for 30 minutes, which supports AO1; AO2; AO3; AO4

thebgpikester commented 5 years ago

Some observations. Overhead is pretty much a useless concept for this, yes indeed. I think it should match an AREA in a 1:1 flight ratio. Thus you design the response by the number of AREAS.

CAS is such a generic MOOSE concept and drifts from reality. We only define the names of these concepts by the position of friendlies or the type of target in MOOSE.

We miss the terms of SCAR - Strike Coordination and Armed reconnaissance which is NATO language for managed 'patrols' in specific areas, called Restricted Operating Zones. It fits very easily in MOOSE as a patrol in a fixed area. It launches only with air superiority like most post ww2 strategy but not sure we should be over-managing the AI intelligence here, often Mission designers seek conflict and this can be up to them.

FAC(A) - Forward Air Control (Airborne) is really needed in Dispatcher since the entire thing is driven by DETECTION. Whilst in a CAS situation both troops are near each other, who in fact detects for BAI tasks? lack of recon has to be made up by the mission designer currently. A2A_Dispatcher has EWR networks so we have a gap here in logic.

I see the current BAI and SEAD tasks as just overlapping different types of Strikes, just with different target types. It might be useful to keep them split, just so squadrons that can do dedicated SEAD can actually be separated from CAS platforms.

I think both Dispatchers need a max airborne setting that can stop spawns. Right now GCI spawns to meet need - without limit, Same as A2G non patrols. It should be halted in case of ATC issues spiraling out of control.

Take off from runway/parking/airborne and Landing. I don't know where to start. DCS is so painful here that I dont know where to begin. I think any work and time spent here is worthwhile to improve responsiveness. Like automatically recognising traffic jams and changing spawn type on the fly in case of issues (like the massive merry-go-round circles above airports or deleting aircraft that have had an RTB status for more than 10 minutes in the same airport zone.

The foundation certainly works, no denying it, right now, it's workable to create brilliant missions. The main improvement points are the removal of redundant designs between A2A and A2G dispatchers, tighter numbers control, adding needed features and adjusting the flight behaviour to be a little closer to real operations without preventing easy fun play in DCS.

FlightControl-User commented 5 years ago

Guys... The concept works. We can only add stuff to it.

Get Outlook for Android

On Fri, Nov 16, 2018 at 5:17 PM +0100, "thebgpikester" notifications@github.com wrote:

Some observations.

Overhead is pretty much a useless concept for this, yes indeed. I think it should match an AREA in a 1:1 flight ratio. Thus you design the response by the number of AREAS.

CAS is such a generic MOOSE concept and drifts from reality. We only define the names of these concepts by the position of friendlies or the type of target in MOOSE.

We miss the terms of SCAR - Strike Coordination and Armed reconnaissance which is NATO language for managed 'patrols' in specific areas, called Restricted Operating Zones. It fits very easily in MOOSE as a patrol in a fixed area. It launches only with air superiority like most post ww2 strategy but not sure we should be over-managing the AI intelligence here, often Mission designers seek conflict and this can be up to them.

FAC(A) - Forward Air Control (Airborne) is really needed in Dispatcher since the entire thing is driven by DETECTION. Whilst in a CAS situation both troops are near each other, who in fact detects for BAI tasks? lack of recon has to be made up by the mission designer currently. A2A_Dispatcher has EWR networks so we have a gap here in logic.

I see the current BAI and SEAD tasks as just overlapping different types of Strikes, just with different target types. It might be useful to keep them split, just so squadrons that can do dedicated SEAD can actually be separated from CAS platforms.

I think both Dispatchers need a max airborne setting that can stop spawns. Right now GCI spawns to meet need - without limit, Same as A2G non patrols. It should be halted in case of ATC issues spiraling out of control.

Take off from runway/parking/airborne and Landing. I don't know where to start. DCS is so painful here that I dont know where to begin. I think any work and time spent here is worthwhile to improve responsiveness. Like automatically recognising traffic jams and changing spawn type on the fly in case of issues (like the massive merry-go-round circles above airports or deleting aircraft that have had an RTB status for more than 10 minutes in the same airport zone.

The foundation certainly works, no denying it, right now, it's workable to create brilliant missions. The main improvement points are the removal of redundant designs between A2A and A2G dispatchers, tighter numbers control, adding needed features and adjusting the flight behaviour to be a little closer to real operations without preventing easy fun play in DCS.

— You are receiving this because you were assigned. Reply to this email directly, view it on GitHub, or mute the thread.

Mechanist11 commented 5 years ago

Some ideas for BAI and SEAD just to have the ideas together.

BAI dispatching:

This should not be driven in by detection, in fact all the dispatching should be resource available and coverage needed based.

At least two different types of BAI-s should be distinguised:

I don't know in depth the detection logics currently but we should introduce if we don't have it currently the following principles in the detection.

Last known position Information age Estimated target position

Last known position and information age is starith forward and can be easily implemented if already hasn't

Now Estimated target position can be tricky but manageable in some degree. You take the last 3-5 detection coordinates, define a speed and heading and extrapolate this data with a time factor. This is for moving targets, for stationary the last known and estimated will be the same. As time gose forward the estimation value decerases so you need to enlarge the search area.

Here is a picture explaining better.

kep

You need to define how much error in recon you're willing to take in estimation and in info age. After this expires the target is lost.

Also If you find the target agin in the suspected zone, the info age has to be reset, anyhow the detection entity should be the same as tasking is based on the detection entity.

Anyhow, both types needs to be scheduled and not called upon when detection happens. Should work as CAS described above.

Regarding SEAD.

Should have thre types.

Same as BAI but with a SEAD partol ability when the SEAD is perforemed like CAS, so patrol, loiter and then engage if called.

Mechanist11 commented 5 years ago

Hello Sven,

Thought up some more pragmatic CAS system based on our last night talk.

CAS Pragmatic approach.pdf