Idea: Grouping of common Callsigns for threat calls

[wolfendragoon]

To better simulate how flights are often treated by a controller as a single unit rather than individual airframes, I propose the following change to threat calls for skyeye.

Trigger: Two or more aircraft sharing the same callsign (e.x. Wolf 1-1 and Wolf 1-2) are close together and a threat enters range of them.

Current state response: As there are multiple aircraft threatened, Skyeye calls out the threat for one of the pilots using Bullseye as reference.

Proposed state response: Check if aircraft share callsign, if they do select the closest airframe to the threat from the group and return the threat call in the same BRAA format used for Single airframes under threat.

[dharmab]

for one of the pilots using Bullseye

Correction, SkyEye calls the threat for all pilots using B/E, not just one. In the given example the call would be "Wolf 11, Wolf 12, group threat"

Check if aircraft share callsign, if they do select the closest airframe to the threat from the group and return the threat call in the same BRAA format used for Single airframes under threat.

I'd instead prefer to use a combined callsign, such as "Wolf flight" if all the Wolf aircraft are included or "Wolf 1" if all Wolf 1X aircraft are included but not any from Wolf 2X/3X/....

Note: There is an additional case to handle. Say Eagle 1 flight, a four ship, splits into two elements. Eagle 11 and Eagle 12 remain together, and Eagle 13 and 14 remain together. They set up a "grinder" CAP pattern where the first element pushes the CAP line while the second element resets. In such a case the calls will still need to be specific to each element, so "EAGLE 11, EAGLE 12" is probably the clearest way to communicate this.

[dharmab]

Proposed state response: Check if aircraft share callsign, if they do select the closest airframe to the threat from the group and return the threat call in the same BRAA format used for Single airframes under threat.

I think this can be simplified to "Check if all aircraft in the call satisfy grouping criteria, and if so, use BRAA format from the 2D center of the group instead of B/E"

[dMARLAN]

If they are outside 3nm from each other I'd make a separate call for each.
"Hornet 11, threat group, BRAA .....",
"Hornet 12, threat group, BRAA .....",

if inside, I'd list each callsign

"Hornet 11, Hornet 12, threat group, BRAA ....."

[franukis]

Note: There is an additional case to handle. Say Eagle 1 flight, a four ship, splits into two elements. Eagle 11 and Eagle 12 remain together, and Eagle 13 and 14 remain together. They set up a "grinder" CAP pattern where the first element pushes the CAP line while the second element resets. In such a case the calls will still need to be specific to each element, so "EAGLE 11, EAGLE 12" is probably the clearest way to communicate this.

I would digress: in that specific scenario of a grinder, the flight itself is coordinated to respond to threats, so a threat to the "front" element of the grinder, is a threat to the whole flight, and they will address it as a flight. So, using "Eagle 1, Threat...." would be, IMHO, correct and useful.

We are flying some Retribution campaigns with 4-5 human flights (15-20 planes) flying on the same area, and once the threat environment builds up, radio comms are completely saturated, as SkyEye is hijacking the channel completely. We have had to resort to put both Auto-picture and Threat calls off, and just use it for picture on demand :(

[dMARLAN]

Note: There is an additional case to handle. Say Eagle 1 flight, a four ship, splits into two elements. Eagle 11 and Eagle 12 remain together, and Eagle 13 and 14 remain together. They set up a "grinder" CAP pattern where the first element pushes the CAP line while the second element resets. In such a case the calls will still need to be specific to each element, so "EAGLE 11, EAGLE 12" is probably the clearest way to communicate this.

I would digress: in that specific scenario of a grinder, the flight itself is coordinated to respond to threats, so a threat to the "front" element of the grinder, is a threat to the whole flight, and they will address it as a flight. So, using "Eagle 1, Threat...." would be, IMHO, correct and useful.

We are flying some Retribution campaigns with 4-5 human flights (15-20 planes) flying on the same area, and once the threat environment builds up, radio comms are completely saturated, as SkyEye is hijacking the channel completely. We have had to resort to put both Auto-picture and Threat calls off, and just use it for picture on demand :(

A grinder should be ~10-20nm so a threat to the leading edge is not necessarily a threat to the trailing edge.

I am sure there is some improvements that could be made for less talking, but I don't think this should be one of them.

(Primarily, post-commit handling probably, but thats a big task)

[franukis]

Yeah, I know the trailing element might not be affected. Just implied that, in case they are a grinder, and the lead element is affected by the threat, they should be internally notifying to the trailing element, as they are coordinating in their CAP task, so maybe we could spare that call from the GCI.

I like your idea about post-commit... maybe adding an additional call to the GCI, to inform him that a flight is comitting to a BRAA or B/E threat, and then inhibiting consecutive calls about that affected threat? Something like "MAGIC, Eagle1 comitting Bullseye 040 for 20"

[dharmab]

Thanks for the input. I took a break from SkyEye development due to a health issue but it's finally healed so I can pick this back up in March.

[dMARLAN]

Yeah, I know the trailing element might not be affected. Just implied that, in case they are a grinder, and the lead element is affected by the threat, they should be internally notifying to the trailing element, as they are coordinating in their CAP task, so maybe we could spare that call from the GCI.

I like your idea about post-commit... maybe adding an additional call to the GCI, to inform him that a flight is comitting to a BRAA or B/E threat, and then inhibiting consecutive calls about that affected threat? Something like "MAGIC, Eagle1 comitting Bullseye 040 for 20"

From an IRL/ACC perspective this doesn't make sense.

• By calling out the friendly leading edge threat group, all listeners are already informed. "Hornet 11, 12, group, threat BRAA, ..." now HT13/14, 20nm behind (and all other listeners), know there's a group in front of HT11/12.
• The group is not a threat* to HT13/14. *threat implies specific meaning (See ALSSA ACC for details).
• If it instead said "Hornet, group, threat BRAA, ..." where do you anchor it? If you anchor the call to the trailing hornets now the BRAA is inaccurate to the leading hornets, and vice versa. Maybe you say it should go to the leading hornets, but then we are back to how it should be, except we're not being clear about what is happening by occluding the callsigns.

Side note, a commit call would just be "Eagle, commit."