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.
Especially considering the button in this position used to be how
players added client slots, confirm that they in fact want to launch
an AI-only mission before launching, and guide them toward the new UI.
Calling logging.basicConfig creates a stream handler for the root
logger, and then we were adding our own with a different formatter.
Pass the format string to basicConfig so we don't need to add our own
duplicate stream handler.
Logging before we've made it to the logging setup was causing the root
logger to be permanently configured to the default (warning) log
level, so we weren't getting any info or debug logs any more.
Defer the campaign data load until it is needed rather than doing it
at import time. I've also cleaned up a bit so we only load each
campaign once, rather than re-loading the campaign to create the
theater again after the wizard is finished.
Avoids crowding the taxiways, and adds some life to the end of the
mission.
Later on, this will happen more naturally because we can delay
takeoffs to align with the package's DTOT.
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.
Mission planning has been completely redone. Missions are now planned
by right clicking the target area and choosing "New package".
A package can include multiple flights for the same objective. Right
now the automatic flight planner is only fragging single-flight
packages in the same manner that it used to, but that can be improved
now.
The air tasking order (ATO) is now the left bar of the main UI. This
shows every fragged package, and the flights in the selected package.
The info bar that was previously on the left is now a smaller bar at
the bottom of the screen. The old "Mission Planning" button is now
just the "Take Off" button.
The flight plan display no longer shows enemy flight plans. That could
be re-added if needed, probably with a difficulty/cheat option.
Aircraft inventories have been disassociated from the Planner class.
Aircraft inventories are now stored globally in the Game object.
Save games made prior to this update will not be compatible do to the
changes in how aircraft inventories and planned flights are stored.
Make the type of the waypoint a non-optional part of the constructor.
Every waypoint needs a type, and there's no good default (the previous
default, `TAKEOFF`, is actually unused). All of the target waypoints
were mistakenly being set as `TAKEOFF`, so I've fixed that in the
process.
Also, fix the bug where only the last custom target of a SEAD
objective was being added to the waypoint list because the append was
scoped incorrectly.
