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.
