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
* Introduce a real type.
* Rewrite _transform_point to make use of Point.
* Add shift modifier for large (10 pixel) adjustements to reference
points. Unmodified behavior is now single pixel.
* Use WASD for moving the second point (shift modified numpad keys don't
seem to work).
* Add a debug option to draw transformed reference points to check for
errors. If they don't overlap, something is wrong.
* Cleaned up all the existing reference points. Caucasus in particular
is now *much* better.
As an added bonus, the cleanup for carrier movement projection now also
shows an invalid destination when the destination is on land.
To improve IADS design in campaigns, this differentiates required long
and medium range SAMs. SAMs that must be long range SAMs are defined by
SA-10 or Patriot launchers, while medium range SAMs are defined by SA-2,
SA-3, or Hawk launchers.
Long range SAMs positions will only be populated by long range SAMs
(Patriots and SA-10s), and not all factions have those available. Medium
range SAMs currently comprise all air defenses that are not long range
SAMs, so if the faction includes flak guns in their `sams` property then
flak guns may be spawned at medium range SAM locations.
Base defenses and random SAM locations continue to use either type of
SAM.
Locations that should always be SAMs should be done with fixed IADs
locations, so we don't need the separate type.
The generic "ground strike location" needs to be eventually split up
into more specific types, so eventually all of the non-base defense SAMs
will go away.
Removed always True "event successful"
Add `AirWarEvent` as the primary game `Event` applied to every miz
Cleanup of `FrontLineAttackEvent`
Change `Operation.is_awacs_enabled` to two bools for each side red/blue
Currently controlled by whether an AWACs is available for the faction
(and only ever true for Blue)
The AI isn't making use of these yet, but it's not smart enough to do so
anyway.
Would benefit from an icon to differentiate it on the map.
I'm stretching the definition of "control point" quite a bit. We might
want to put a class above `ControlPoint` for `AirSpawnLocation` to
represent types of spawn locations that can't be captured and don't have
ground objectives.
Fixes https://github.com/Khopa/dcs_liberation/issues/274
"Required" SAMs (designative by redfor long range SAM launchers in the
ME) will always be spawned during campaign generation. This makes it
possible to build a semi-guaranteed IADS (the exact type of SAM is
dependent) on the choice of faction.
Requierd SAMs will consume the slots of random SAMs during generation.
Later we should differentiate between strategic SAMs like SA-10s and
tactical SAMs like SA-11s so we can fill in the medium range SAMs at
random locations among the fixed long range SAMs.
Defining a campaign using a miz file instead of as JSON has a number of
advantages:
* Much easier for players to mod their campaigns.
* Easier to see the big picture of how objective locations will be laid
out, since every control point can be seen at once.
* No need to associate objective locations to control points explicitly;
the campaign generator can claim objectives for control points based
on distance.
* Easier to create an IADS that performs well.
* Non-random campaigns are easier to make.
The downside is duplication across campaigns, and a less structured data
format for complex objects. The former is annoying if we have to fix a
bug that appears in a dozen campaigns. It's less an annoyance for
needing to start from scratch since the easiest way to create a campaign
will be to copy the "full" campaign for the given theater and prune it.
So far I've implemented control points, base defenses, and front lines.
Still need to add support for non-base defense TGOs.
This currently doesn't do anything for the `radials` property of the
`ControlPoint` because I'm not sure what those are.
