Fixes the YAMLs for 3 F-14B squadrons that didn't have SEAD as an
available mission type. F-14s use SEAD for TALD deployment. The other
F-14B squadrons and all the F-14A squadrons are fine. I also removed
"Bases:" from one of the squadrons as the other squadron yamls don't
have it and it's unecessary (F-14Bs can already be based at airfields
and carriers.
If one type of unit is zeroed but there are still other units to check
in the dict, the dict will have changed size during iteration. Iterate
on a copy of the dict instead.
Fixes https://github.com/dcs-liberation/dcs_liberation/issues/2773.
The Falklands data in pydcs was missing an (unfinished, unusable)
airport, and that was breaking miz loading of campaigns that were edited
or created with a version of DCS to include these airports which have
incomplete data.
Fixes https://github.com/dcs-liberation/dcs_liberation/issues/2732.
Updated the F4.py pydcs extension to match the updated F-4B/C mod and
reworked the standard payloads to add "clean" to new F-4B pylons 11 and
12.
This includes a workaround to allow Liberation to use the new VSN F-4B
weapons with combined 2x Aim-9js on pylons 3 and 9 underslung with bombs
on ters on new pylons 11 and 12. In mission editor the combined weapons
are selected in pylons 3 and 9 and their under-slung counterparts are
forced onto 11 and 12 using "required" arguments in the mod's lua. All
other pylon 3 and 9 weapons use "required clean" arguments. Liberation
doesn't have a way to force these linkages onto pylons 11 and 12 and
without them, even without clean, no weapons will load on 3 and 9 or 11
and 12.
The workaround for normal weapons on the F-4B is to set the standard
load-outs to "clean" on pylons 11 and 12. This allows all normal weapons
to work on pylons 3 and 9 so long as pylons 11 and 12 are left as Clean.
It also allows Clean into the Liberation dropdown so it can be selected
later if necessary.
The workaround for the 4 new weapons that combines pylons 3 with 11 and
9 with 12 is that the user has to use the matching pair on each set of
pylons. For example - if F4B_LAU105_AIM9J_2_BRU42A_MK82_3 is selected
for pylon 3, BRU 42A MK823 LAU105 AIM9J2 must be selected for pylon 11.
Failure to do this correctly doesn't crash liberation or DCS, the result
will just be either no weapons at all on either pylon or the underslung
weapons on 11 and 12 floating without a pylon attaching it to the plane.
When updating f4.py in the future, note that running the pydcs database
export doesn't pull any data for Pylons 11 and 12. Those matching
weapons / classes have to be manually defined in those pylons for the
F-4B. This is noted in f4.py.
If the transport were able to move exactly the quantity of units of the
given type remaining in the transfer without moving the whole order, the
transfer order would be left with instructions to transfer zero of that
unit. That's an invariant violation, and was resulting in _later_
transfers attempting to create a convoy with zero units, which pydcs
rightly rejects.
For example: if 2 Abrams and 2 Paladins are ordered to transfer from a
disconnected FOB to a distant location that is connected by road, and
only two cargo slots are available, that transfer could be split into:
```
{
Abrams: 2
}
```
and
```
{
Abrams: 0,
Paladin: 2
}
```
Depending on the route, those airlifted units might end up still needing
road transit (we prefer short airlifts rather than direct routes because
it gives the player more opportunities to intercept enemy convoys). The
current turn would airlift the Abrams-only group and the Paladin group
would wait. On the next turn the Abrams would travel by road and the
Paladins would be airlifted. On the _third_ turn, the Paladins (and zero
Abrams) would generate an invalid convoy.
Fixes https://github.com/dcs-liberation/dcs_liberation/issues/2761.
Need to reset the persisted save paths on load, since the file that was
loaded may have been moved since it was saved and the original location
may no longer be accessible.
Fixes https://github.com/dcs-liberation/dcs_liberation/issues/2756.
The manual for the legacy warthog usually calls these VHF 1/2 and UHF,
or VHF AM/FM and UHF. The AM/FM nomenclature is what I usually hear
people call them and it's clearer, so go with that.
For the A-10C II, that manual hasn't been updated for the AN/ARC-210
yet, so I'm not really sure what that ought to be called. The UFC calls
it COM 1 though, so I went with that. The alternative would be something
like VHF/UHF for the 210 and UHF for the 164, but I don't know if that's
actually better. Could be completely explicit and call them by their
full names, but that's probably less clear to people that aren't
fiddling with the radio implementation constantly (and even I confuse
the 164 and the 186 all the damn time).
My earlier tests were not accurate enough. It turns out that yes, DCS
does still do some channel clobbering with these, so fix the radio
selection to account for that.
I also fumbled some copy paste between the A-10Cs so the A-10C II
channel assignment ended up in the wrong section doing nothing...
The latest DCS update both added support for preset radios (two both
A-10C modules!), and re-ordered the legacy A-10C's radios so we can use
the VHF radio for intra-flight.
After this patch, the legacy A-10C will use VHF for intra-flight, the
new module will use one AN/ARC-210 for intra-flight and the other for
inter-flight comms, and both modules will have preset channels assigned.
Includes the new A-10C radios. Will follow up to make Liberation
actually use them.
This manually removes some weapons from mod files that were removed from
DCS. Those mods may need re-exporting, and may also need updating by
their authors, but for now this should keep them functioning.
R-24R weapons file correction to R-3R fallback name - now matches name used in R-3R file.
Remove KH-28 weapons file due to removal from DCS.
Update KH-25MP weapons file to fallback to KH-29L instead of Kh-28. Kh-28 previously fell back to Kh-29L.
Adds US Weapons files with fallbacks in order of capability.
Aim-7P added by ED for several US fighters. Falls back to 7MH, and Aim-120B fallback adjusted from MH to P.
Aim-9J and Aim-9Juli added by ED for the Mirage F-1, also used by F-4 mod and will likely be added to the F-4E whenever it ships. Aim-9J placed between 9P and 9B, Aim-9 Juli placed between 9L and 9P5.
2x9j and 2x9Juli added by VSN for F-4 mod. Placed between 2x versions of same missiles as above.
Aim-7E now falls back to 2xAim9x instead of single Aim9x so that it runs through the entire loop of Aim-9s.
When a new flight is added to a package, if the TOT is early enough the
new flight might have a startup time in the past. Clamp the TOT when
adding new flights to the package to avoid this.
https://github.com/dcs-liberation/dcs_liberation/issues/1680
This makes the start time in WaitingForStart dynamic, which is more
expensive but probably still cheap enough.
It also checks that the new TOT will not result in a start time in the
past when the player changes the TOT.
https://github.com/dcs-liberation/dcs_liberation/issues/1680
Black rolls out style changes every year, and using "stable" means that
the check run on PRs might start formatting differently than we do
locally, or require a reformat of the codebase to make a PR submittable.
Pin to the version that we've been using. We should update to 23 at some
point, but we want to do that deliberately.
All three refueling missions share a common task type and differentiate
their behavior based on the type and allegiance of the package target.
This means that if the theater commander identifies a carrier as the
best location for a theater refueling task, a recovery tanker will be
planned by mistake.
If this happens on a sunken carrier, mission generation will fail
because a recovery tanker cannot be generated for a sunken carrier.
Fix the crash and the misplanned theater tanker by preventing the
commander from choosing fleet control points as refueling targets.
Fixes https://github.com/dcs-liberation/dcs_liberation/issues/2693.
This is the first step toward bundling all assets related to a save game
into a single item. That makes it easier to avoid clobbering "temporary"
assets from other games like the state.json, but also makes it easier
for players to file bug reports, since there's only a single asset to
upload.
This is only the first step because so far it only includes the various
save files: start of turn, end of last turn before results processing,
and "latest" (the game saved explicitly by the player).
This is by no means complete. The bugs that this solves were already in
6.x, but we'd hidden the speed controls for the sim in that release, and
have always said that anything done after pressing "go" the first time
is undefined behavior. This is the first step on making those mid-sim
actions behave correctly.
UI actions such as creating a new package need to be executed between
ticks of the sim. We can either do this synchronously by blocking the UI
until the tick is done executing, acquiring a lock on the sim, executing
the action, then releasing the lock; or asynchronously by queueing
events and letting the sim execute them when it completes the current
tick (or instantly if the sim is paused).
Anything that comes from the new UI (currently just the map) must be
asynchronous because it goes through the REST API, but for the old UI
it's simpler (and because the lock will only be acquired as quickly as
the user can act, shouldn't slow anything down) to do this
synchronously, since it's difficult to use coroutines in Qt.
https://github.com/dcs-liberation/dcs_liberation/issues/1680
Cleared the requirements.txt and rebuilt from scratch. The only thing
left un-upgraded is mypy, which I'll deal with separately because it
catches new issues.
