We currently have three methods of choosing locations for TGOs:
1. From the campaign miz
2. From the per-CP mizdata files
3. Randomly
Move the selection among these sources into a single place and use it
everywhere that we search for a TGO location.
Longer term methods 2 and 3 will be removed.
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.
Like with deleting waypoints, these will degrade the flight plan to the
2.1 behavior.
Ascend/descend points aren't in use any more, so I removed those.
Fighter sweeps arrive at the target ahead of the rest of the package
(currently a fixed 5 minute lead) to clear out enemy fighters and then
RTB.
Fixes https://github.com/Khopa/dcs_liberation/issues/348
`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.
This also removes ascend/descend waypoints. They don't seem to be
helping at all. The AI already gets an implicit ascend waypoint (they
won't go to waypoint one until they've climbed sufficiently), and
forcing unnecessary sharp turns toward the possibly mispredicted ascent
direction can mess with the AI. It's also yet another variable to
contend with when planning hold points, and hold points do essentially
the same thing.
Fixes https://github.com/Khopa/dcs_liberation/issues/352.
(cherry picked from commit 21cd764f6625db0784059a0b59a1e8a72a7a699d)
* 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
- 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.
