FastAPI uses JsonResponse by default, which will convert the empty
response None to null. We need to forcibly use Response instead to
prevent that for No Content responses.
This didn't cause any observable issues but was polluting the log.
If the user's DCS directory is not configured correctly this will
degrade by not showing an icon. Otherwise (and typically) we get nicer
looking icons for each theater, and we don't have to make these for each
new map.
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).
