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.
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.
yaml to json
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.
The weapon laser codes can be set more easily from the weapon laser code
combo box. Setting the properties explicitly here will just cause
conflicts and annoying UI bugs. Hide those properties from the UI.
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.
* Helicopter waypoint altitude configurable
Added a new option in Settings: Helicopter waypoint altitude (feet AGL).
It sets the waypoint altitude for helicopters in feet AGL. In campaigns in more mountainous areas, you might want to increase this setting to avoid the AI flying into the terrain.
* black?
* Distinguish cruise/combat altitudes for helicopters
Also includes a refactor for WaypointBuilder so it doesn't need a coalition. It can already reference the coalition from the flight.
* Update changelog.md
---------
Co-authored-by: Raffson <Raffson@users.noreply.github.com>
* 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
Use the new data from pydcs to improve the properties UI:
* Use human readable names
* Use appropriate control types
* Limit min and max values as appropriate for each property
* Show labels
Fixes https://github.com/dcs-liberation/dcs_liberation/issues/3090.
These are read unconditionally, but were only initialized when the
coalition had nodes. When a coalition had no nodes, this caused a nil
access. It's unclear if that had any symptoms, but I expect at the very
least it would break the remainder of the script (so a non-functioning
blue IADS if the red IADS had no nodes).
There's a very small chance this is the culprit behind
https://github.com/dcs-liberation/dcs_liberation/issues/3073.
