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
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
AI aircraft purchase decisions are now driven by the missions that the
flight planner was unable to fulfill. This way we're buying the aircraft
we actually need instead of buying them at random, in the locations we
need them, in the order they're needed.
There's a bit more that could be improved here:
* Unused aircraft could be ferried to where they would be more useful.
* Partial squadrons could be completed rather than buying a whole flight
at a time.
* Aircraft could be ranked by their usefulness so we're not buying so
many Hueys when a Hornet would do better.
* Purchase a buffer of CAP capable aircraft in case too many are shot
down and they are not available next turn.
https://github.com/Khopa/dcs_liberation/issues/361
To have an effect on turn zero these need to be enabled in the wizard.
Since the last page was getting quite full I've split it into two pages:
one for the objective generation options and a second for the difficulty
and player assist options.
I also added an option to set the inital budget for opfor.
The procurement AI now uses the same system as the players. Orders are
placed and take a turn to fulfill.
This has a few advantages:
* We no longer need special case purchase logic for the turn 0
population of opfor airbases.
* Players using auto-purchase can cancel orders they don't like.
The allows the players to use the same auto-purchase mechanics that the
AI uses. The behavior is very bad, but it's no worse than what OPFOR
deals with.
There's a lot that needs to be improved before this is really a good
choice for the player:
* Option to adjust budget balance between front lines and airbases.
* Disallow negative budgets (which incidentally will cause more aircraft
to be purchased, since the armor purchases currently accidentally
spend the aircraft budget).
* Buy less randomly: https://github.com/Khopa/dcs_liberation/issues/361.
* Obey parking limits.
* Use the delivery events rather than instant delivery (also allows the
player to cancel orders they don't want).
Fixes https://github.com/Khopa/dcs_liberation/issues/362
For now this is mostly behavior preserving. I slightly improved the
ability to buy units when multiple front lines exist by removing full
bases as candidates, but it should be a minor change at best. A larger
improvement will come later.
This is also written such that it will work for the player as well. The
procurer currently runs for the player but with all the options off, so
it does nothing. The next patch allows adds options for the player to
use auto-procurement.
This adds both player and enemy income multiplier options. Note that
previously the AI was only getting 75% of their income. I've changed
that to give them their full income by default since the player can now
influence it.
Repairing a damaged runway costs $100M and takes 4 turns (one day). The
AI will always repair runways if they can afford it. if a runway is
damaged again during the repair the process must begin again.
Runways are still operational despite what the UI says. Preventing the
player and AI from using damaged runways (except for with helicopters
and harriers) is next.
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)
Generated units are added to this during mission generation so we can
map destroyed units back to the data that generated them. Currently only
implemented for aircraft as a proof of concept.
Breaks save compat, but we need to have this knowledge outside the UI so
we can know whether or not we can ferry aircraft to the airfield without
overflowing parking.
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
`FrontLine` is tightly coupled with `ConflictTheater`.
Moved into the same module to prevent circular imports.
Moved `ConflictTheater.frontline_data` from class var
to instance var to allow save games to have different
versions of frontlines.
* Move the UI code out of the plugin logic.
* Add types where needed.
* Move into game package.
* Improve error handling.
* Simplify settings behavior.
* Don't load disabled plugins.
* Remove knowledge of non-base plugins from game generation.
Fixes https://github.com/Khopa/dcs_liberation/issues/311
Capturing bases is sometimes really annoying because of the DCS unit
AI and our non-optimal ground victory heuristics. Add a cheat option
to allow the player to move on without the tedium.
Weather and exact time of day information is helpful during mission
planning, so generate it at the start of the turn rather than at
takeoff time.
Another advantage aside from planning is that we can now use the wind
information to set carrier headings and takeoff runways appropriately.
- load plugins when loading a game
- moved plugins scripts to resources/plugins (for pyinstaller)
- removed vanilla JTAC and JTAC_smoke options and settings GUI
- call JtacAutolasePlugin in armor.py
- made a dictionary of INSTALLED_PLUGINS
- removed NIOD from the VEAF plugin
Mission planning on a per-control point basis lacked the context it
needed to make good decisions, and the ability to make larger missions
that pulled aircraft from multiple airfields.
The per-CP planners have been replaced in favor of a global planner
per coalition. The planner generates a list of potential missions in
order of priority and then allocates aircraft to the proposed flights
until no missions remain.
Mission planning behavior has changed:
* CAP flights will now only be generated for airfields within a
predefined threat range of an enemy airfield.
* CAS, SEAD, and strike missions get escorts. Strike missions get a
SEAD flight.
* CAS, SEAD, and strike missions will not be planned unless
they have an escort available.
* Missions may originate from multiple airfields.
There's more to do:
* The range limitations imposed on the mission planner should take
aircraft range limitations into account.
* Air superiority aircraft like the F-15 should be preferred for CAP
over multi-role aircraft like the F/A-18 since otherwise we run the
risk of running out of ground attack capable aircraft even though
there are still unused aircraft.
* Mission priorities may need tuning.
* Target areas could be analyzed for potential threats, allowing
escort flights to be optional or omitted if there is no threat to
defend against. For example, late game a SEAD flight for a strike
mission probably is not necessary.
* SAM threat should be judged by how close the extent of the SAM's
range is to friendly locations, not the distance to the site itself.
An SA-10 30 nm away is more threatening than an SA-6 25 nm away.
* Much of the planning behavior should be factored out into the
coalition's doctrine.
But as-is this is an improvement over the existing behavior, so those
things can be follow ups.
The potential regression in behavior here is that we're no longer
planning multiple cycles of missions. Each objective will get one CAP.
I think this fits better with the turn cycle of the game, as a CAP
flight should be able to remain on station for the duration of the
turn (especially with refueling).
Note that this does break save compatibility as the old planner was a
part of the game object, and since that class is now gone it can't be
unpickled.
