The dataclass contructor will not automatically convert the int in the
JSON file to the enum type, so our enum equivalence check was not
actually working, and could result in us re-allocating a TACAN channel
that was used by the map.
Fixing this problem surfaces a latent bug, where we can't actually treat
duplicate map TACAN channels as a bug because some channels are used by
multiple airports in PG.
This isn't related to the missiongenerator, and importing this file from
some places (such as runway data) will cause a circular reference when
importing the rest of the missiongenerator package.
This update includes expanded runway data that lets us clean up some
code. It also include beacon IDs for runways and airfields that will let
us get ILS and TACAN info from pydcs, but that's a bigger change that
I'll land separately.
Instead of comparing to some deduced radius in case of a quad-point trigger,
use pydcs' Polygon.point_in_poly to determine if a position is located inside the zone.
The new behavior is as follows for SAMs:
No damaged units: fully capable (green)
Damaged but still operational: present (no bar)
Not fully destroyed but inoperable: damaged (yellow)
Fully destroyed: destroyed (red)
And for all other TGOs:
Fully destroyed: destroyed (red)
Any missing units: damaged (yellow)
No missing units: present (no bar)
Fixes https://github.com/dcs-liberation/dcs_liberation/issues/2438.
This isn't actually the data that callers usually want. Most of the
callers just want the bounds. The heading and length are trivially
computed from that. Add a class to contain the result so it's easier to
refactor.
This looks like it was just a typo. We want to join as late as possible
to allow flights coming from other airfields to take the best route to
the target that is safe, rather than joining as early as possible, which
isn't useful since pre-join and post-split are supposed to be safe areas
anyway.
The for_theater method is always called before for_airport is during
normal gameplay, but I'm writing a linter to show missing airfield data
that calls for_airport first.
This shouldn't be the case for anything shipped, but is typical when new
theaters are still being developed.
We could potentially add an `in_progress` flag to the theater definition
to make this only optionally tolerant, but since that code path would
rarely be exercised it's just likely to bitrot. This data isn't critical
to mission generation anyway, so this is fine. What we should do is add
some linters that document all the data that is missing though (and
ideally publish that to our docs).
Fixed (zombie) carrier killed in state.json but always respawning in-game, issue #2405. GenericCarrierGenerator.generate() will now generate the ship group with an array that only contains alive ship units, just like GroundObjectGenerator.generate() has previously done.
Carrier groups will now also show up as destroyed/damaged on the map when the carrier is sunk.
Causes an exception otherwise, and at the same time a perfect example why a strongly typed language would be better in this case, because this would've been caught by a compiler!
It replaces the FRONTLINE_LENGTH constant, which was used previously. The default setting for the frontline length has been set to match the FRONTLINE_LENGTH value (80 km), but I feel the default should be a bit shorter. Discussion on the topic would be welcome.
