The old mode where squadrons started empty and had no size limit is
going away.
I bumped the campaign versions for the ones that claimed support and
tested a handful. All of Fuzzle's campaigns actually had the wrong
version in the yaml. They claim support for this but none that I tested
actually fit within the limits (despite having sizes defined). Either it
was supposed to be 10.7, or maybe the airports lost some parking.
1000km isn't large enough in the case where there's an off-map spawn
that's a long way from the target, but still in range for aircraft like
the B-1. Double it, which for now is enough to fix the one pathological
case we know.
Fixes https://github.com/dcs-liberation/dcs_liberation/issues/3156.
Another step in reducing the rigidity of FlightPlan and making it
testable.
There is one intentional behavior change here: escort flights no longer
request escorts. That actually has a very minimal effect because these
properties are only used for two things: determining if a package needs
escorts or not, and determining when the TARCAP should show up and
leave. Since escorts won't have been in the package when the first part
happens anyway, that has no effect. The only change is that TARCAP won't
show up earlier or stay later just because of a TOT offset for an escort
flight.
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.
Rather than having a separate faction file that is identical to the Russia 1975 faction file but includes the Hind, might as well just add the Hind to the standard Russia 1975 faction.
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.
There's an ugly special case in flight simulation to handle hold points
because we don't differentiate between the total time between two
waypoints (which can include delays from actions like holding) and
travel time. Split those up and remove the special case.
The CAS flight plan tweaks break save compat in a way that's not as easy
to fix. Accept it and drop the existing hacks since they won't be useful
any more.
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 fuzz test generates random inputs for waypoint solvers to check if
they can find a solution. If they can't, the debug info for the solver
is dumped to the testcases directory. Another test loads those test
cases, creates a solver from them, and checks that a solution is found.
Obviously it won't be immediately, but it's a starting point for fixing
the bug and serves as a regression test afterward.
This is a replacement for the existing "zone geometry" classes that are
currently used for choosing locations for IP, hold, and join points.
The older approach required the author to define the methods for
choosing locations at a rather low level using shapely APIs to merge or
mask geometries. Debug UIs had to be defined manually which was a great
deal of work. Worse, those debug UIs were only useable for *successful*
waypoint placement. If there was a bug in the solver (which was pretty
much unavoidable during development or tuning), it wasn't possible to
use the debug UI.
This new system adds a (very simple) geometric constraint solver to
allow the author to describe the requirements for a waypoint at a high
level. Each waypoint type will define a waypoint solver that defines one
or more waypoint strategies which will be tried in order. For example,
the IP solver might have the following strategies:
1. Safe IP
2. Threat tolerant IP
3. Unsafe IP
4. Safe backtracking IP
5. Unsafe backtracking IP
We prefer those in the order defined, but the preferred strategies won't
always have a valid solution. When that happens, the next one is tried.
The strategies define the constraints for the waypoint location. For
example, the safe IP strategy could be defined as (in pseudo code):
* At least 5 NM away from the departure airfield
* Not farther from the departure airfield than the target is
* Within 10 NM and 45 NM of the target (doctrine dependent)
* Safe
* Within the permissible region, select the point nearest the departure
airfield
When a solver fails to find a solution using any strategy, debug
information is automatically written in a GeoJSON format which can be
viewed on geojson.io.
Fixes https://github.com/dcs-liberation/dcs_liberation/issues/3085.
Includes an Argentina 1982 faction for testing purposes, although it's
sparse because of a lack of assets in DCS.
Note that the carrier is mispelled as the Vienticinco in the game.
Includes prerequisite pydcs update.
Fixes https://github.com/dcs-liberation/dcs_liberation/issues/3123.
