fix a number of regressions in the flight waypoint list by changing the
indexing and finding a work-around to blocking of signals
This PR addresses some (but not all) recently reported issues with the
waypoints screen reported in Issue #3188 . This PR was tested by:
- Changing the waypoint altitude and confirming it shows up correctly
when reloading the waypoint list window and on the map
- Adding a waypoint and confirming that it shows up immediately and
persists on reload
- Deleting a waypoint (except the first waypoint) and confirming that it
is removed immediately and persists on reload,
Known issues: first waypoint (typically hold) cannot be deleted -- still
looking into this one.
Fixes https://github.com/dcs-liberation/dcs_liberation/issues/3188.
Moves the stretch to the bottom of the page to avoid awkward whitespace
in the middle. Presumably the totals used to be at the bottom (since
that's a normal place for a total), but it was moved to the top,
probably since that was the most interesting data and we didn't want to
scroll though all the details to find that one point.
This also removes the unused code path where the total would be shown at
the bottom.
Fixes https://github.com/dcs-liberation/dcs_liberation/issues/1288.
This property affects safe compat because the ID is what gets preserved
in the save, but it's unfortunately also used as the display name, which
means changing the display name breaks save compat. It also prevents us
from changing display names without breaking faction definitions.
This is the first step in fixing that. The next is adding a separate
display_name property that can be updated without breaking either of
those.
The weapon laser codes can be set more easily from the weapon laser code
combo box. Setting the properties explicitly here will just cause
conflicts and annoying UI bugs. Hide those properties from the UI.
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.
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.
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.
If we're going to show a game over dialog, we need to do so before
moving to the next turn, but we will still want to show the debriefing
window. Move those steps to happen after the debrief window.
https://github.com/dcs-liberation/dcs_liberation/issues/978
Any real end game dialog needs a "new game" button. If only the main
window can usefully call the NGW we'd have to plumb that object through
and call into it from that dialog, which is gross. Just make it easier
to call the wizard.
https://github.com/dcs-liberation/dcs_liberation/issues/978
The aircraft banners are only used for the unit info window, and that's
not a normal part of gameplay. We spend a bit over 1.5 seconds
preloading this data at startup (about 25% of the non-game load startup
time). This data is only expensive to load in aggregate, and we never
need all of it. The unit info window is not noticeably slowed by this,
but startup is noticeably faster without it.
I think someone just copied this pattern from the icons where the suffix
represented the icon size. These are definitely not 24px banners, and
some of the suffixes are even wrong (_25).
It's not feasible to actually check the parking limits because we can't
identify parking limits for carriers until the theater is populated.
Doing so is expensive (and depends on other NGW inputs). Instead,
compare against the version of the campaign and guess.
A new (minor) campaign version has been introduced which makes this
required to improve the UI hint. Campaigns that are compatible with the
new rules should update their version to advertise support.
Fixes https://github.com/dcs-liberation/dcs_liberation/issues/2909.
This also changes the window close button of the air wing configuration
dialog to cancel rather than revert and continue, because otherwise
there's no way for the user to back out of the dialog without fixing all
the overfull bases first.
Fixes https://github.com/dcs-liberation/dcs_liberation/issues/2910.
This does show the theoretical parking use of full squadrons even when
the new rules are not enabled. Since limits can be enabled manually
later in the game, it's still useful information, even if it's a bit
misleading.
https://github.com/dcs-liberation/dcs_liberation/issues/2910
Want to move this deeper into the launch process so that it can use the
UI, but don't want to pass the loosely typed argparse namespace any
more than we have to.
