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.
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.
- 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
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.
This appears to be incompatible with pyinstaller. I get the following
when trying to run the executable generated with pyside6:
```
Traceback (most recent call last):
File "qt_ui\main.py", line 29, in <module>
File "PyInstaller\loader\pyimod03_importers.py", line 476, in exec_module
File "qt_ui\windows\QLiberationWindow.py", line 28, in <module>
File "PyInstaller\loader\pyimod03_importers.py", line 476, in exec_module
File "qt_ui\widgets\map\QLiberationMap.py", line 11, in <module>
ImportError: could not import module 'PySide6.QtPrintSupport'
```
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
Moves all TOT planning into the FlightPlan to clean up specialized
behavior and improve planning characteristics.
The important part of this change is that flights are now planning to
the mission time for their flight rather than the package as a whole.
For example, a TARCAP is planned based on the time from startup to the
patrol point, a sweep is planned based on the time from startup to the
sween end point, and a strike flight is planned based on the time from
startup to the target location. TOT offsets can be handled within the
flight plan.
As another benefit of theis cleanup, flights without hold points no
longer account for the hold time in their planning, so those flights are
planned to reach their targets sooner.
As a follow up TotEstimator can be removed, but I want to keep this low
impact for 2.3.2.
Fixes https://github.com/Khopa/dcs_liberation/issues/593
The AI isn't making use of these yet, but it's not smart enough to do so
anyway.
Would benefit from an icon to differentiate it on the map.
I'm stretching the definition of "control point" quite a bit. We might
want to put a class above `ControlPoint` for `AirSpawnLocation` to
represent types of spawn locations that can't be captured and don't have
ground objectives.
Fixes https://github.com/Khopa/dcs_liberation/issues/274
Like with deleting waypoints, these will degrade the flight plan to the
2.1 behavior.
Ascend/descend points aren't in use any more, so I removed those.
Like with deleting waypoints, these will degrade the flight plan to the
2.1 behavior.
Ascend/descend points aren't in use any more, so I removed those.
In almost every case this leaves us with a flight plan we can't reason
about, so it gets degraded to `CustomFlightPlan`. The exception is when
deleting a target point when there are other target points remaining.
This probably gets people using this feature back to what they want
though, which is essentially the 2.1 behavior.
Fixes https://github.com/Khopa/dcs_liberation/issues/393
In almost every case this leaves us with a flight plan we can't reason
about, so it gets degraded to `CustomFlightPlan`. The exception is when
deleting a target point when there are other target points remaining.
This probably gets people using this feature back to what they want
though, which is essentially the 2.1 behavior.
Fixes https://github.com/Khopa/dcs_liberation/issues/393
This was also needed in other parts of the UI and is easier to implement
in the target class anyway.
Note that DEAD is now properly restricted to air defense targets.
Also added error boxes to the UI for when planning fails on an invalid
target.
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.
