- B52, A-20, and Tu-22 will level bomb targets
- When there is an unit group as target, all the units are now engaged instead of only the first unit of the group
first pass briefing refactor
briefing fixes
briefing fixes
Stop briefing generate being called twice
Stop frontline advantage string being appended
when there are no units.
jinja template
always return enum instance in Strategy Selector
For some reason on DEFENSE, enum is appended to control point stance,
but on all other the enum.value is added instead.
I don't see any case where the value is used, but there are many
cases that the enum instance is evaluated against.
type issue
junja's not a thing
swap mapping with dict
jinja template
always return enum instance in Strategy Selector
For some reason on DEFENSE, enum is appended to control point stance,
but on all other the enum.value is added instead.
I don't see any case where the value is used, but there are many
cases that the enum instance is evaluated against.
type issue
Update build.yml
junja's not a thing
swap mapping with dict
Restore build job
Previously we were trying to make every potential flight plan look
just like a strike mission's flight plan. This led to a lot of special
case behavior in several places that was causing us to misplan TOTs.
I've reorganized this such that there's now an explicit `FlightPlan`
class, and any specialized behavior is handled by the subclasses.
I've also taken the opportunity to alter the behavior of CAS and
front-line CAP missions. These no longer involve the usual formation
waypoints. Instead the CAP will aim to be on station at the time that
the CAS mission reaches its ingress point, and leave at its egress
time. Both flights fly directly to the point with a start time
configured for a rendezvous.
It might be worth adding hold points back to every flight plan just to
ensure that non-formation flights don't end up with a very low speed
enroute to the target if they perform ground ops quicker than
expected.
Somehow this constant was wrong so all of our foot-to-meter
conversions were coming out ~7% too large. We're still introducing
some error because we're rounding early rather than only when we need
an integer, but it's much more accurate now.
- dcsLiberation.installPath does not include "state.json" anymore
- corrected behavior :
- try LIBERATION_EXPORT_DIR
- then try dcsLiberation.installPath
- then try TEMP
- then try working directory
- corrected multiple bugs in dcs_liberation.lua
- corrected bad string.format causing DCS crashes in
jtacautolase-config.lua
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
- the base LUA functionality has been implemented as a mandatory plugin
- the jtacautolase functionality has been implemented as a plugin
- added a VEAF framework plugin
The plugins have GUI elements in the Settings window.
When the mission is aborted the pending mission is still in the event
list, which is part of the game option. That event has a reference to
the operation, which in turn contains all the mission generator
objects. Two of these objects are the radio/TACAN allocators, which
use a generator to track the next free channel. Generators cannot be
picked, so because these are transitively part of the game object the
game cannot be saved.
Aside from the briefing generator, none of those objects are
actually needed outside the generation function itself, so just make
them locals instead.
This probably needs a larger refactor at some point. It doesn't look
like we need so many calls into the operation type (it has an
initialize, a prepare, and a generate, and it doesn't seem to need
anything but the last one). The only reason breifinggen needs to
remain a part of the class is because the briefing title and
description are filled in from the derived class, where title and
description should probably be overridden properties instead. I'm also
not sure if we need to make the event list a part of game at all, and
also don't think that the mission needs to be one of these events.
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.
