* Added a separate Doctrine page in settings with the following new options:
- Minimum number of aircraft for autoplanner to plan OCA packages against
- Airbase threat range (nmi)
- TARCAP threat buffer distance (nmi)
- AEW&C threat buffer distance (nmi)
- Theater tanker threat buffer distance (nmi)
Implemented handling for the OPFOR autoplanner aggressiveness in objectivefinder.py vulnerable_control_points().
* * Added three new options in Settings:
- Autoplanner plans refueling flights for Strike packages
- Autoplanner plans refueling flights for OCA packages
- Autoplanner plans refueling flights for DEAD packages
Fixed a bug in faction.py where F-16Ds were not correctly removed from the faction when the F-16I/F-16D mod was not selected.
* Renamed Maximum frontline length -> Maximum frontline width.
Troops must be dropped inside this zone or they won't attack the target.
The zone needs to be drawn in the map so players don't break the flight
plan by accidentally moving the drop waypoint outside the DZ.
I've move the API for doing this out of `PatrollingFlightPlan` in favor
of a mixin so this is no longer presented as `engagement_distance` by
the flight plan. I don't love that it's still the `commit-boundary`
endpoint, but it's fine for now.
I don't know why mypy wasn't able to catch this. pycharm is also
struggling to understand this class.
This isn't actually the data that callers usually want. Most of the
callers just want the bounds. The heading and length are trivially
computed from that. Add a class to contain the result so it's easier to
refactor.
It replaces the FRONTLINE_LENGTH constant, which was used previously. The default setting for the frontline length has been set to match the FRONTLINE_LENGTH value (80 km), but I feel the default should be a bit shorter. Discussion on the topic would be welcome.
Squashing 8 commits by DanAlbert:
- Track theater in ControlPoint.
Simplifies finding the owning theater of a control point. Not used yet.
- Clean some cruft out of FlightPlanBuilder.
- Clean up silly some exception handling.
- Move FlightPlan instantiation into the builder.
I'm working on moving the builder to be owned by the Flight, which will simplify callers that need to create (or recreate) flight plans for a flight.
- Simplify IBuilder constructor.
We have access to the theater via the flight's departure airbase now.
- Move FlightPlan creation into Flight.
For now this is just a callsite cleanup. Later, this will make it easier
to separate unscheduled and scheduled flights into different classes without complicating the layout/scheduling.
- Remove superfluous constructors.
- Remove unused Package field.
During package planning we don't care about the details of the flight
plan, just the layout (to check if the layout is threatened and we need
escorts). Splitting these will allow us to reduce the amount of work
that must be done in each loop of the planning phase, potentially
caching attempted flight plans between loops.
Split the oversized file into one per plan type. This also moves the
layout responsibility out of the oversized FlightPlanBuilder and into
each flight plan type file.
