The UI sets these to the proper enum types; only the default is wrong.
Fix the default and clean up the associated code.
Note that this does minorly break save compatibility and alters default
behavior, since previously we were ignoring the default option. Ignoring
the default looks unintentional since there is no explicit "don't force
this option" setting in the UI.
Existing saves can be fixed simply by changing this option to something
else and then back.
Generated units are added to this during mission generation so we can
map destroyed units back to the data that generated them. Currently only
implemented for aircraft as a proof of concept.
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
We currently have three methods of choosing locations for TGOs:
1. From the campaign miz
2. From the per-CP mizdata files
3. Randomly
Move the selection among these sources into a single place and use it
everywhere that we search for a TGO location.
Longer term methods 2 and 3 will be removed.
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
Fixes https://github.com/Khopa/dcs_liberation/issues/375
This also fixes a problem where we're spawning non-cold start planes in
an uncontrolled state. The ME won't let us do this, so we probably
shouldn't be doing that.
Fixes https://github.com/Khopa/dcs_liberation/issues/375
This also fixes a problem where we're spawning non-cold start planes in
an uncontrolled state. The ME won't let us do this, so we probably
shouldn't be doing that.
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.
