The new introduced layout system extends the mission generation so that a campaign designer can now define the heading of the ground objects which will be also used later in mission generation to orient the group accordingly. This removes the randomization of the orientation from the generation.
Most campaigns will not need any updates and will work out of the box.
added the fill property to the layout groups which allows to specify if a optional layout group should be filled with a faction accessible unit if it was not defined by the preset groups. This is usefull to allow more generalized templates which for example may or may not have a Search Radar without adding one to all layouts (example: Rapier and Roland Sites which use the generic SHORAD layout)
this fixes an issue which prevented optional units like logistics to be added to the forcegroup if they were not defined in the preset group yaml
This allows unique identification across saves. The front-end needs to
be able to differentiate the first carrier in game A and the first
carrier in game B, but because carriers (and other non-airfield CPs) are
assigned IDs sequentially, collisions were to be expected. The front-end
can't tell the difference between a reloaded game and a new turn, so we
need to ensure different IDs across games.
This is a handy cleanup anyway, since callers constructing CPs no longer
need to manually track the CP ID counter.
Fixes https://github.com/dcs-liberation/dcs_liberation/issues/2078.
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.
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
https://stackoverflow.com/a/44888113/632035
Pickle can't deal with loading sets (and probably dicts) of objects with
custom __hash__ functions that depend on their state because __hash__
can be called before __setstate__. Make the hash function stupider (but
still correct) by just relying on the object ID.
This may not be the way to do this long term, but it is how the old map
works so it's at least not a regression. It might be better to generate
events for the between-turn changes in state instead.
https://github.com/dcs-liberation/dcs_liberation/issues/2039
The UI needs to be able to identify these to the server and vice versa,
so they'll need IDs that don't change. Rather than constructing an ID
based on the control points names, make them an owned part of the
control point. The constructed ID would be fine, but a UUID will make
them more suitable for the database, and this was always fairly gross
anyway.
Some follow up work if anyone is interested: a bunch of the data that's
computed in the various properties can now probably be computed *once*
and persisted to the FrontLine type.
