* A Bluefor EWR 55GS in the campaign miz defines an optional EWR site. There is no distinction between how close or far it is to a base, so it's possible that there will be many EWRs within an airbase.
* A Redfor EWR 1L13 in the campaign miz defines a required EWR site.
It would be a good future idea to limit the amount of EWRs within a certain distance from an airbase. That way there's no chance of 5 EWRs all at the same airbase. Even better if there were something preventing any two EWRs from being right next to each other.
No campaigns take advantage of this yet.
Fixes https://github.com/Khopa/dcs_liberation/issues/524
Still a work in progress (the missions don't actually perform their task, just orbit). Currently:
* AEW&C aircraft can be bought.
* AEW&C missions can be planned at any control point and at front lines.
* AEW&C will return after 4H or Bingo.
Allowing these to grow infinitely leads to some really weird behaviors
when the enemy has been buying reserves long enough, where capturing a
base might result in 80 enemy vehicles suddenly at the gates.
This is just an interim fix. Ideally these units would be reinforcing
the front line as needed
(https://github.com/Khopa/dcs_liberation/issues/382), and a CP could be
lost without needing to completely destroy the defender.
If there are not airbases withing ferry range with available parking for
the aircraft then the aircraft will be captured and sold. Otherwise the
aircraft will retreat to the closest available airbase.
Fixes https://github.com/Khopa/dcs_liberation/issues/693
If the captured base has no connection to other friendly objectives (the
base was encircled) then the enemy equipment will be captured and sold.
Otherwise the units will retreat toward connected bases.
Partial fix for https://github.com/Khopa/dcs_liberation/issues/693.
Still need to fix this for air units.
We were never resetting the dead state for repaired SAMs. Rather than
tracking that manually, determine liveness from the number of units left
alive.
For building objectives where the group is not assigned to the TGO until
*mission* generation time we still need manual tracking.
(cherry picked from commit d3b1f6110f23b72c67d2ab86585087115004390d)
We were never resetting the dead state for repaired SAMs. Rather than
tracking that manually, determine liveness from the number of units left
alive.
For building objectives where the group is not assigned to the TGO until
*mission* generation time we still need manual tracking.
Some SAMs have multiple groups (such as an SA-10 group with its
accompanying SA-15 and SA-19 groups). This shows each group's threat and
detection separately on the map, and also makes it so that an SA-10 with
dead radars will no longer contribute to the threat zone just because
the shilka next to it still has a functioning radar.
https://github.com/Khopa/dcs_liberation/issues/647
Fixes https://github.com/Khopa/dcs_liberation/issues/672
Holes in the inclusion zone are defined by exclusion zones, not by holes
in the inclusion zone. Add a cached property for the inclusion zone that
is not also sea or exclusion zone and use that boundary instead.
Converts the landmap to use MultiPolygon instead of a collection of
polygons, since Shapely has explicit support for this.
Because we've done that, we can use a single projection from a line
instead of brute forcing the extent of the front line.
This makes turn processing ~66% faster (3 seconds to 1.8).
There are probably other places this should be used.
Started with TARCAP because they're simple, but will follow and extend
this to the other flight plans next.
This works by building navigation meshes (navmeshes) of the theater
based on the threat regions. A navmesh is created for each faction to
allow the unique pathing around each side's threats. Navmeshes are built
such that there are nav edges around threat zones to allow the planner
to pick waypoints that (slightly) route around threats before
approaching the target.
Using the navmesh, routes are found using A*. Performance appears
adequate, and could probably be improved with a cache if needed since
the small number of origin points means many flights will share portions
of their flight paths.
This adds a few visual debugging tools to the map. They're disabled by
default, but changing the local `debug` variable in `DisplayOptions` to
`True` will make them appear in the display options menu. These are:
* Display navmeshes (red and blue). Displaying either navmesh will draw
each navmesh polygon on the map view and highlight the mesh that
contains the cursor. Neighbors are indicated by a small yellow line
pointing from the center of the polygon's edge/vertext that is shared
with its neighbor toward the centroid of the zone.
* Shortest path from control point to mouse location. The first control
point for the selected faction is arbitrarily selected, and the
shortest path from that control point to the mouse cursor will be
drawn on the map.
* TARCAP plan near mouse location. A TARCAP will be planned from the
faction's first control point to the target nearest the mouse cursor.
https://github.com/Khopa/dcs_liberation/issues/292
Creates threat zones around airfields and non-trivial air defenses (it's
not worth dodging anything with a threat range under 3nm). These threat
zones can be used to aid mission planning and waypoint placement.
https://github.com/Khopa/dcs_liberation/issues/292
