Initial version of attack/support rework

[jaj22]

What type of PR is this.

1. Fail project

What have you changed and why?

This is a general rework of all enemy supports and attacks to draw from limited resource pools. Key files and systems:

Resource pools

Enemy resources are split into two types, "attack" and "defence". Units generated as part of an attack or support are paid for up-front and have their "A3A_resPool" variable set accordingly. If despawned in good condition, they are partially refunded. Mission units have A3A_resPool set to "legacy" and are free to spawn (as they're effectively ambient units with no particular task), and paid for equally from both pools on destruction. Garrison units are paid for on creation and not refunded on despawn for obvious reasons. Attack and defence resources are saved, and updated appropriately on save: Pre-paid units are refunded according to damage level.

Attack and defence pools are used differently. An attack is launched once an enemy faction hits >0 attack resources, typically leaving that faction with a large negative value, which is slowly increased back to zero before the next attack can be launched. Defence resources typically have a positive buffer which is used up as reinforcements and supports are generated.

AggressionUpdateLoop

This file (basically a 60-second loop) is now responsible for updating all the balance variables, incrementing the four resource pools and launching attacks. Descriptions of balance variables:

• A3A_activePlayerCount is a count of all active players. Activity is determined by a simple client-side getDir check.
• A3A_balancePlayerScale is the general amount-of-stuff coefficient, normalized to 1 with 6 players at tier 6.
• A3A_balanceVehicleCost is a rough average resource cost of a single attack vehicle + cargo (if any) at the current war tier.
• A3A_balanceResourceRate is the resources of each type typically gained by a faction every 10 minutes, currently just balancePlayerScale * balanceVehicleCost. The defence cap is currently at 10*A3A_balanceResourceRate.
• A3A_enemyBalanceMul is a parameter (default 10, because params don't do FP) that multiplies A3A_balancePlayerScale to make the game generally harder or easier.
• A3A_enemyAttackMul is a parameter that multiplies attack resource rate to make attacks faster or slower.
• A3A_invaderAttackMul and A3A_invaderDefenceMul are temporary multipliers applied to invader resource gain rates. These aren't currently parameterized.

ResourceCheck (the 10-minute loop) still has most of its former responsibilities, although it now runs with any active players (not necessarily a commander), and no longer generates supply convoys against flipped towns (now the responsibility of chooseAttack).

Support system

This is the call/response system rather than the limited-knowledge system, as I got it mostly working first. Might be replaced in the future as limited-knowledge does have advantages. Key files:

• initSupports set up various arrays and hashmaps used by the support system, including marker values and static support type data. They're all documented there, so I won't repeat it here.

• maxDefenceSpend determines how many resources can be spent against a particular target or marker. It takes account of the importance of the location (based on nearby friendly and enemy markers), aggregate threat (based on live friendly garrisons and enemy troops nearby, plus recent casualties taken), available resources, and support resources already spent against that target/area.

• requestSupport takes dumb support requests against targets (typically from callForSupport or airspaceControl), uses maxDefenceSpend to decide how many resources to spend, and then chooses a support type dependening on base types (area, troops, target) already called nearby. It also uses the SUP_*Available functions to generate weights for each support based on target type and other support-specific factors. There is a similar but simpler function (requestArtillery) used to choose artillery type supports for attacks. requestSupport always uses the defence pool.

• createSupport is a worker function to force-create a support of a specific type. It will use already-active supports by preference, if they don't currently have a target.

Each support typically has an availability function (actually returns a weight now, could be renamed), a creation function (intended to be called by createSupport, and so returns fairly quickly), and a persistently spawned routine that manages the support while active. Multi-target supports update the A3A_activeSupports array to indicate readiness and completion.

All working supports from the previous system have been preserved except for Gunship and the orbital laser, which need updating to new systems.

Individual supports have been heavily refactored and in some cases rewritten. Some common trends:

• Event handlers for damage response have been generalised and moved to AIVehInit.
• Support marker creation and maintenance is now offloaded to showInterceptedSupportCall.
• Multitarget supports now only store one target at once. This avoids problems where the support system would overstack a support with targets it was never likely to engage.

The CAS support had a major overhaul, rewriting the pre-run loop to a semi-proper state engine and converting CASRun to an onEachFrame handler so that it behaves properly under moderate script load.

callForSupport is now only triggered by damage, not spotting. Unconsciousness triggers have been cleaned up to call AIReactOnKill more consistently with and without ACE. These triggers also add to the recentDamage arrays on the server, to improve the decision making of maxDefenceSpend.

Marker recapture counterattacks now use maxDefenceSpend to calculate how large a counterattack to send. If the capture was a hard fight with multiple supports called, or the flag was reflipped shortly after a counterattack was cleared, it's likely that nothing further will be sent.

QRF and attack vehicle spawning

QRFs, counterattacks (singleAttack), major attacks, punishments and HQ attacks have all been rewritten to use the same code paths for spawning and vehicle/troop behaviour.

Vehicle choice is based on splitting vehicles into transport (contains cargo units) and support types. Any attack force must contain at least one transport vehicle, typically more than half. Only attack helis are generated as air supports. CAS and ASF must be called separately.

Land forces are spawned using the vehicle spawn places system, patched up so that it mostly works. Maps without sufficient vehicle spawn places defined will need them added, otherwise land vehicles will be minimal. Air vehicles are restricted to spawning at airfields or the carrier marker.

Various changes to previous QRF/singleAttack vehicle behaviour:

• Ground vehicles now have their waypoints culled much more heavily, improving travel speed and preventing some weird cowardly behaviour of unarmed transports.
• Crew in weapon-less ground transport vehicles now leave with the cargo units.
• Attack helis are less inclined to give you a free shot on approach, and will not hover once they run out of targets.
• Paradrop method has been substantially improved. Perf should be better and drop height should be more consistent. Aims further from the target but may miss.
• combatLanding now lands further away from the target and gets the troops out more reliably, but needs more work (onEachFrame usage, persisting after landing).

Attack choice system

Once a faction has positive attack resources, it will call chooseAttack to launch an attack. Target selection is handled with findAttackTargets, which weights potential attacks depending on target value and threat. Main differences:

• Lower-rated attacks can be chosen, using the weight as a probability.
• Attacks against rebel targets outside mission distance are now permitted, although chance is reduced.
• Danger of flying over other enemy locations is taken into account.
• Threat of other nearby locations is taken into account, not just the target.
• Distance has no effect (other than the hard air distance cap), but nearby land bases are beneficial.
• Supply convoys are now used instead of occupant city attacks.
• HQ attacks are now generated with the same system,

HQ attack system

HQ attacks can now only be launched once an enemy faction has full knowledge of your HQ. Knowledge is currently added when a traitor mission is failed, or when a support is called against a target near HQ. Knowledge diminishes slowly over time as long as it hasn't reached 1. Moving HQ will reset knowledge, as long as their wasn't a previous HQ nearby recently.

The attacks themselves are still specops air, but benefit from improvements to combat behaviour. Support artillery and UAVs are also used to assist.

Aggro system changes

Aggression from kills is now inversely adjusted by balancePlayerScale. This means that aggro should work similarly for low and high player counts. High activity means high aggro, low activity means low aggro.

There is typically no longer any direct aggro from defeating supports or attacks. Destroying vehicles and killing troops is assumed to be sufficient. This should also be applied to most missions, but wasn't addressed yet to cut down on file changes. Capturing markers still increases aggro, by a flat amount rather than player scaled.

In the reb vs gov game mode, aggro now affects resource rates directly. In reb vs gov vs inv, aggro doesn't change the total resource rates but affects the quantity that enemies will spend on rebels as against the other enemy faction. Aggro also affects delay times on supports, and the chance of attacks being launched on rebels.

Remaining stuff

• AI functions have been added to make enemy units terminate their current AI scripts (eg attackDrillAI) and return to base or garrison at a nearby friendly marker. These are pretty bad due to various garrison organisation and marker data problems, but they'll do for the moment.

• There is now no direct use of maxUnits. The assumption is that the resource limits will manage active troop counts appropriately.

• The scheduler has been tweaked to use the server when it's not heavily loaded.

• timingCA calls (typically mission rewards) now just diminish enemy resource pools. Temporary.

Please specify which Issue this PR Resolves.

TODO

Please verify the following and ensure all checks are completed.

1. Have you loaded the mission in LAN host?
2. Have you loaded the mission on a dedicated server?

Is further testing or are further changes required?

1. No
2. Yes (Please provide further detail below.)

How can the changes be tested?

TODO

[killerswin2]

Just some stuff I saw. Happy that the annoying incoming missile event is being killed.

[killerswin2]

Dead?

[jaj22]

This one in particular will stay, because I'm still in two minds as to whether to use it more. The others are very dead.

[jaj22]

Getting pretty close to done. Remaining test/cleanup:

• At least syntax-check all the templates.
• More synthetic testing of findAttackTargets changes.
• Sort out template verification for vehicleAttributes.

[Bob-Murphy]

Went through all the stuff and marked the ones where I have some questions and to check ToDos marked by you, just to check them off. I also didn't mark every ToDo, just so you know.
In addition to that I saw that there are some headers not completely set up or fully missing. Hence I'd like you to go through the files and clean up the headers a bit. The ones I marked are exemplary.

Other than that nothing special jumped into my eye. No typos, no obvious wrong content in texts.