A was intended to be the blue point and B was intended to be the red
point. Make this a part of the name so that's clear, and clean up
related code to keep that reliable.
`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.
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
We estimate the longest possible time from mission start to TOT for
all flights in a package and use that to set the TOT (plus any delay
used to stagger flights). This both cuts down on loiter time for
shorter flights and ensures that long flights will make it to the
target in time.
This is also used to compute the start time for the AI, so the
explicit delay option is no longer needed.
The first waypoint is automatically added by pydcs, so it's not
actually in our waypoint list from the flight planner. Import is from
the group so it shows up in the kneeboard.
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.
