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.
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.
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.
Unit composition is defined by the doctrine. The most understaffed CP
will now get the most underrepresented unit type. Previously a random
understaffed CP would get a random unit type.
Fixes https://github.com/dcs-liberation/dcs_liberation/issues/1057.
Not converting all at once so I can prove the concept. After that we'll
want to cover all the cases where an int distance or speed is a part of
the save game (I've done one of them here with `Flight.alt`) so further
cleanups don't break save compat.
https://github.com/Khopa/dcs_liberation/issues/558
Fighter sweeps arrive at the target ahead of the rest of the package
(currently a fixed 5 minute lead) to clear out enemy fighters and then
RTB.
Fixes https://github.com/Khopa/dcs_liberation/issues/348
This also removes ascend/descend waypoints. They don't seem to be
helping at all. The AI already gets an implicit ascend waypoint (they
won't go to waypoint one until they've climbed sufficiently), and
forcing unnecessary sharp turns toward the possibly mispredicted ascent
direction can mess with the AI. It's also yet another variable to
contend with when planning hold points, and hold points do essentially
the same thing.
Fixes https://github.com/Khopa/dcs_liberation/issues/352.
(cherry picked from commit 21cd764f6625db0784059a0b59a1e8a72a7a699d)
Previously we were trying to make every potential flight plan look
just like a strike mission's flight plan. This led to a lot of special
case behavior in several places that was causing us to misplan TOTs.
I've reorganized this such that there's now an explicit `FlightPlan`
class, and any specialized behavior is handled by the subclasses.
I've also taken the opportunity to alter the behavior of CAS and
front-line CAP missions. These no longer involve the usual formation
waypoints. Instead the CAP will aim to be on station at the time that
the CAS mission reaches its ingress point, and leave at its egress
time. Both flights fly directly to the point with a start time
configured for a rendezvous.
It might be worth adding hold points back to every flight plan just to
ensure that non-formation flights don't end up with a very low speed
enroute to the target if they perform ground ops quicker than
expected.
