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.
Mission planning has been completely redone. Missions are now planned
by right clicking the target area and choosing "New package".
A package can include multiple flights for the same objective. Right
now the automatic flight planner is only fragging single-flight
packages in the same manner that it used to, but that can be improved
now.
The air tasking order (ATO) is now the left bar of the main UI. This
shows every fragged package, and the flights in the selected package.
The info bar that was previously on the left is now a smaller bar at
the bottom of the screen. The old "Mission Planning" button is now
just the "Take Off" button.
The flight plan display no longer shows enemy flight plans. That could
be re-added if needed, probably with a difficulty/cheat option.
Aircraft inventories have been disassociated from the Planner class.
Aircraft inventories are now stored globally in the Game object.
Save games made prior to this update will not be compatible do to the
changes in how aircraft inventories and planned flights are stored.
In order to be able to customize the scripts that can be injected in the
mission, a __plugin.lst file is read and the scripts mentionned in this
file are injected (through DoScriptFile and not DoScript).
A mechanism checks if a standard script (Mist, JTACAutolase) has
already been loaded, to avoid loading them twice.
Adds the following:
* AJS37
* AV-8B
* JF-17
This does move the preset channel allocation logic into its own class,
since we need to customize that behavior for the AJS37 since it has a
rather unique preset channel layout (see the comments in
`ViggenRadioChannelAllocator` for details).
I've been wrongly importing these from `pydcs.dcs` instead of just
`dcs`, because that was what PyCharm thought they were. These will all
be broken when we get back to using a real pydcs instead of relying on
its directory being in our tree.
This page in the wiki should be updated:
https://github.com/Khopa/dcs_liberation/wiki/Developer's-Guide
Instead of recommending that `PYTHONPATH` be updated in the run
configuration, it should instead recommend that Settings -> Project:
dcs_liberation -> Project Structure be set to exclude the pydcs
directory from the dcs_liberation content root, and add the pydcs
directory as a *separate* content root.
Alternatively, we could recommend that configure a virtualenv (good
advice anyway, and pycharm knows how to set them up) that have people
run `pip install -e pydcs`.
I think even easier would be switching from the virtualenv-style
requirements.txt to pipenv, which can actually encode the `-e` style
pip install into its equivalent of requirements.txt.
I removed the nav target info from the briefing because that doesn't
seem to have been doing what it was intended to do. It didn't give any
actual target information, all it would show was (example is a JF-17
strike mission):
PP1
PP2
PP3
PP4
Without any additional context that doesn't seem too helpful to me.
I'll be following up (hopefully) shortly by adding target information
(type, coordinates, STPT/PP, etc) to both the briefing and the
kneeboard that will cover that.
Refactor a bunch to share some code with the kneeboard generator as
well.
Add central registries for allocating TACAN/radio channels to the
Operation. These ensure that each channel is allocated uniquely, and
removes the caller's need to think about which frequency to use.
The registry allocates frequencies based on the radio it is given,
which ensures that the allocated frequency will be compatible with the
radio that needs it. A mapping from aircraft to the radio used by that
aircraft for intra-flight comms (i.e. the F-16 uses the AN/ARC-222)
exists for creating infra-flight channels appropriate for the
aircraft. Inter-flight channels are allocated by a generic UHF radio.
I've moved the inter-flight radio channels from the VHF to UHF range,
since that's the most easily allocated band, and inter-flight will be
in the highest demand.
Intra-flight radios are now generally not shared. For aircraft where
the radio type is not known we will still fall back to the shared
channel, but that will stop being the case as we gain more data.
Tankers have been moved to the Y TACAN band. Not completely needed,
but seems typical for most missions and deconflicts the tankers from
any unknown airfields (which always use the X band in DCS).
This includes most of the briefing information in the kneeboard:
* Airfield info
* Waypoint info
* Comm info
* AWACS
* Tankers
* JTAC
There's more that could be done:
* Restrict tankers to the type compatible with the current aircraft
* Support for carriers
* Merge all relevant comm info (tankers, AWACS, JTAC, other flights)
into the comm ladder
This gives us a good start and a framework to build on. Very likely
that we'll want to split part of this (probably the comm ladder) off
onto a separate page once we start adding more to this, since it's a
pretty full page currently.
Also missing is any checking that the contents do not go beyond the
bounds of the page. We could add this if needed. For now the page has
enough room for about a dozen waypoints, which is quite a bit more
than most missions need.
