search

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
291 stars 94 forks source link

AWACS Alpha (0.0.18) Discussion #1715

Closed Applevangelist closed 2 years ago

Applevangelist commented 2 years ago

Discussion AWACS Alpha 0.0.2

thebgpikester commented 2 years ago

AI Considerations: Player dispatching AKA "the mission"

Scenario1: AI CAP on station, enemy planes approach (something?) within X miles Scenario2: Player CAP on station or assigned, enemy planes approach (something?) within X miles Scenario3: We don't use AI CAPs and we don't have a player signed in. When do we launch an AI intercept? Scenario4: We Dont use AI CAP but a player is checked in on the ground to simulate scramble. When do we give him a scramble/intercept?

Things to consider.... Anchor zones might equal the threat defence range Multiple anchor zones or cap zones Not having CAP in the config Having GCI Quick reaction How to assign a mission to an AI or a Player. Multple players. Player created Anchor zones via Markpoint? Threat axis (makes for nicer hold points) Different ranges for different reactions Bogey inside X range of X asset like awacs or air base or high value asset.

Applevangelist commented 2 years ago

Let's park the GCI / Scramble features for the moment, maybe later, but may show up as request Human tasking will be preferred to AI

thebgpikester commented 2 years ago

WORKFLOW SUGGESTIONS Expanding checkin as both a functional "Asset" for the AI and an immersion item: Checkin is normally done via a single frequency where flights will authenticate to a controller who will assign them to a a senior Weapons Director in charge of that area. The mission and picture and lowdown are provided, check in frequency is provided and the flight is pushed to a specific controller frequency. This manages multiple traffic into channels that are manageble.

Typically the flow is: Authentication is probably out of scope. The pilots own voice is assumed, so on pressing the 'check in' button the sample conversation flow could be:

"Uzi 1-1, Magic, Radar contact, bullseye xxx/xx at x thousand. Say when ready for Picture." Menu item: "Ready" (can we wipe the other options?) "Picture is (Clean/Single group/2 groups/multiple groups), Track X BULLSEYE 123, 45, Angels 6, HOSTILE, Track X BULLSEYE 123 45 Angels 6, HOSTILE" etc. I dont think it makes sense to try to do any complex PICTURES but I will have a think about if that's even possible. End that with a custom "LOWDOWN" if the mission design enters one for this mission which is a text sentence like "Situation is to execute current no fly zone, say when ready to copy station coordinates" Menu item: "Ready" (can we wipe the other options?) "Uzi 1-1, Magic, New Mission. CAP/Intercept/Scramble. Northings 12345, Eastings 056789, 20 thousand, Hot leg zero four five. Time on station 30"

"Check in with DarkStar on 123 decimal 45"

If planes don't check in with AWACS then all messages should be advisories. For the sake of making a workable script I dont think it's neccessary to put any additional conversation on this channel, but its possible.

At this point player should change channel to the assigned directors channel as a new AI asset. Pictures can now be done away with because they are cumbersome and we can assume tactical control which is a direct realtionship with specific flights. Meaning we can do BRAA's. Services can now be shown on menu like Tripwire, bogey dope, check out. POPUP calls can alert specific players to a new detection inside 50nm.

Assignments/Missions. These as you say can be parked for later iterations but would be seen as AI tasking player.

Targetting: I would see the following directive from AWACS: "Uzi 1 1, DarkStar , Target group track..n BRAA 123 45 angels 6, hot, hostile" Create two new menu items: JUDY UNABLE Put the target assignment on 1 minute repeats. "uzi 11, DarkStar , roger unable/Judy". The AWACS would cease if the pilot uses menu item Judy or unable. The difference is that the AWACS would assign a GCI or alternative flight if unable. This will silence the callouts once the player has the target or repeat until the plane is dead.

Once dead some workflow to get the play back on mission: "Uzi 11, DarkStar , confirmed grand slam, vectors to station 123 45"

Check out: "Uzi 11, DarkStar , roger, check in with Magic on 123 decimal 45, good day/good night, safe flight, thanks etc -removes flight from being tasked

AWACS "Magic,All stations, SUNRISE SUNRISE SUNRISE, Magic" --AWACS takes off and begins service

"Magic, All stations, MIDNIGHT, MIDNIGHT, MIDNIGHT, Magic" --AWACS stops service (RTB?)

thebgpikester commented 2 years ago

Deleted this. Only need to worry about labelling if we program an actual PICTURE with anchoring. Stick to "GROUP" and leave it. There may be additional descriptors of POPUP GROUP, THREAT GROUP, but that's it. Labels are done when anchoring the picture only. Anchoring I will talk about in general.

thebgpikester commented 2 years ago

Using lua Code and MOOSE to describe a realistic PICTURE. For this I studied https://armypubs.army.mil/epubs/DR_pubs/DR_a/ARN33396-ATP_3-52.4-000-WEB-1.pdf A Picture is used to convey the relevant parts of the entire airspace the contorller (and pilots) are assigned to.

The basics of a PICTURE is the CORE INFORMATION. Core information is a simple list of bogeys (and up) bullseyes that groups of planes are currently at. CORE INFORMATION is used when the picture is just not making sense from a tactical or organisation perspective, it just reads out the BULLSEYEs of the top three biggest threat bogeys. It's used when you can't anchor the picture on what looks like a singles groups tactical threat - i.e. just crap flying around.

ANCHORING is when there is a definite groups of interest - the most significant threat is called out and the second two groups are given with relationships to that one, in Range or azimuth. For example, there's ten groups flying around. Two of them are flying towards the awacs together, side to side. This would then make sense to anchor the picture on the most threatening of those two contacts and the callout would be "two groups, azimuth (number of miles apart), cardinal group, bullseye etc..."

After considering the code level there are some simple decisions becoming apparent.

Therefore if we only include CORE INFORMATION in our PICTURES, the PICTURE is very simplified and the following formats and technical work is required:

Basics of a large picture: DARKSTAR, TEN GROUPS. GROUP BULLSEYE 020/25, TWENTY-SEVEN THOUSAND, TRACK EAST, HOSTILE, HEAVY, THREE CONTACTS. GROUP BULLSEYE 270/25, FIFTEEN THOUSAND, TRACK WEST, HOSTILE. GROUP BULLSEYE 290/35, TEN THOUSAND, TRACK WEST, HOSTILE.”

Friendlies, strangers, civilians, non participating flights are not counted in the picture. Groups are aircraft sharing the same 3nm bubble.

The format is "C/S. , GROUP BULLSEYE (zero two five), Twenty-five, Seventeen thousand, HOSTILE, tracking, ID, Fillers.

TRACK Use the track to cardinal function. One exception is you can use CAP or CAPPING, ANCHORED or MANOUEVER, but this is hard to code so here is a suggestion. Capture the heading twice before messaging. If the heading has changed then we are GROUP MANOUVER else we are TRACK NORTH/s/e/w

DECLARATION coding DCS AWACS automatically terms all coalition opposites as HOSTILE. This is done wiht the AWACS TASK and for datalink, the ELPRS task on the AWACS DCS group. It is regrettibly stupid to copy anything else as the datalinks will be marked as hostile by AWACS, rather than ambiguous HAFU. Thus, all contacts are de facto HOSTILE and bandit, friendly, spades, or complex ID cannot be used in game. However, I would not hardcode this into the speech lines because of several reasons, most importantly we could add SPADES, BOGEY and so on in two future cases: 1) When the IFF scripting is incorporated 2) If or when we implement a cold war

FILLER CODING Fillers are additional information and their inclusion or exclusion requires code and effort. Here are some rules: 1) Avoid too many if it expands the message length too much (how much is too much) 2) Order of preference is:

Overall code design There must be a polygon area for the AO for these pictures to make sense in. We have to cut this up so we can make some distinctions of "relevant" and "no factor" This enables us to cut noise from awacs, tankers and such. We need a threat axis. AWACS is a good start but it needs a direction, probably from awacs to an anchor point. We have code for what is and isnt a fighter. We can use this to only zone in on fighters. We can also use this to develop a higher threat, we have that. Remember if we have bombers and fighters mixed we have to list out fighters first and nearest to furthest along the threat axis. picture should be called from menu on demand, and provided on new groups that are relevant like fighters. It's given on check in too. We have to count the awacs groups (not the DCS groups) using INTEL class. These are in the AO which probably shoudlnt be stretched deep to avoid counting support planes. Fighters inside a threshold should then be anchored if less than 3 groups, else read out as CORE INFORMATION with nearest hot one first. We can hardcode the TYPE for the filler at a certain range to simulate NCTR or offboard secret stuff. We have to do a lot of range code. Take the groups that INTEL gives, get nearest, check the third nearest etc. Its goign to be nasty to come up with algorithms that handle the anchoring or go for unrelated core information, but it it can be done its soemthing no one else can do.

Applevangelist commented 2 years ago

Thanks @thebgpikester I'll go through that tomorrow. I have implemented a basic picture and limited to INTEL clusters, with a disctinction in or out of the AO. For the base picture your described most elements are there in code.

thebgpikester commented 2 years ago

The most important thing is that you only need the three most relevant contacts for a core information picture as per the book. The simulation does it wrong, it just keeps saying ADDITIONAL GROUP BULLS...and repeat. The proword additional is not used unless someone is pointing out you missed something. So basically much more simple until you have to pick "which three". I would say the three nearest to the awacs but thats a decision to consider, perhaps three nearest fighters that are also in the AO instead.

Applevangelist commented 2 years ago

Yep. Have a delimitation for that, no worries

dMARLAN commented 2 years ago

Example of a full intercept just for reference (btw this is really exciting to have this developed for DCS)

Example Callsigns AIC = BEAR FTR = COLT

Pre-Commit PRI: "BEAR, TWO GROUPS, GROUP, BULLSEYE 300/50, 25 THOUSAND, CAP, HOSTILE. GROUP, BULLSEYE 340/70, 30 THOUSAND, CAP, HOSTILE."

Commit PRI: "BEAR, TWO GROUPS, GROUP, BULLSEYE 300/50, 25 THOUSAND, TRACK SOUTH, HOSTILE. RECOMMEND COMMIT."

PRI: "COLT, COMMIT."

Post-Commit PRI: "BEAR, 2 GROUPS, RANGE, 20. LEAD GROUP, BULLSEYE 300/50, 25 THOUSAND, HOT, HOSTILE. TRAIL GROUP, BULLSEYE 340/70, 30 THOUSAND, HOT, HOSTILE."

Targeting

PRI: "COLT, TARGET LEAD GROUP. BEAR, MONITOR TRAIL GROUP." PRI: "BEAR."

Tac Range

PRI (AIC): "COLT, LEAD GROUP, 55 MILES."

Meld

AUX: "COLT, MELD."

Sort

AUX: "COLT, SORT RANGE." AUX: "COLT 12, SORTED TRAIL."

Employment

PRI: "COLT 11, FOX 3." AUX: "COLT 11, CRANK LEFT."

PRI: "COLT 12, FOX 3." AUX: "COLT 12, CRANK RIGHT."

Defense

PRI: "COLT 11, SKATE SOUTH, PITBULL, LEAD MAN, LEAD GROUP." PRI: "COLT 12, SKATE SOUTH, PITBULL, TRAIL MAN, LEAD GROUP."

Can get into a lot more depth but that's the rough idea of an intercept timeline.

As for how this applies to a scripted AIC here are the important parts:

Pre-Commit, Broadcast Control, Bullseye Format

Commit, Broadcast Control, Bullseye Format

Post-Commit, Tactical Control, Bullseye Format

Tac Range

Meld

e.g. (PRI) "COLT 11, BEAR, TARGET, POP-UP GROUP, BRAA 050/30, 10 THOUSAND, HOT, HOSTILE" (PRI)"COLT 11."

Other

Gotta run now, but hopefully this helps. It's a very generalized post, if you guys have any questions please let me know, I'd love to help get this up and running. I've been learning this stuff for a long time and have the luxury of knowing both an E2 NFO and a retired F-18 pilot who has helped me understand a lot of this.

The document thebgpikester linked is fantastic, but also give a look at the P-877 ADV E2 NFOTS, it's also Public Release and a wonderful resource for understanding AIC.

dMARLAN commented 2 years ago

Got some more time, for maybe a first edition instead of trying to code an algorithm that will be able to label groups could just start with perhaps "first group" "second group" etc. (for tactical control only, in broadcast control it would always just be "group") then perhaps a future edition could attempt to automatically label groups appropriately.

Comm Menu commands that could be used:

Check-in (would look like this: "BEAR, COLT 11, CHECKING IN AS FRAGGED." "COLT 11, BEAR, ALPHA CHECK BULLSEYE X/Y" "COLT 11, GOOD ALPHA CHECK" ) Commit (Changes the AI AIC from Broadcast control to Tactical control) BRAA/Bogey Dope Picture Separation (By default could be between the first and second groups, or could have a sub menu with a list of all groups in the picture) e.g. "BEAR, COLT 11, SEPARATION SECOND GROUP." "COLT 11, BEAR, SECOND GROUP, SEPARATION 15, 25 THOUSAND, HOT, HOSTILE." Judy (Not really used IRL, but for an AI that could be annoying in some cases, handy to have)

Settings (either in code, or menus) Broadcast Range - Maximum range between a fighter and a bogey/bandit that the AI AIC will consider. Anything beyond this range will be excluded.

Tac Range - Range where Tac Range call will be made.

Meld Range - Range where meld occurs. AIC transitions to BRAA format here. Groups detected inside meld range are considered pop-up groups.

Threat Range - Range where groups are considered threat groups.

Applevangelist commented 2 years ago

Deleted this. Only need to worry about labelling if we program an actual PICTURE with anchoring. Stick to "GROUP" and leave it. There may be additional descriptors of POPUP GROUP, THREAT GROUP, but that's it. Labels are done when anchoring the picture only. Anchoring I will talk about in general.

I have added labels when a new contact comes in from intel. Wrt the below posts question is when to call them out

Applevangelist commented 2 years ago

That’s a lot of information, thanks guys. We need to simplify that somewhat and bring into diagrams to make it work. Note: AI CAP callouts. ATM I only plan to have them on voice for checking in, checking out, arriving at station. Possibly can also add also get a text out when going on an Auftrag, when this Auftrag is successful, and when they RTB (bingo, tos over, winchester, dead/crash/eject) or go back to station. Everything else AIC to general audience and to Player comms.

dMARLAN commented 2 years ago

What kind of diagrams do you need?

Aside from trying to label group names it can actually be fairly simple.

1) AIC in Broadcast Control, Bullseye Format. -> Broadcast all relevant groups, no more than 3, and nothing outside of broadcast range.

2) Fighter activates "Commit" menu option -> AIC changes to Tactical Control, Bullseye Format. Labels groups with "first group" "second group" etc. based on range. This isn't a realistic practice but perfectly usable for a first iteration and less awful than the DCS infinite additional groups.

3) AIC makes Tac Range call.

And that's about it for the generic timeline, AIC can make pop-up/threat group callouts if a group does suddenly appear inside meld/threat range during a commit and there are those menu options to request things from the AIC but they're all pretty straight forward I think.

Applevangelist commented 2 years ago

Example of a full intercept just for reference (btw this is really exciting to have this developed for DCS)

Example Callsigns AIC = BEAR FTR = COLT

Pre-Commit PRI: "BEAR, TWO GROUPS, GROUP, BULLSEYE 300/50, 25 THOUSAND, CAP, HOSTILE. GROUP, BULLSEYE 340/70, 30 THOUSAND, CAP, HOSTILE."

  • repeated every 60 seconds unless there is an important change in aspect.

Commit PRI: "BEAR, TWO GROUPS, GROUP, BULLSEYE 300/50, 25 THOUSAND, TRACK SOUTH, HOSTILE. RECOMMEND COMMIT."

  • AIC will anchor only the highest threat group.
  • AIC can recommend or direct commit.
  • Fighters can call their own commit even without recommendation/direction.

PRI: "COLT, COMMIT."

  • AIC will allow a small pause (5-10 seconds) for fighters to perform administrative tasks such as examples below AUX: "COLT, CHECK TAPES, MASTER ARM." AUX: "COLT, DEPLOY." or "COLT, PUMP" as briefed/appropriate. AUX: "COLT, TAC LEFT, 350, GO."

Post-Commit PRI: "BEAR, 2 GROUPS, RANGE, 20. LEAD GROUP, BULLSEYE 300/50, 25 THOUSAND, HOT, HOSTILE. TRAIL GROUP, BULLSEYE 340/70, 30 THOUSAND, HOT, HOSTILE."

Targeting

  • Fighters will target themselves into the groups, targeting must be assigned no later than the pre-briefed MELD range otherwise the AIC will directively target the fighters.

PRI: "COLT, TARGET LEAD GROUP. BEAR, MONITOR TRAIL GROUP." PRI: "BEAR."

Tac Range

  • At Tac Range, and informative call will be made indicating that MELD is less than a minute away, this call is typically made by AIC, but in the case that AIC does not transmit tac range call, any fighter with SA will make the call (typically the lead).

PRI (AIC): "COLT, LEAD GROUP, 55 MILES."

Meld

  • Meld is the time when radar sanitization is changed to gaining & maintaining radar about the targeted group. If the group was already detected during sanitization then it is only an informative part of the intercept, otherwise "clean" calls and talk ons can be performed.

AUX: "COLT, MELD."

Sort

  • Fighters will sort targets inside their respective targeted group as per their pre-briefed sorting trees. Typically this starts with azimuth sort and requires no comms. If the fighter lead determines an azimuth sort is not possible he will switch to first range then elevation.

AUX: "COLT, SORT RANGE." AUX: "COLT 12, SORTED TRAIL."

Employment

  • Fighters will employ their missiles on timeline.

PRI: "COLT 11, FOX 3." AUX: "COLT 11, CRANK LEFT."

PRI: "COLT 12, FOX 3." AUX: "COLT 12, CRANK RIGHT."

Defense

  • Fighters will defend on timeline and make time of missile last support calls.

PRI: "COLT 11, SKATE SOUTH, PITBULL, LEAD MAN, LEAD GROUP." PRI: "COLT 12, SKATE SOUTH, PITBULL, TRAIL MAN, LEAD GROUP."

Can get into a lot more depth but that's the rough idea of an intercept timeline.

As for how this applies to a scripted AIC here are the important parts:

Pre-Commit, Broadcast Control, Bullseye Format

  • AIC transmits every 60 seconds the most relevant groups using cardinal track directions, and never including more than the 3 most important groups. Based on the pre-briefed ranges, the picture shall be considered "CLEAN" if threats are outside that briefed range. For example, any groups beyond 120 NM from a friendly asset will not be included in the broadcast.

Commit, Broadcast Control, Bullseye Format

  • AIC will direct or recommend a commit by retransmitting a broadcast call, but only anchoring 1 group (still say total number of groups)
  • Fighters can also simply call commit at any time before being directed or recommended.

Post-Commit, Tactical Control, Bullseye Format

  • AIC will give fighters a brief time to complete administrative actions, then the AIC will label the picture in tactical control, meaning group labels are applied, and aspect is now relative to the fighters.

Tac Range

  • AIC will make the Tac Range call at the pre-briefed range.

Meld

  • At Meld range is when AIC will transition to BRAA Format.
  • AIC will typically not talk after Meld except for some exceptions, such as threat groups, untargeted groups, etc.
  • Inside Meld range is where the AIC can now directively target fighters, typically when fighters are dragging or if an emergent situation arises.

e.g. (PRI) "COLT 11, BEAR, TARGET, POP-UP GROUP, BRAA 050/30, 10 THOUSAND, HOT, HOSTILE" (PRI)"COLT 11."

Other

  • AIC will call when groups are passing/crossing
  • AIC will call group maneuvers e.g. "BEAR, LEAD GROUP, BEAM EAST." e.g. "BEAR, LEAD GROUP, MANEUVER." "BEAR, LEAD GROUP, DRAG NORTH."
  • Fighters can request BRAA/BOGEY DOPE at any time. e.g. "BEAR, COLT 11, BRAA, TRAIL GROUP." "COLT 11, BEAR, TRAIL GROUP, BRAA 010/40, 25 THOUSAND, HOT, HOSTILE."
  • AIC will call out arms, which is when a group (contacts inside 3nm of each other) separate. "BEAR, LEAD GROUP, MANEUVER AZIMUTH. NORTH ARM 25 THOUSAND FLANK NORTH WEST. SOUTH ARM 25 THOUSAND FLANK SOUTH WEST."

Gotta run now, but hopefully this helps. It's a very generalized post, if you guys have any questions please let me know, I'd love to help get this up and running. I've been learning this stuff for a long time and have the luxury of knowing both an E2 NFO and a retired F-18 pilot who has helped me understand a lot of this.

The document thebgpikester linked is fantastic, but also give a look at the P-877 ADV E2 NFOTS, it's also Public Release and a wonderful resource for understanding AIC.

Ranges - these are zones so I can get filtering right. What are typical sizes, thinking of concentric rings as easiest example I have atm

OpsZone - 120 NM - all detected contacts are stored by AIC. Considered for picture, sorted by distance to AO center or bulls, max callout 3

AO or TacZone - Polygon or round - contacts in this zone are considered for bogey dope and tasking. Sorted by distance to CAP plane max callout 3

Merged - TBD - when going through the contacts anyway, callout merges

Popup group - basically a new contact callout where the contact is first seen in the AO

Meld range - would only apply to groups where AIC knows they are committed

Declare - AIC will help IFF (dependent on era setting) to identify closest contact to a cap in a 3nm range around the plane. Note - need to come up with a menu so the player can vid and feed back the intel to the AIC.

Applevangelist commented 2 years ago

What kind of diagrams do you need?

Aside from trying to label group names it can actually be fairly simple.

  1. AIC in Broadcast Control, Bullseye Format. -> Broadcast all relevant groups, no more than 3, and nothing outside of broadcast range.
  2. Fighter activates "Commit" menu option -> AIC changes to Tactical Control, Bullseye Format. Labels groups with "first group" "second group" etc. based on range. This isn't a realistic practice but perfectly usable for a first iteration and less awful than the DCS infinite additional groups.
  3. AIC makes Tac Range call.

And that's about it for the generic timeline, AIC can make pop-up/threat group callouts if a group does suddenly appear inside meld/threat range during a commit and there are those menu options to request things from the AIC but they're all pretty straight forward I think.

From a Software Design perspective the FSM does cyclic rounds of functions, so I need to think about a flow of things to be done one after another based on certain states. Player menu requests can bei single events (like a bogey dope call) which however doesn’t necessarily change the data state - but a commit to a task would change a data item and in the next cycle lead to a different behaviour.

So in the base status round we have a couple of things to consider:

Applevangelist commented 2 years ago

Before I forget - has anyone a lua table ready for dcs unit type names to Nato types (Foxbat, Flanker…) conversion?

Ok, I added one myself.

Applevangelist commented 2 years ago

https://en.m.wikipedia.org/wiki/List_of_NATO_reporting_names_for_fighter_aircraft

thebgpikester commented 2 years ago

I think inside a specific zone, we should have a basic state of targeted or untargeted for all red coalition planes. The dispatching and control of the intercepts is a primary AI job that is intertwined with Players. This should work with and without players by default out of the box I think.

TRIGGERS Out of band events that oiccur requiring some action:

Dispatching flow iterate contacts and check for:

Overview: match contacts with a targeting directive to player and AI and dispatch and monitor AUFTRAG for non player.

if the contact in a zone which I have to do something about it at all? is there an existing AUFTRAG in progress on the contact? if the contact already targeted from a prior cycle by an alive group? > issue a BRAA call and break out the loop if there is a human resource (prefered) that is checked in? > Tasking function else No> launch AUFTRAG (intercept)

Player pre commit flow Pre check in we do nothing menu shows options to check in Post check in we add the player to a resource pool and replace check in with check out. AWACS checks his CAP zones, sends mission on station using the existing code

Player Post commit flow (- triggers monitor lives above)

Thats all for now. ssince its very complex and I can't think of everything properly yet.

Applevangelist commented 2 years ago

I think inside a specific zone, we should have a basic state of targeted or untargeted for all red coalition planes. The dispatching and control of the intercepts is a primary AI job that is intertwined with Players. This should work with and without players by default out of the box I think. Indeed a planned feature

TRIGGERS Out of band events that oiccur requiring some action:

* New Enemy plane in the AO area (AO defined by polygon - must not be huge).

DONE for contact saving, listing. Question on how/if to prevent mission designers to create stupid zones ... 

* Existing Enemy plane inside a friendly planes tactical range (e.g. 45nm) This can be an autocommit logic:

* if player and player targeted then issue THREAT call logic

* if player and player untargeted then issue COMMIT call logic

Can be done in the Tripwire loop, messaging depending on what the player & mission/target status is 

* Targeted contact has left AO or VANISHED

  * issue player with a "New mission, return to station" or "INVESTIGATE BULLSEYE 123 45"
  * issue AI with RTB
* Untargeted contact has left AO or vanished

* Targetee (the plane issues with the job of intercepting) is dead > Switch contact to untargeted so the loops restarts.

* certain dead events on any team, I think callouts from AWACS in BULLSEYE format for group bullseye 123 45 vanished would be uyseful for everyone.

right

Dispatching flow iterate contacts and check for:

Overview: match contacts with a targeting directive to player and AI and dispatch and monitor AUFTRAG for non player.

if the contact in a zone which I have to do something about it at all? is there an existing AUFTRAG in progress on the contact? if the contact already targeted from a prior cycle by an alive group? > issue a BRAA call and break out the loop if there is a human resource (prefered) that is checked in? > Tasking function else No> launch AUFTRAG (intercept)

Player pre commit flow Pre check in we do nothing menu shows options to check in Post check in we add the player to a resource pool and replace check in with check out. AWACS checks his CAP zones, sends mission on station using the existing code

Player Post commit flow (- triggers monitor lives above)

Here it gets tricky, and I think it makes sense to think about having a control SRS Radio Freq per checked in player group 

* call BRA on 30s intervals - now this is where it might get interesting. There is a condition where another group within your threat range comes into your bubble during the interecept and the question is how to deal with that, especially if there are multiple threat groups. If you create a new intercept based on the distance you sent the first intercept, you will get an escalation and rolling hot war that goes quite mental. TBD

** Good one. Having though about this, could be a couple of cases, basic one a Gorilla or Bomber group just crossing the zone. Maybe check type and flight altitude planes. AI Fighter - would they meddle in the fight? Not sure. Enemy players - can't really make an automated decision. For the latter 2 types can make sense to auto-add them to the TARGET object tracked with the specific mission, avoiding overhead with JUDY etc, but would mean an auto-commit. Other option - generally ignore - also for further taskign by other AI/Player - until left the intercept bubble.

* JUDY optional from menu to silence this.

* untargetted filler becomes higher priority

* i find it hard to create a flow beyond single engagments that makes sense at this point.

** keeping it simple - the idea is to have a flow of single engagements.

Thats all for now. ssince its very complex and I can't think of everything properly yet.

thebgpikester commented 2 years ago

Today and yesterday currently playing with various PICTURE calls. Enjoying the complexity of how to provide the top three groups of a bigger picture, and how to weight the ways we assess with human eyes the relevant parts. I am using the following criteria:

There can be more but when figuring out a table sorting algorithm you really can't get an effective ordering unless there is somehow a weighting system and the order is interchangeable. When speaking to Frank he set me up with a basic sorting algorithm and it is never going to be as good as human eye:

Given

 contact={name=grp:GetName(), threat=grp:GetThreatLevel(), dist=dist}

 local function sort(a,b)
  return **(a.dist<b.dist)-- or (a.dist==b.dist and a.threat>b.threat)**
end

Like SQL it will sort one way then resolve differences which is really pants. Would like to hear your ideas here. Objective to give the top three contacts of importance in the picture

Applevangelist commented 2 years ago 
Range - the obvious and cheap ordering system
Aspect - I think its possibly the most important part of assessing threat directionally.
Fighter or other. I think over three group pictures can easily filter non fighters
Group size. Heavy groups are always dangerous

Looks like a sensible approach to me. A bit of a bucket approach might help.

thebgpikester commented 2 years ago

Right now I'm using the AWACS as 'centre of the universe' to consider threat and range, but this should probably be script configurable. For example use a unit or static or airbase as a centrally pinned vulnerable point. Note that this threat distance is not going to be refered to ever outside of code, its arbitrary evaluation (and subject to argument). Carrier, AWACS, airfield, city, topographical point, EWR installation can all be examples of a defensive point the algorithm can decide on.

So developing on your feedback fill 3 range buckets <50nm,<100nm, >100nm

Then I think a combined threat level works like: group size * grp:GetThreatLevel()

And finally ordered by aspect?

I'm gonna aim for this and see how it calls out.

Applevangelist commented 2 years ago

AWACS as 'centre of the universe' to conside

  • The coded version is currently either bulls eye or the center of the AO, as it is the target to keep the AO clean. But yeah, for threat assessment can be any coordinate. Too many options might create problems down the road with noob mission designers, maybe we stick to one approach first
  • On the aspect calc I need to read up the source, I think we currently need a directional vector for that, which is only provided with positionables.
Applevangelist commented 2 years ago

Heading can be provided to the coordinate, ok, so we need a direction set in which the defense coord is “looking” (threat axis). Let me add that and make it visual on the map

thebgpikester commented 2 years ago

Aspect was the reason for the requirmeent of a centre point to reference from. But you can hard code it to the awacs, because as said, its not the aspect that is read out when doing a BRAA and BULLSEYE has no aspect local aspect = tgtCoord:ToStringAspect(currentCoord) This will only be for differentiating high threat fighters when painting a picture, i don't recomemnd its usage for anything else. The BRAAA code is pretty easy and has that.

Applevangelist commented 2 years ago

The downside is that the awacs is changing headings when orbiting so the aspect changes. I can have that in a shadow coord so it doesn’t influence bra callouts

thebgpikester commented 2 years ago

The aspect of a contact remains the same whichever way the awacs is facing. It's not Angle on Bow :). If the ToStringAspect() is incorrectly writte (i thought it was OK previously) then this needs some different code. A bandit driving towards the awacs will always be hot.

Applevangelist commented 2 years ago

Need to cross check this Checked. ToStringAspect is empty since per se the GROUP Coordinate does not include the Heading

Applevangelist commented 2 years ago

function aspectcheck() local myposition = ZONE:FindByName("NW Zone"):GetCoordinate() local group = GROUP:FindByName("Aerial-1") local groupcoord = group:GetCoordinate() local groupheading = group:GetHeading() groupcoord.Heading = groupheading local aspect = groupcoord:ToStringAspect(myposition) MESSAGE:New(string.format("Aerial-1 is aspect %s",aspect),10,"Info"):ToAll() end

local timer = TIMER:New(aspectcheck) timer:Start(10,15)

Applevangelist commented 2 years ago

Works if I add the heading

Applevangelist commented 2 years ago

Fixed low down in group and positionable

Applevangelist commented 2 years ago

Right now I'm using the AWACS as 'centre of the universe' to consider threat and range, but this should probably be script configurable. For example use a unit or static or airbase as a centrally pinned vulnerable point. Note that this threat distance is not going to be refered to ever outside of code, its arbitrary evaluation (and subject to argument). Carrier, AWACS, airfield, city, topographical point, EWR installation can all be examples of a defensive point the algorithm can decide on.

So developing on your feedback fill 3 range buckets <50nm,<100nm, >100nm

Then I think a combined threat level works like: group size * grp:GetThreatLevel()

And finally ordered by aspect?

I'm gonna aim for this and see how it calls out.

Implemented now in the code. Need to change getting contacts from contact to cluster in a meaningful way - contacts are easier to address for many things, but the cluster mechanism from intel can club stuff together, eg a mainstay and it’s escort. I’ll have a think on that

dMARLAN commented 2 years ago

Additional/Pop-up/Threat range would be based on the fighter positions BTW for future versions.

It doesn't really make sense to have it hard set to an airbase/AWACS/etc.

For example, You may consider the AA-10C Missile a category SAR-2 threat with a 25 NM threat range and lesser missiles a SAR-1 threat with a 15 NM threat range.

Therefore if a MiG-29 was within 25 NM of a friendly fighter that would be a THREAT call

"COLT 11, BEAR, THREAT GROUP, BRAA 250, 23, 25 THOUSAND, HOT, HOSTILE."

But if it was, say, a MiG-23, it wouldn't be until 15 NM.

Both of these ranges are in regards to the fighter itself, it wouldn't have much use if a bandit was 25 NM from the AWACS, but 100 NM from the fighter (well, except being a THREAT to the AWACS of course)

Applevangelist commented 2 years ago

Since I'm working on missile callouts today, IMHO an option would be to to go by seeker type, else I'd need an extensive list of missiles and their ranges ... considering: https://wiki.hoggitworld.com/view/DCS_Class_Weapon Callouts will be for

Weapon.MissileCategory
  AAM          1
  SAM          2

and then maybe distance per type

Weapon.GuidanceType
  IR                   2 -- 5nm
  RADAR_ACTIVE         3  --25nm
  RADAR_SEMI_ACTIVE    4  --15nm 
  RADAR_PASSIVE        5  --10nm

With SAM types getting a 25nm range. For the THREAT call, a fixed distance might be ok for a first approach (~25nm)

dMARLAN commented 2 years ago

If you want to save yourself some trouble (and are looking for a realistic approach) there would be no missile callouts real world, that's purely a DCSism -- at least, in the era we are simulating.

Yea a 25nm range is a great range to use for now, honestly could just leave it like that as a default and allow configuration later on. Having more than 1 threat range I personally would consider out of scope, but it's just something that would exist real world.

Applevangelist commented 2 years ago

I have an era switch - non-moderns don't get a callout ;) - just a dcs thing, good to know, but helpful for Players. Same I'll have some "Vector to target BRA" callouts for stationing and guide intercepts for players, I'll make both switchable

thebgpikester commented 2 years ago

Right now I'm using the AWACS as 'centre of the universe' to consider threat and range, but this should probably be script configurable. For example use a unit or static or airbase as a centrally pinned vulnerable point. Note that this threat distance is not going to be refered to ever outside of code, its arbitrary evaluation (and subject to argument). Carrier, AWACS, airfield, city, topographical point, EWR installation can all be examples of a defensive point the algorithm can decide on. So developing on your feedback fill 3 range buckets <50nm,<100nm, >100nm Then I think a combined threat level works like: group size * grp:GetThreatLevel() And finally ordered by aspect? I'm gonna aim for this and see how it calls out.

Implemented now in the code. Need to change getting contacts from contact to cluster in a meaningful way - contacts are easier to address for many things, but the cluster mechanism from intel can club stuff together, eg a mainstay and it’s escort. I’ll have a think on that

This is where it gets awfully complex and we have effort vs reward tailoff. Ideal world: This is unit based and we measure all groups on that regardles sof the DCS group. Gross simplification you get groups ignoring the 3nm limit and adhering to the DCS group which in 80% of occasions will work.

I'll understand if you can't get it exactly right. Given the capabilities of this, the groundwork accuracy may be worth the effort. This part is beyond my skill level for sure.

Just one thing, you are so on the right track I've had this in my head for many years now and almost every design decision has been bang on my vision or better, stick with it, this is your legacy here! Great work!!

thebgpikester commented 2 years ago

EDIT! Only two comments from the initial start. I ran the demo and i was doing everything I had hoped.

"All stations, Magic, clear" should be "Magic, All stations. Picture clean" Clean is specific to radar returns and without the proword 'picture', it feels a bit wonky when said (often). Also with broadcast messages, magic comes first, with specific targetted groups, their callsign comes first.

Bogey Dope with no nearest target "Jedi- four, Magic, clear" should be "Jedi-four, Magic, clean" (or unable)

BRAAs and callout format Some of the callouts are using older code because you get a mix of old and new wording types for BRA and some fo the newer ones are wrong too.

three examples: image

Most of the miles in new examples are being read out as seperate digits. So, "1 2 3 for 064" should be "1 2 3, sixty-four miles"

First example should be "Magic, Dodge 3 1, commit echo group, brah 3 2 1, sixty-three miles, 25 thousand"

Second example should be "Foxtrot group, Rock 0 3 2, 64 miles, Twenty-five thousand, Cold, Targeted by Dodge 1 1" "Echo group, Rock 3 5 5, 78 miles, Twenty-five thousand, 2-ship, , Targetted by Dodge 3 1"

Third example is the old Flight control BR, should be; "Dodge 1 1, Magic, vector to station 2 1 4, thirty-five miles, Angles 22

I got one script error and it was a GetCordinate failure 2022-04-30 17:16:11.260 INFO SCRIPTING: 18500( 21645)/E: UNIT02235.GetCoordinate({[1]=Cannot GetCoordinate,[Positionable]={[UnitName]=Aerial-1#001-01,[ClassName]=UNIT,},}) 2022-04-30 17:16:11.260 INFO SCRIPTING: Error in SCHEDULER function:[string "C:\Users\Pikes\AppData\Local\Temp\DCS.openbeta\/~mis00007103.lua"]:21647: attempt to index local 'FirstUnitCoordinate' (a nil value)

I know this one as it needs an error check if exists before checking the group:GetCoordinate() because they die and mess stuff up.

This is awesome work, i cant believe its so close!

Applevangelist commented 2 years ago

Great feedback, and easy to fix :)

thebgpikester commented 2 years ago

On to some more :D sorry

AI checkin. Seems to be per unit instead of per flight. There's a lot of checking in on the same callsign.

thebgpikester commented 2 years ago

AWACS:New() -6th parameter is super weird. In the docs this is an area. I changed it to "Georgia" and it began in messages that AWACs was Georgia control and all seemed good.

Then it appeared to be used as a bullseye and with a single point which is counterintuitive. The instructions say

Name of the round, mission editor created Fighter Engagement operations zone (FEZ) this AWACS controls. Can be passed as #ZONE_POLYGON. Will be used in referenc call, ensure a radio friendly name that does not collide with NATOPS keywords. Did this cause error SCRIPTING: 14356( 8795)/E: COORDINATE01238.MarkupToAllFreeForm(ERROR: Currently a free form polygon can only have 10 points in total!) I instinctively tried to mimmic a border and I dont know what I should do with it.

Can we check what this reference call is about and what the intention is of this area?

thebgpikester commented 2 years ago

testawacs:SetBorderZone(ZONE:FindByName("Blue Border"))

Related to the above, its another border, not sure its purpose and what it dictates. Documentation is empty. Is this INTEL related?

Ultimatley when designing a mission I want to draw a border for ignoring contacts and a border for the zone the AWACS controls, both of which will be multiple points. If there needs to be a single coordiante, I'd rather it was seperate and explained than try too hard to multipurpose all these poly zones into single poitns also?

thebgpikester commented 2 years ago

Actually, scratch that, the 6th parameter seems to be a custom bullseye AND a zone of operations and the callouts are given to a zone. I put the bulleseye out to sea and its bascally disregarded. I think this is an area requiring a bit of rework. I'm OK with custom bullseyes and ops zones, but we have to have a centre of a zone made precisely. A Bullseye is already positioned and provides a coordinate, so i dont see that we need to change it. Instead soemthing like AWACS:CustomBullseyeName = "string"

This way the bulseye position is used, retained and if you need a zone for something else in parameter 6 then use it that way.

thebgpikester commented 2 years ago

image Cadence sounds better in TTS with All stations, Magic. Picture. 3 groups. Theres a comma rather than the period after 'stations' that makes the sentence more natural.

thebgpikester commented 2 years ago

image These are great callouts. I think atmospherically a callout more similar to the DCS one is nicer and you can do some randomisation and expand this with the following suggestions: All stations, Magic ... <-- this opener again in broadcast chute spotted/<C/S> vanished/friendly flight faded/lost contact with C/S/CSAR Scramble Bullseye 1 2 3 forty-five miles

dMARLAN commented 2 years ago

I am probably missing something but I am not understanding the purpose of "All Stations", AWACS calls made in Broadcast Control are already addressed to everyone "Magic, 3 groups, group, bullseye ......" and doesn't need "picture" unless it was a response to a request from a fighter because in broadcast control every broadcast is a (new) picture.

e.g. Broadcast Control (Picture): [Magic]: "Magic, 3 groups, group, bullseye 250/50, 25 thousand, cap, hostile. group, bullseye 300/80, 30 thousand, cap, bogey spades. group, bullseye, 200/30, 15 thousand, track west, bogey spades."

e.g. Post-Merge Picture call from Fighter: (Of course we don't need the flow/state but just an example of real comm) [Colt 11]: "Magic, Colt 11, flow east, picture." [Magic]: "Magic, Picture clean, flow miami, say state." (miami being the code worded bullseye in this example) [Colt 11]: "Colt 11, tiger." (tiger is not a static comm brevity, it's a code word that would be changed, but it's a common training one such as "rock" for bullseye. In addition to tiger, common training code words can be cub and lamb. (cub = yellow, lamb = red))

Regarding a downed friendly fighter, the comm brevity is RIGHTGUARD with location. This indicates a fighter (or any friendly flight) is downed and SAR should be initiated if able.

e.g. [Magic]: "Magic, RIGHTGUARD, RIGHTGUARD, Dodge 41, Bullseye X/Y"

thebgpikester commented 2 years ago

I am probably missing something but I am not understanding the purpose of "All Stations", AWACS calls made in Broadcast Control are already addressed to everyone "Magic, 3 groups, group, bullseye ......" and doesn't need "picture" unless it was a response to a request from a fighter because in broadcast control every broadcast is a (new) picture.

e.g. Broadcast Control (Picture): [Magic]: "Magic, 3 groups, group, bullseye 250/50, 25 thousand, cap, hostile. group, bullseye 300/80, 30 thousand, cap, bogey spades. group, bullseye, 200/30, 15 thousand, track west, bogey spades."

e.g. Post-Merge Picture call from Fighter: (Of course we don't need the flow/state but just an example of real comm) [Colt 11]: "Magic, Colt 11, flow east, picture." [Magic]: "Magic, Picture clean, flow miami, say state." [Colt 11]: "Colt 11, tiger."

Regarding a downed friendly fighter, the comm brevity is RIGHTGUARD with location. This indicates a fighter (or any friendly flight) is downed and SAR should be initiated if able.

e.g. [Magic]: "Magic, RIGHTGUARD, RIGHTGUARD, Dodge 41, Bullseye X/Y"

Its got legacy origins, its probably better to use the way you said. Not a hard and fast design, its changed over the years of course, this would come froma time before these books :)

Applevangelist commented 2 years ago

On to some more :D sorry

AI checkin. Seems to be per unit instead of per flight. There's a lot of checking in on the same callsign.

Ah that’s per group ATM, each a single flight. So Dodge 1, 2, 3. Maybe I do a little round robin with group names to make it more distinctive

Applevangelist commented 2 years ago

AWACS:New() -6th parameter is super weird. In the docs this is an area. I changed it to "Georgia" and it began in messages that AWACs was Georgia control and all seemed good.

Then it appeared to be used as a bullseye and with a single point which is counterintuitive. The instructions say

Name of the round, mission editor created Fighter Engagement operations zone (FEZ) this AWACS controls. Can be passed as #ZONE_POLYGON. Will be used in referenc call, ensure a radio friendly name that does not collide with NATOPS keywords. Did this cause error SCRIPTING: 14356( 8795)/E: COORDINATE01238.MarkupToAllFreeForm(ERROR: Currently a free form polygon can only have 10 points in total!) I instinctively tried to mimmic a border and I dont know what I should do with it.

Can we check what this reference call is about and what the intention is of this area?

I you look into the ME, Rock#POLYGON_ZONE is the name of the Helo making the FEZ zone ;) Moose picks that up and creates a Polyzone on loading; it’s a little used Sven feature :)

Applevangelist commented 2 years ago

Actually, scratch that, the 6th parameter seems to be a custom bullseye AND a zone of operations and the callouts are given to a zone. I put the bulleseye out to sea and its bascally disregarded. I think this is an area requiring a bit of rework. I'm OK with custom bullseyes and ops zones, but we have to have a centre of a zone made precisely. A Bullseye is already positioned and provides a coordinate, so i dont see that we need to change it. Instead soemthing like AWACS:CustomBullseyeName = "string"

This way the bulseye position is used, retained and if you need a zone for something else in parameter 6 then use it that way.

Yep that’s arguably a more natural approach for the mission designer.