Breaks save compat because it adds new fields to `Flight` that have no
constant default. Removing all of our other save compat at the same
time.
Note that player flights with a divert point will have a nav point for
their actual landing point. This is because we place the divert point
last, and DCS won't let us have a land point anywhere but the final
waypoint. It would allow a LandingReFuAr point, but they're only
generated for player flights anyway so it doesn't really matter.
Fixes https://github.com/Khopa/dcs_liberation/issues/342
All of the callers are passing altitude in meters because that's what
pydcs uses. This still returns knots which makes it extra weird, but
that's what almost all of the callers expect.
It's probably a good idea to introduce some explicit types for the
various distance and speed units to avoid these sorts of mistakes.
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.
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
BAI is used for attacking ground vehicles as opposed to buildings like
strike does, and not air defenses like DEAD does. Unlike strike, BAI is
tolerant of moving targets.
Fixes https://github.com/Khopa/dcs_liberation/issues/216
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.
Fighter sweeps arrive at the target ahead of the rest of the package
(currently a fixed 5 minute lead) to clear out enemy fighters and then
RTB.
Fixes https://github.com/Khopa/dcs_liberation/issues/348
`FrontLine` is tightly coupled with `ConflictTheater`.
Moved into the same module to prevent circular imports.
Moved `ConflictTheater.frontline_data` from class var
to instance var to allow save games to have different
versions of frontlines.
This also removes ascend/descend waypoints. They don't seem to be
helping at all. The AI already gets an implicit ascend waypoint (they
won't go to waypoint one until they've climbed sufficiently), and
forcing unnecessary sharp turns toward the possibly mispredicted ascent
direction can mess with the AI. It's also yet another variable to
contend with when planning hold points, and hold points do essentially
the same thing.
Fixes https://github.com/Khopa/dcs_liberation/issues/352.
(cherry picked from commit 21cd764f6625db0784059a0b59a1e8a72a7a699d)
Was using the interval from mission start to latest rather than from
earliest to latest, so this could sometimes be off by a bit and cause
us to not generate enough start times.
- B52, A-20, and Tu-22 will level bomb targets
- When there is an unit group as target, all the units are now engaged instead of only the first unit of the group
We were calculating the TOT based on travel time to the *flight's*
target, but the ingress point based on the travel time to the target
area. If the difference in travel time between the center of the
target area and the first target were different then we'd calculate
the start time incorrectly even for single flight packages.
Seems to fix https://github.com/Khopa/dcs_liberation/issues/295
The increased precision that we had everywhere except the UI and the
interface with DCS was causing issues with ASAP creating barely
negative start times. The main cause of this was that we'd compute the
earliest possible TOT, it would result in, for example, 23:10.002.
When we then set the QTimeEdit for the TOT, we have to round because
it does not support (nor do we really want to display) sub-second
values, which then caused the previously 0 start time to be -0.002.
Instead, since the sub-second values aren't really interesting anyway,
we now just round TOTs up and start times down. This should prevent
negative start times from occurring (except when they've been manually
planned as such), and also prevents start times of 00:00:01.
Also rounds the package waypoint times to avoid the same issues, but
it's not really important which direction we round these.
Fixes https://github.com/Khopa/dcs_liberation/issues/295
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.
