- Moved logic from TGO to TheaterGroup and Unit, cleanup
- Fixed an issue with wrong radar threat zone calculation
- Correctly handle dead and alive units in threat calculation (dead units are no more threats...)
- Fixed wrong air_defenses threat zone used for planning (now uses aa-capable tgos instead of all tgos for the CP)
- Remove the might_have_aa property from TGOs and actually check if there is any aa-capable unit present (this is needed as with the recent tgo refactor all type of TGOs can also have anti air units if they have some defined in the layout)
This is briefly moving us over to my fork of pydcs while we wait for
https://github.com/pydcs/dcs/pull/206 to be merged. The adaptation is
invasive enough that I don't want it lingering for long.
- completly refactored the way TGO handles groups and replaced the usage of the pydcs ground groups (vehicle, ship, static) with an own Group and Unit class.
- this allows us to only take care of dcs group generation during miz generation, where it should have always been.
- We can now have any type of unit (even statics) in the same logic ground group we handle in liberation. this is independent from the dcs group handling. the dcs group will only be genarted when takeoff is pressed.
- Refactored the unitmap and the scenery object handling to adopt to changes that now TGOs can hold all Units we want.
- Cleaned up many many many lines of uneeded hacks to build stuff around dcs groups.
- Removed IDs for TGOs as the names we generate are unique and for liberation to work we need no ids. Unique IDs for dcs will be generated for the units and groups only.
This alters the DEAD task planning to be the *least* preferred task, but
prevents other tasks from being planned unless they are excepted to be
clear of air defenses first. Even so, missions are a guaranteed success
so those other missions will still get SEAD escorts if there's potential
for a SAM in the area.
This means that air defenses that are not protecting a more useful
target (like a convoy, armor column, building, etc) will no longer be
considered by the mission planner. This isn't *quite* right since we
currently only check the target area for air defenses rather than the
entire flight plan, so there's a chance that we ignore IADS that have
threatened ingress points (though that's mostly solved by the flight
plan layout).
This also is still slightly limited because it's not checking for
aircraft availability at this stage yet, so we may aggressively plan
missions that we should be skipping unless we can guarantee that the
DEAD mission was planned. However, that's not new behavior.
The usual symptom here was the game breaking when a carrier is
destroyed. The carrier would no longer be operational but missions would
be assigned there that could not generate flight plans.
Target the air defenses whose *threat ranges* come closest to friendly
bases rather than the closest sites themselves. In other words, the
SA-10 that is 5 miles behind the SA-6 will now be the priority.
This also treats EWRs a bit differently. If they are not protected by a
SAM their detection range will be used for determining their "threat"
range. Otherwise a heuristic is used to determine whether or not they
can be safely attacked without encroaching on the covering SAM.
We shouldn't consider the non-escorted parts of the flight path when
checking for threats to determine if escorts should be used or not,
since escorts can't help in those areas anyway. This was causing escorts
to be overly requested since the bullseye is now a part of the
"flight plan", but could have also triggered for divert waypoints, or
for aircraft taking off in a retreat from a threatened location.
This is an interim improvement since we should probably be pushing the
BARCAPs into TARCAP roles when the front line is so close. This does
regress flight pathing for anything that should route around the front
(to avoid getting shot at by SHORADS and TARCAPs), but for now it's one
or the other and this is the one everyone's complaining about.
Limit the commit range of a BARCAP to halfway to the closest enemy
airbase so that they don't become offensive missions.
This has the side effect of largely reducing long retreats to hold
points from front line airfields, since the package can get much closer
without being at risk of engagement by an enemy BARCAP.
Fixes https://github.com/Khopa/dcs_liberation/issues/742.
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
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
