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.
This is optional because I really don't know if I trust it. I don't see
much wrong with it (aside from the warning about not using it with auto-
resolve, because it won't restore lost aircraft), but it's really not
something I'd built for since it's not going to be possible as the RTS
features grow.
Fixes https://github.com/dcs-liberation/dcs_liberation/issues/2735.
We want other pieces of country information (in particular the short
names). This cleans up a lot of code anyway.
As an added bonus, this now catches squadrons that used invalid names
which would previously be passed through to pydcs and... then I don't
know what would happen.
We're still using mostly the same aircraft selection as we have before
we added squadrons: the closest aircraft is the best choice.
This adds an option to obey the primary task set by the campaign
designer (can be overridden by players), even if the squadron is farther
away than one that is capable of it as a secondary task.
I don't expect this option to live very long. I'm making it optional for
now to give people a chance to test it, but it'll either replace the old
selection strategy or will be removed.
Fixes https://github.com/dcs-liberation/dcs_liberation/issues/1892.
Preferred aircraft per task are now determined by a ranking of weights
stored in the aircraft yaml files. To aid in visualizing the priorities
across aircraft, Liberation can be run with the argument
dump-task-priorities to dump a yaml file in Saved
Games/DCS/Liberation/Debug/priorities.yaml, which will show each task
along with priority sorted aircraft and their weights.
The current weights in the data were exported from the existing lists,
where each position from the bottom of the list was worth 10 (to allow
some games for less shuffling later).
Fixes https://github.com/dcs-liberation/dcs_liberation/issues/2809.
There isn't really any need for these two types to interact. The lua
plugin manager effectively fully owned its properties, it just delegated
all reads and writes to the settings object.
Instead, break the plugin settings out into the plugin manager and
preserve the manager in the Game. This will make it possible to expose
plugin options in the NGW without breaking the game on cancel.
We should also persist mod options, but those will go in a separate file
because they aren't a part of Settings.
Plugins need some work before that can be saved here. They're not
configurable in the NGW currently, so that needs to be fixed first. It
also appears that it may not be safe to inject the settings object with
plugin options until the game is created, but that needs more
investigation (see the comment in Settings.save_player_settings).
Another obvious candidate would be the desired player mission duration,
but we need to implement custom serialization for that first.
The mechanism for how this bug arises is that the *WaypointGenerator*
uses the *FlightWaypoint.waypoint_type* to decide whether to generate
the waypoint in the .miz file using a *DeadIngressBuilder* or a
*SeadIngressBuilder*. This *waypoint_type* is set by
*ato.flightplans.<sead|dead>.Builder*, which is set when *ato.flight* is
initialised in the *Flight._flight_plan_builder* member variable based
on *Flight.flight_type*. When *Flight.flight_type* is updated when the
flight is changed from SEAD->DEAD, *Flight._flight_plan_builder* is not
updated in the development build, resulting in it continuing to generate
SEAD waypoints.
This PR adds *set_flight_type()* which sets the *flight_type* property
and updates *Flight._flight_plan_builder* and uses this function when
converting flight types. Ideally, *flight_type* should be made private
and only accessed through getter/setter functions that encapsulate this
behavior, but that would mess up any existing liberation save files.
This PR was tested by:
1. Opening the save file from Issue 2779 in the development build
2. Clicking "Take Off" and confirming that the Weapon Release Type is
"Guided" at the Ingress Waypoint as described in the issue.
3. Opening the save file from Issue 2779 in this PR
4. Converting the SEAD2DEAD flight from DEAD back to SEAD, and then from
SEAD to DEAD
5. Clicking "Take Off" and confirming in the mission editor that the
SEAD2DEAD flight has Weapon Release Type set to "Auto" at the Ingress
Waypoint.
Fixes https://github.com/dcs-liberation/dcs_liberation/issues/2779.
