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.
The timing for these doesn't work. Sweep RTBs at the same time the
package reaches its TOT. The tanker won't be on station until 1m30s
before the package reaches the refueling point.
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.
The next step in splitting up the layout and scheduling phases. This
facilitates splitting flights into two classes where one has a full
flight plan, but one used in the earlier phases of planning has only a
layout. Layout-only flights won't need TOTs, which will make them much
easier to work with once we've migrated TOTs from timedeltas to
datetimes.
Layout-only flights of course aren't actually usable, but it lets us
avoid dealing with the current sim time until we're certain the Flight
will even survive planning.
I'm not actually sure if we'll be able to split the two phases any more,
but this ends up being a nice cleanup anyway.
We can always estimate a startup time now. Remove the nullability from
the result, cleanup the callsites, and eliminate
TotEstimator.mission_start_time since it no longer does anything useful.
Flights without a meaningful TOT make the code around startup time (and
other scheduling behaviors) unnecessarily complicated because they have
to handle unpredictable flight plans. We can simplify this by requiring
that all flight plans have a waypoint associated with their TOT. For
custom flight plans, we can just fall back to the takeoff waypoint. For
RTB flight plans (which are only synthetic flight plans injected for
aborted flights), we can use the abort point.
This also means that all flight plans now have, at the very least, a
departure waypoint. Deleting this waypoint is invalid even for custom
flights, so that's no a problem.
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.
- Add the new airassault mission type and special flightplans for it
- Add the mission type to airbase and FOB
- Add Layout for the UH-1H
- Add mission type to capable squadrons
- Allow the auto planner to task air assault missions when preconditions are met
- Improve Airlift mission type and improve the flightplan (Stopover and Helo landing)
- Allow Slingload and spawnable crates for airlift
- Rework airsupport to a general missiondata class
- Added Carrier Information to mission data
- Allow to define CTLD specific capabilities in the unit yaml
- Allow inflight preload and fixed wing support for air assault
* Fix suicide SEAD flights (diving to the SAM)
additional fix for #2152. This sets the Target Waypoint ALT to the Ingress ALT for non player flights. Player flights will have the target waypoint set to 0 AGL so that they can slave weapons or TGP to it.
* Add GroupAttack to SEAD so that they suppress more
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.
