This PR
- Introduces replanning of missions after continuing a turn.
- A new doctrine field setting the AEWC mission duration that was
previously hard coded.
This PR addresses #3337 by:
- Updating the UI to identify that a destroyed carrier/LHA as "Sunk"
- Fall back on targeting other groups in the NavalControlPoint (e.g.
escorts if present) if the carrier/LHA is sunk.
This is enabled by default because I can't think of a time where it's
ever been more fun to watch the AI run out of fuel after cycling between
afterburner and speedbrake for twenty minutes.
This is only lightly tested (I verified that the task shows up
appropriately in the ME when set, not when unset, and never for
players), since the interesting part of the implementation is up to ED.
Fixes https://github.com/dcs-liberation/dcs_liberation/issues/3201.
This is just the refactor to make way for the real change: adding a
package page to the kneeboard so players can get package-level
information like other radio, laser, and STNs.
This doesn't need to be a part of FlightPlan, and it's easier to test if
it isn't. Move it out and add the tests.
It's pretty misleading to allow this in the core of the flight plan code
anything. This is an extremely unreliable estimate for most aircraft so
it should be more clearly just for briefing purposes.
Create a WaypointAction class that defines the actions taken at a
waypoint. These will often map one-to-one with DCS waypoint actions but
can also be higher level and generate multiple actions. Once everything
has migrated all waypoint-type-specific behaviors of
PydcsWaypointBuilder will be gone, and it'll be easier to keep the sim
behaviors in sync with the mission generator behaviors.
For now only hold has been migrated. This is actually probably the most
complicated action we have (starting with this may have been a mistake,
but it did find all the rough edges quickly) since it affects waypoint
timings and flight position during simulation. That part isn't handled
as neatly as I'd like because the FlightState still has to special case
LOITER points to avoid simulating the wrong waypoint position. At some
point we should probably start tracking real positions in FlightState,
and when we do that will be solved.
Putting the ingress point directly on one end of the FLOT means that AI
flights won't start searching and engaging targets until they reach that
point. If the front line has advanced toward the flight's departure
airfield, it might overfly targets on its way to the IP.
Instead, place an IP for CAS the same way we place any other IP. The AI
will fly to that and start searching from there.
This also:
* Removes the midpoint waypoint, since it didn't serve any real purpose
* Names the FLOT boundary waypoints for what they actually are
Fixes https://github.com/dcs-liberation/dcs_liberation/issues/2231.
This property affects safe compat because the ID is what gets preserved
in the save, but it's unfortunately also used as the display name, which
means changing the display name breaks save compat. It also prevents us
from changing display names without breaking faction definitions.
This is the first step in fixing that. The next is adding a separate
display_name property that can be updated without breaking either of
those.
This isn't a great fix for the reason I mention in the comment, but it's
quick and actually is accurate since it looks like we don't actually
handle formation speeds correctly in most cases...
This is probably as "fixed" as this is going to get for now since most
of the flight planning code is in the process of being rewritten.
https://github.com/dcs-liberation/dcs_liberation/issues/3113
We don't need explicit configuration of initial points. The plane
automatically configures any steerpoint immediately before a target
point as an initial point.
Target offset points and aim points have not been implemented because I
can't find any information the describes their intent.
Fixes https://github.com/dcs-liberation/dcs_liberation/issues/3088.
This makes it possible to have the right laser code set for hot start
aircraft that (typically) do not allow changing laser codes when the
engine is on.
The release behavior isn't used yet, but I'm working on pre-allocating
laser codes for front lines and flights to make it easier for players to
pick the laser codes for their weapons.
* Store a deque rather than an iterator so it can be pickled
* Remove mangling from staticmethod (and rename now that it's no longer
a generator)
* Rename "get" to "alloc" to make the mutation clear
* Move to its own package (the changes I'm working on make this no
longer mission generator specific)
* Remove useless exception class. It's never caught so the unique type
isn't needed
If the package does not have a tanker, the refueling task will cause AI
flights to go to an arbitrary tanker, which may cause them to fly
through enemy territory or even go farther than their arrival airbase.
It's also not remotely possible for every AI flight in the game to
refuel in most missions. There's typically one tanker and dozens of
aircraft that would previously attempt to refuel.
Fixes https://github.com/dcs-liberation/dcs_liberation/issues/2716.
We want other pieces of country information (in particular the short
names). This cleans up a lot of code anyway.
As an added bonus, this now catches squadrons that used invalid names
which would previously be passed through to pydcs and... then I don't
know what would happen.
There isn't really any need for these two types to interact. The lua
plugin manager effectively fully owned its properties, it just delegated
all reads and writes to the settings object.
Instead, break the plugin settings out into the plugin manager and
preserve the manager in the Game. This will make it possible to expose
plugin options in the NGW without breaking the game on cancel.
All three refueling missions share a common task type and differentiate
their behavior based on the type and allegiance of the package target.
This means that if the theater commander identifies a carrier as the
best location for a theater refueling task, a recovery tanker will be
planned by mistake.
If this happens on a sunken carrier, mission generation will fail
because a recovery tanker cannot be generated for a sunken carrier.
Fix the crash and the misplanned theater tanker by preventing the
commander from choosing fleet control points as refueling targets.
Fixes https://github.com/dcs-liberation/dcs_liberation/issues/2693.
mypy struggles to prove this cast correct when there are two or'd
isinstance checks where both types coincidentally have properties of the
same name (but no defined protocol making that explicit). I'm not really
sure why mypy is happy with this in its current state, but it isn't
after a change I'm making.
All our isinstance use is a bit of an anti-pattern anyway, so extract a
method that exposes the data we care about.
The start/end times for tankers aren't actually used, so this could be
simplified even more, but that data _should_ be used.
There doesn't appear to be any reason for us to be poking at
implementation details here aside from changing the name from "unit" to
"building" for that case. Just iterate over the known strike targets.
Making this change uncovered some latent type errors.
Fixes https://github.com/dcs-liberation/dcs_liberation/issues/2564.
