Additional skynet components

[DanAlbert]

Add the remaining skynet components:

• C2
• power
• AWACS integration

[qwertymanisalive]

The REDFOR Russian AWACS A-50 would be an useful add-on for OPFOR skynet

[DanAlbert]

@RndName btw if you're interested, we'd been holding off on adding the AEW&C aircraft to the list of skynet EWRs because they weren't available to red, but 3.0 fixed that. If you want even better coverage you could do something similar to your EWR fix for those. I think the key location is AircraftConflictGenerator.generate_planned_flight() (although the change should maybe be in NameGenerator.next_aircraft_name()?) You'd also want to edit the skynet plugin config so that it knows to use BLUE|AEWC| prefixed names or whatever.

[RndName]

@RndName btw if you're interested, we'd been holding off on adding the AEW&C aircraft to the list of skynet EWRs because they weren't available to red, but 3.0 fixed that. If you want even better coverage you could do something similar to your EWR fix for those. I think the key location is AircraftConflictGenerator.generate_planned_flight() (although the change should maybe be in NameGenerator.next_aircraft_name()?) You'd also want to edit the skynet plugin config so that it knows to use BLUE|AEWC| prefixed names or whatever.

I will have a look into it what could be possible to implement the missing parts :)

[RndName]

@DanAlbert
Red AEW&C are already added to skynet via the lua data luaData["AWACs"][awacs.callsign]. The operation.py iterates over airsupportgen.air_support.awacs and adds them. The AWAC Planes were added there because they have a flightplan of type AwacsFlightPlan. So every Plane which has one of these flightplans will be added to the AWACs array. They later will be added to the plugin directly by theyre unitName instead of this "byPrefix" function as the lua script iterates over the complete array and uses the unitName directy.
Blue AWACS on the other hand are currently not added to this array. Correction: They would be added but the array is based on the callsign luaData["AWACs"][awacs.callsign] which for Red and Blue currently is set to "overlord" so they will be overitten. Thats be bug here 🐛

This would lead to two options:

1. Add Blue AWACs to this array as well and reuse the current implementation without chaning the unit Name of the AWACs flight
2. Change the unit name of all generated AWACS flights (Red or Blue) and make the lua script easier so that it can use prefixes instead of iterating over the specially crafted array.

What do you think, how should we proceed?

[DanAlbert]

Option 2. Much easier and keeps the decision in Python. I hadn't realized that we had anything that was adding it per unit, good catch.

[RndName]

Additional tasks for this Issue to be feature complete:

• AWACS flight added as EWR correctly
• Handle Point Defence SAMs correctly so that they wont be shutdown if a harm or Air threat is detected.
• Add Long Range SAM systems as EWR as recommended
• Ensure that all SAM Generators set the SearchRadar as first unit (Requirement by Skynet)
• Ensure that only same SAM types are part of one group. Different types have to be added as auxiliary group instead so that Skynet can handle them correctly
• Exclude AAA and SHORAD (if not used as Point Defence) from beeing added to Skynet
• Think about adding the A2A Interceptor dispatcher to the RED AI.

[DanAlbert]

I think the last point is probably very difficult. Making anything moose work with the rest of our systems didn't look feasible since it expects to be able to take complete control. No one has looked closely afaik though.

[RndName]

Implement the missing Skynet Components and give designers a way to add them to the campaign

To sum up all the infos and ideas to implement this function i put all my ideas in this post. Should be a good base for further specific discussions on the implementation. Especially to clarify what campaign designers would expect from this function.

DevBranch: https://github.com/RndName/dcs_liberation/tree/advanced-skynet

Infos

Source: https://github.com/walder/Skynet-IADS#skynet-iads-elements

Power Sources:

- 0..N can be connected to SAM, EWR and C2s
- Once destroyed the connected Assets will go dark when no other power source is availale

Command Center:

- 0..N can be connected to the IADS Network
- Once all offline the IADS goes to autonomous

Connection Node:

- Once all nodes to an EWR or SAM are destroyed it goes to autonomous
- Do not have a power source
- Can not be connected with each other but can be chained over EWR/SAM/CC (example: CC - CN1 - EWR - CN2 - EWR)
- They should be placed in between Assets

Autonomous Mode

- When no more connection node is alive to connect the site to the IADS
- When all Command Centers are destroyed
- can be configured with setAutonomousBehaviour for each asset (https://github.com/walder/Skynet-IADS#autonomous-mode-behaviour)

Features

Give user and campaign designer the option to disable/enable Advanced Skynet Features

• In Campaign Yaml: Define if it is capable of (Advanced) Skynet functions
• In New Game Wizard: Enable / Disable as user (Plugin and the advanced features)
• Handle if a user does not enable the Skynet Plugin at all -> Prevent wrong behaviour and generation of the IADS Elements when they are not used

Give campaign designer the possibility to place units

• Extend: https://github.com/dcs-liberation/dcs_liberation/wiki/Custom-Campaigns#unit-type-quick-reference-1

IADS Element	DCS Unit
Command Center	Fortification._Command_Center
Connection Node	Fortification.Comms_tower_M
Power Source	Fortification.GeneratorF

Set the specific autonomous behaviour

• As general "hard coded" (Example: All SAMS go autonomous OR Dark)
• Or By Campaign designer
• Or Coupled to some difficulty settings

Lua Scripting / Implementation

All Assets (SAM; EWR; C2) are connected by lua scripting to Connection Nodes and Power Sources. Skynet itself does not utilize a maximum range between two elements to be connected nor does it implement an automated way to connect nodes.

We can implement it with two basic concepts:

• Automatic handling with predefined ranges for Connection nodes and Power Source. So the code will automaticall attach all Assets within their range. The campaign designer just places the units and the generator does the rest.
• Customized by the campaign designer within the campaign YAML which will be parsed by the mission generator.
• Combination of both where the automatic generator is the fallback if no customized handling is defined in the campaign YAML

Example of a campaign yaml

iads:
  red:
    connection_nodes:
      - name: node1
        assets:
        - asset1
        - asset2
    power_sources:
      - name: node2
        assets:
        - asset1
        - asset2
  blue:

AI rebuilding destroyed IADS Elements

• Like Runway Repairs it takes time

Visualization of the IADS on the liberation map

• How should we display the IADS things on the liberation map?
• Icons for all Elements (Power Source, C2, Connection Node) // Icon for IADSElement Type
• More visuals on connected nodes (maybe a line between them as on the screenshot)
• Range circles?

Open Points:

• How to define which Connection Nodes and Power Sources are connected to a SAM or EWR? Easy method would be by Range. Every Node has a specific range and if some Assets are within this range they get connected. Another good one would be to let the campaign designer set some properties in the campaign yaml and liberation reads them out (Fallback Mode: When no special config is defined in the yaml file it will use the range mode)
• How to use the autonomous mode? It is possible to specify the explicit behaviour for each unit. It is possible to choose between Autonomous and Dark mode. (https://github.com/walder/Skynet-IADS#autonomous-mode-behaviour)
• AWACs - how should we integrate them into the IADS? They can be attached to connection nodes as well (Could be realized with range along the racetrack. But is this realistic?)
• How can we deal with user selling a SAM and buying another one which afterwards could be part of an IADS network (previous: AAA, after: SAM Long Range) -> This can only be captured with the automatic "range" approach. Also how do we handle CP Capture events when IADS Elements change the ownership... This would mean that the YAML file approach could only be used on the first initialisation of the campaign. Afterwards we can only use the range method or sth similar

Example

Red: Communication Nodes, Yellow: Power

1. CN-2 destroyed -> EWR-1 has connection over CN3-EWR2-CN1-CC1
2. CN-3 destroyed: EWR-1 No Connection, Offline
3. PS-2 Destroyed: EWR-2 Offline -> EWR-3 no connection

[DanAlbert]

Just one note:

Handle if a user does not enable the Skynet Plugin at all -> Prevent wrong behaviour and generation of the IADS Elements when they are not used

Skynet can be toggled on/off after generation, so it's probably best to generate everything even if the user doesn't enable those features. It's simple enough to get the AI to not bother targeting them when the feature is off.

Could later give those nodes non-skynet purposes too. The existing power plant building as a power node, and maybe later factories need those to function.

The rest of the plan SGTM.

Some ideas for the open questions:

Range v predefined

Range as a fallback seems fine, but I think range-based isn't how these would be set up. AIUI (but my understanding is limited) there will typically be only one or two control centers tucked way in the back where they are safe that control the whole thing, and power plants are similarly protected. I'm not sure if the power nodes are meant to represent actual power plants or just mobile generators though.

Allowing the predefined mode keeps that flexible though.

AWACS

Simpler is probably better here. Maybe allow them to connect to the network as long as any connection node still lives?

Handling sales

Associate the connections with the TGO and there's no problem. Replacing a SAM doesn't replace the TGO, just the group it owns.

Behavior after capture

I don't see anything wrong with captured IADS having degraded behavior.

Short term stretch goal would could be making it so that generators can be bought at the site to bring it online before the player captures the power plant (or if the the power plant gets destroyed). Then again, if you can do that, what's the point of targeting the power plants? Maybe it's better to leave that as a trade off. Killed the enemy power plant to make your job easier right now? Then you only get simpler SAM systems later (I don't think it makes sense for the mobile systems to require power connections, but idk).

Longer term, maybe it makes sense to allow building those connections in the UI?