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.
This isn't the grouped layer control that we have in the non-react map.
The react variant of that hasn't been updated in years and won't work
with our base maps (and may not work at all). We'll need to fix that or
write our own if we want to use that. This will do for now though.
https://github.com/dcs-liberation/dcs_liberation/issues/2039
There was accidentally a second layer of callback here. I'm not sure why
it worked. I think the lambda being returned was being used as the
cleanup function?
The vulnerabilities are false positives and React doesn't think those
are worth fixing to make `npm audit` be quiet. We can at least make them
go away for `npm audit --production`, which is the official advice:
https://github.com/facebook/create-react-app/issues/11174.
Useful for development if you want to disable API key authentication for
debugging the server without having to pull the generated key out of the
log every time.
This gets us out of the business of maintaining our own icons. The
milsymbol library generates the SVG data needed to display anything
covered by APP-6.
- The SA-8 LD unit hat the SA-13 unit name as variant. The Layout tried to create a SA-13 SHORAD Site but actually used an SA-8 LD unit instead with zero threat range. This resulted in a yellow marked GroundObject on the map
- Cleaned up the treat and radar range functions a bit
There are some TODOs here but th behavior is flagged off by default. The
biggest TODO here is that the time spent frozen is not simulated, so
flights that are engaged by SAMs will unfreeze, move slightly, then re-
freeze.
https://github.com/dcs-liberation/dcs_liberation/issues/1680
If there's a websocket being waited on the shut down won't actually
happen. Add a new event for shut down and send it to break the websocket
out of its loop.
