Finished the F-104C mod support of version 2.7.11.222.01, which was included during a new export after the livery-scanner was introduced. Includes VSN_F104C banner by GLOBAL HAWK. Banner includes the official VSN logo by J.P. Ferré. Used with permission.
Co-Authored-By: MetalStormGhost <89945461+MetalStormGhost@users.noreply.github.com>
We'll have to get smarter about this some day (since turn initialization
won't always exist), but for now we can avoid stale UI data by doing
what we've always done and refreshing the world on turn init.
Fixes https://github.com/dcs-liberation/dcs_liberation/issues/2397.
This makes the oil platform a required building so that all factions can
use it. Alternatively, we could pick a different offshore target for WW2
factions, or gracefully degrade to not generating these targets for WW2
factions. This approach seems to best match the designer's intent.
Fixes https://github.com/dcs-liberation/dcs_liberation/issues/2322.
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.
