During package planning we don't care about the details of the flight
plan, just the layout (to check if the layout is threatened and we need
escorts). Splitting these will allow us to reduce the amount of work
that must be done in each loop of the planning phase, potentially
caching attempted flight plans between loops.
Split the oversized file into one per plan type. This also moves the
layout responsibility out of the oversized FlightPlanBuilder and into
each flight plan type file.
It would probably be more accurate to have the icon based on the
aircraft type and use the modifier to indicate the mission, but this
will do for now (I also might have that backwards, I can't find the
guidance because it's in STANAG 1241 which isn't free).
I also increased the icon size a bit in the UI because the longest icon
text ("SEAD") was hard to read.
Still more could be done here by caching the merged poly at the theater
level, but this goes a long way.
Aircraft commit regions are already cached (in the FlightState), so
those are already fairly fast. The combined A2A commit boundary could
also potentially be cached at the theater level.
A serverconfig.env (or just environment variables) can be set to
override the default bind address/port for the backend. This is passed
to the front end as a query parameter.
This is now feature complete with the exception of the ruler, none of
which seem to work with react. Someone that understands JS packaging
better than I do (which is a very low bar) will need to have a look.
https://github.com/dcs-liberation/dcs_liberation/issues/2039
There are still two more of these that don't show up in openapi.json
because they don't show up in HTTP routes (only in the websocket):
* GameUpdateEvents
* FrozenCombat
I'm not sure if there's a way to forcibly include those in the
openapi.json, if I should add a no-op API to force it to happen, or if I
should just ignore it. For now I'm going with option 3.
operation_ids give us better function names when generating the
typescript API from the openapi.json. BaseModel.Config.title does the
same for type names. Response models (or 204 status codes) need to be
explicit or the API will be declared as returning any.
The React UI running in a browser can't connect to the backend without
punching a hole for CORS, which isn't done by default. We don't need the
API key to protect from browsers, and anything else running on the
user's machine that can access the backend (that's hosted on only
localhost) already has enough control to do damage without using
Liberation as an attack vector.
https://github.com/dcs-liberation/dcs_liberation
