- instead of only checking if the transfer destination was captured it now checks if there is a valid route between origin and destination. This also ensures that there will be a check if the current position or next_stop was captured and therefore the transfer should be disbanded.
- disband uncompletable transfer before planning or performing (also when user cheated a base capture)
when a cp capture happens and the next cp has pending unit deliveries then they will be redeployed to the newly captured cp. The redeploy was drecreasing the num of pending unit deliveries for the old cp but was not removing them completly from the dict when all were removed
* Addresses #478, adding a heading class to represent headings and angles
Removed some unused code
* Fixing bad merge
* Formatting
* Fixing type issues and other merge resolution misses
It's rare with the current 5NM buffer around the origin, but if we use
the hold distance as the buffer like we maybe should it's possible for
the preferred join locations to fall entirely within the home zone. In
that case, fall back to a location within the max-turn-zone that's
outside the home zone and is nearest the IP.
The doctrine/task limits were capturing a reasonable average for the
era, but it did a bad job for cases like the Harrier vs the Hornet,
which perform similar missions but have drastically different max
ranges. It also forced us into limiting CAS missions (even those flown
by long range aircraft like the A-10) to 50nm since helicopters could
commonly be fragged to them.
This should allow us to design campaigns without needing airfields to be
a max of ~50-100nm apart.
After completing the new game wizard but before initializing turn 0,
open a dialog to allow the player to customize their air wing. With this
they can remove squadrons from the game, rename them, add players, or
change allowed mission types. *Adding* squadrons is not currently
supported, nor is changing the squadron's livery (the data in pydcs is
an arbitrary class hierarchy that can't be safely indexed by country).
This only applies to the blue air wing for now.
Future improvements:
* Add squadron button.
* Collapse disable squadrons to declutter?
* Tabs on the side like the settings dialog to group by aircraft type.
* Top tab bar to switch between red and blue air wings.
This only takes effect for default loadouts. Custom loadouts set from
the UI will allow LGBs. In the default case there will not be buddy-lase
coordination so we should take iron bombs instead.
Also adds single/double Mk 83 and Mk 82 weapon data to accomodate this.
Test cases:
1. Target is not threatened.
The IP should be placed on a direct heading from the origin to the
target at the max ingress distance, or very near the origin airfield
if the airfield is closer to the target than the IP distance.
2. Unthreatened home zone, max IP between origin and target, safe
locations available for IP.
The IP should be placed in LAR at the closest point to home.
3. Unthreatened home zone, origin within LAR, safe locations available
for IP.
The IP should be placed near the origin airfield to prevent
backtracking more than needed.
4. Unthreatened home zone, origin entirely nearer the target than LAR,
safe locations available for IP.
The IP should be placed in LAR as close as possible to the origin.
5. Threatened home zone, safe locations available for IP.
The IP should be placed in LAR as close as possible to the origin.
6. No safe IP.
The IP should be placed in LAR at the point nearest the threat
boundary.
Much of the UI was using the old budget which wasn't removed from Game
like it should have been when Coaltion was introduced. The UI displayed
(and in some cases pulled from) the starting budget rather than the real
budget.
The only parts of the old weapon data that worked well (didn't commonly
result in empty pylons) did this implicitly, so make the grouping
explicit.
This also moves the data out of Python and into the resources, which
both makes the data moddable and isolates us from a huge amount of
effort and a save compat break whenever ED changes weapon names.
I didn't auto migrate the old data since the old groups were not
explict and there's no way to infer the grouping. Besides, since most of
the weapons were *not* grouped, the old data did more harm than good in
my experience. I've handled the AIM-120 and AIM-7 for now, but will get
at least all the fox 3 missiles before we ship.
This makes it so that the mission planning effects are applied only if
the package can be fulfilled. For example, breakthrough will be used
only if all the BAI missions were fulfilled, not if they will *attempt*
to be fulfilled.
Consider BAI missions planned this turn when determining if a control
point is still garrisioned for preventing breakthrough.
This isn't very accurate yet since the HTN isn't checking for aircraft
fulfillment yet, so it might *plan* a mission to kill the garrison, but
there's no way to know if it will be fulfilled.
This improves the AI behavior by choosing the stances non-randomly:
* Breakthrough will be used if the base is expected to be capturable and
the coalition outnumbers the enemy by 20%.
* Elimination will be used if the coalition has at least as many units
as the enemy.
* Defensive will be used if the coalition has at least half as many
units as the enemy.
* Retreat will be used if the coalition is significantly outnumbers.
This also exposes the option to the player.
IADS that are in detection range (but not attack range) of missions will
be targeted at very low priority. These will typically only be planned
when no other targets are in range.
The players can still manually assign strike missions on other target
types since that's sometimes better for player waypoint generation (one
waypoint per unit is nice for SAMs), but it's bad for the AI so by
default we should exclude non-buildings.
This also prevents double targeting of groups, since they might have
been identified by other missions as well.
We already did some of this, but since we were excluding specific TGO
types rather than only allowing building TGOs we were often missing
things (missile sites, coastal defenses, and EWRs, it seems).
Garrison groups should be preferred with the following priority:
1. Groups blocking base capture
2. Groups at bases connected to an active front line
3. Rear guard units
Previously they were being prioritized based on the distance to the
closest friendy control point, which is similar to this but an
aggressively placed carrier could throw it off.
Used to decorate functions or methods that have save compat code for a
given major version.
```
@has_save_compat_for(5)
def foo() -> None:
...
```
This function will raise an error at startup if it is decorated as
having save compat for a version other than the current major version of
the game. A new major version is the definition of a save compat break,
so keeping around the old compat code serves no purpose other than
hiding initialization bugs. The compat code and the decorator should be
removed in the branch raising the error.
This alters the DEAD task planning to be the *least* preferred task, but
prevents other tasks from being planned unless they are excepted to be
clear of air defenses first. Even so, missions are a guaranteed success
so those other missions will still get SEAD escorts if there's potential
for a SAM in the area.
This means that air defenses that are not protecting a more useful
target (like a convoy, armor column, building, etc) will no longer be
considered by the mission planner. This isn't *quite* right since we
currently only check the target area for air defenses rather than the
entire flight plan, so there's a chance that we ignore IADS that have
threatened ingress points (though that's mostly solved by the flight
plan layout).
This also is still slightly limited because it's not checking for
aircraft availability at this stage yet, so we may aggressively plan
missions that we should be skipping unless we can guarantee that the
DEAD mission was planned. However, that's not new behavior.
An HTN (https://en.wikipedia.org/wiki/Hierarchical_task_network) is
similar to a decision tree, but it is able to reset to an earlier stage
if a subtask fails and tasks are able to account for the changes in
world state caused by earlier tasks.
Currently this just uses exactly the same strategy as before so we can
prove the system, but it should make it simpler to improve on task
planning.
