Follow up work:
* Data entry. I plan to do the air-to-air missiles in the near term. I
covered some variants of the AIM-120, AIM-7, and AIM-9 here, but there
are variants of those weapons for each mounting rack that need to be
done still, as well as all the non-US weapons.
* Arbitrary start dates.
https://github.com/Khopa/dcs_liberation/issues/490
This feature allows you to cancel the sales of aircraft or ground vehicles if needed.
Upon clicking the minus button, a count of sold units will be appended to the unit count. This count responds to both further presses of the minus button, and also to presses of the plus button. No further units will be requested for the next turn until all sold units have been re-bought.
I've tested a bunch of different scenarios with this:
- Selling and rebuying a unit - the budget increases and decreases as expected.
- Selling one unit, buying a unit worth the new player budget, and then trying to rebuy the old unit - the old unit cannot be rebought until the budget has been freed up for it.
- Closing the base window and re-opening it - the sold unit count is retained.
- Ending the turn - the sold unit count is reset back to 0 as expected.
Contributes to Khopa/dcs_liberation#365
Mildly breaks save compat with 2.3; All existing flight dialogs will be
broken, passing the turn or recreating all the flights in the UI will
allow you to continue
This isn't perfect because the auto planner might still target it. We
need a larger refactoring for target iteration so we don't need to
remember all the special rules at each call site. For now, this restores
the 2.3.2 behavior.
Fixes https://github.com/Khopa/dcs_liberation/issues/681
On station time for CAP is only 30 minutes, so plan three cycles to give
~90 minutes of CAP coverage.
Default starting budget has increased significantly to account for the
greatly increased aircraft needs on turn 1.
Fixes https://github.com/Khopa/dcs_liberation/issues/673
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
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
Not converting all at once so I can prove the concept. After that we'll
want to cover all the cases where an int distance or speed is a part of
the save game (I've done one of them here with `Flight.alt`) so further
cleanups don't break save compat.
https://github.com/Khopa/dcs_liberation/issues/558
Moves all TOT planning into the FlightPlan to clean up specialized
behavior and improve planning characteristics.
The important part of this change is that flights are now planning to
the mission time for their flight rather than the package as a whole.
For example, a TARCAP is planned based on the time from startup to the
patrol point, a sweep is planned based on the time from startup to the
sween end point, and a strike flight is planned based on the time from
startup to the target location. TOT offsets can be handled within the
flight plan.
As another benefit of theis cleanup, flights without hold points no
longer account for the hold time in their planning, so those flights are
planned to reach their targets sooner.
As a follow up TotEstimator can be removed, but I want to keep this low
impact for 2.3.2.
Fixes https://github.com/Khopa/dcs_liberation/issues/593
(cherry picked from commit 745dfc71bca10407b1151a7e41483e3a2110a76e)
Moves all TOT planning into the FlightPlan to clean up specialized
behavior and improve planning characteristics.
The important part of this change is that flights are now planning to
the mission time for their flight rather than the package as a whole.
For example, a TARCAP is planned based on the time from startup to the
patrol point, a sweep is planned based on the time from startup to the
sween end point, and a strike flight is planned based on the time from
startup to the target location. TOT offsets can be handled within the
flight plan.
As another benefit of theis cleanup, flights without hold points no
longer account for the hold time in their planning, so those flights are
planned to reach their targets sooner.
As a follow up TotEstimator can be removed, but I want to keep this low
impact for 2.3.2.
Fixes https://github.com/Khopa/dcs_liberation/issues/593
Just emit the signal to update the budget rather than trying to figure
out the heirarchy of the UI.
Fixes https://github.com/Khopa/dcs_liberation/issues/581
(cherry picked from commit 7d907aac0f644f55bda42ec916eb2be054aefcf5)
