This makes it possible to have the right laser code set for hot start
aircraft that (typically) do not allow changing laser codes when the
engine is on.
This PR addresses #3066 by restricting the list of control points in the
new unit transfer dialog to control points reachable from the origin.
This change centralizes the logic for reachable nodes to the
TransitNetworkBuilder class.
This PR was tested by:
1. Loading save from #3066
2. Using cheat menu to destroy runway at Wadi al Jandali
3. Purchasing units at any of the other control points
4. Pass the turn to allow the purchase to complete
5. Initiating a unit transfer from the other control point and
confirming that Wadi al Jandali does not show up in the list
Steps 2-4 are needed as no ground units show up at Melez when loading
the save directly from the latest dev build.
Fixes https://github.com/dcs-liberation/dcs_liberation/issues/3066.
The release behavior isn't used yet, but I'm working on pre-allocating
laser codes for front lines and flights to make it easier for players to
pick the laser codes for their weapons.
* Store a deque rather than an iterator so it can be pickled
* Remove mangling from staticmethod (and rename now that it's no longer
a generator)
* Rename "get" to "alloc" to make the mutation clear
* Move to its own package (the changes I'm working on make this no
longer mission generator specific)
* Remove useless exception class. It's never caught so the unique type
isn't needed
Use the new data from pydcs to improve the properties UI:
* Use human readable names
* Use appropriate control types
* Limit min and max values as appropriate for each property
* Show labels
Fixes https://github.com/dcs-liberation/dcs_liberation/issues/3090.
These are read unconditionally, but were only initialized when the
coalition had nodes. When a coalition had no nodes, this caused a nil
access. It's unclear if that had any symptoms, but I expect at the very
least it would break the remainder of the script (so a non-functioning
blue IADS if the red IADS had no nodes).
There's a very small chance this is the culprit behind
https://github.com/dcs-liberation/dcs_liberation/issues/3073.
There isn't any UI observable behavior of the dragend of the waypoint,
but we can test that the backend was called. The only uncovered parts of
that component are now error paths, but the error handling in that
component is to just ignore errors, so there's also nothing to test
there.
Unlike the other map tests which heavily rely on mocks, this one uses
React refs to inspect the constructed leaflet objects. The DOM itself
doesn't appear to contain anything worth testing against (react-leaflet
rendering doesn't work like typical React rendering).
This required some infrastructure changes:
1. Forwarded ref from WaypointMarker to Marker so the test can observe
it. Added a mergeRefs helper (and its own tests) to make that easier.
2. Switched from identity-obj-proxy to jest-transform-stub, because the
former doesn't produce a useable image for imports, and we need
usable images for leaflet to be able to render.
This doesn't yet test drag and drop behavior since that requires mocking
the backend, and this commit is already complicated enough. That'll be
next.
The flight plan used to not include a waypoint for departure, so a few
places would create one for the sake of the UI, or were built to assume
there was a missing waypoint that was okay to ignore. At some point we
added them to the flight plan, but never updated the UI, so the waypoint
list in the flight dialog started counting from 1 instead of 0, and the
openapi endpoint wrongly reported two departure waypoints to the front-
end.
Fixes https://github.com/dcs-liberation/dcs_liberation/issues/3037.
DCS AI cannot yet use LGBs.
A2G loadouts for anti-unit have been switched to CBU-97s, which appear
to be the most effective weapon type.
A2G loadouts against static targets (OCA/aircraft, OCA/runway, strike)
have been change to Mk82s and Mk84s.
