Previously the only difference between these was the objective type:
TARCAP was for front lines and BARCAP was for everything else.
Now BARCAP is for friendly areas and TARCAP is for enemy areas. The
practical difference between the two is that a TARCAP package is like
the old front line CAP in that it will adjust its patrol time to match
the package if it can, and it will also arrive two minutes ahead of the
rest of the package to clear the area if needed.
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.
We were only getting BARCAP results right in BARCAP packages. This
fixes calculations of TOTs and start times for BARCAPs in strike
packages.
The probably needs some refactoring. BARCAP is just the symptomatic
example at the moment, but the real problem is that different mission
profiles exist and we currently only handle one. Making profiles
explicit in mission planning will clean this up, will be needed for
other future mission types, and makes it easier for us to alter
behavior for waypoint and timing decisions based on the aircraft or
mission type.
Stop using "CAP". Use BARCAP or TARCAP instead.
TARCAP no longer allowed anywhere but front lines, since that's all we
have mission planning for right now. Later will add TARCAP and BARCAP
for all objective types with different timing profiles.
Part two of the fix for
https://github.com/Khopa/dcs_liberation/issues/210.
Also fixes the CAP racetracks so the AI actually stays on station.
Waypoint TOT assignment happens at mission generation time for the
sake of the UI. It's a bit messy since we have the late-initialized
field in FlightWaypoint, but on the other hand we don't have to reset
every extant waypoint whenever the player adjusts the mission's TOT.
If we want to clean this up a bit more, we could have two distinct
types for waypoints: one for the planning stage and one with the
resolved TOTs. We already do some thing like this with Flight vs
FlightData.
Future improvements:
* Estimate the group's ground speed so we don't need such wide margins
of error.
* Delay takeoff to cut loiter fuel cost.
* Plan mission TOT based on the aircraft in the package and their
travel times to the objective.
* Tune target area time prediction. Flights often don't need to travel
all the way to the target point, and probably won't be doing it
slowly, so the current planning causes a lot of extra time spent in
enemy territory.
* Per-flight TOT offsets from the package to allow a sweep to arrive
before the rest, etc.
Changing targets doesn't make sense now that flights belong to a
package. Change all the "generate" dialogs to simply confirm dialogs
to make sure the user is okay with us clobbering the flight plan.
Mission planning on a per-control point basis lacked the context it
needed to make good decisions, and the ability to make larger missions
that pulled aircraft from multiple airfields.
The per-CP planners have been replaced in favor of a global planner
per coalition. The planner generates a list of potential missions in
order of priority and then allocates aircraft to the proposed flights
until no missions remain.
Mission planning behavior has changed:
* CAP flights will now only be generated for airfields within a
predefined threat range of an enemy airfield.
* CAS, SEAD, and strike missions get escorts. Strike missions get a
SEAD flight.
* CAS, SEAD, and strike missions will not be planned unless
they have an escort available.
* Missions may originate from multiple airfields.
There's more to do:
* The range limitations imposed on the mission planner should take
aircraft range limitations into account.
* Air superiority aircraft like the F-15 should be preferred for CAP
over multi-role aircraft like the F/A-18 since otherwise we run the
risk of running out of ground attack capable aircraft even though
there are still unused aircraft.
* Mission priorities may need tuning.
* Target areas could be analyzed for potential threats, allowing
escort flights to be optional or omitted if there is no threat to
defend against. For example, late game a SEAD flight for a strike
mission probably is not necessary.
* SAM threat should be judged by how close the extent of the SAM's
range is to friendly locations, not the distance to the site itself.
An SA-10 30 nm away is more threatening than an SA-6 25 nm away.
* Much of the planning behavior should be factored out into the
coalition's doctrine.
But as-is this is an improvement over the existing behavior, so those
things can be follow ups.
The potential regression in behavior here is that we're no longer
planning multiple cycles of missions. Each objective will get one CAP.
I think this fits better with the turn cycle of the game, as a CAP
flight should be able to remain on station for the duration of the
turn (especially with refueling).
Note that this does break save compatibility as the old planner was a
part of the game object, and since that class is now gone it can't be
unpickled.
