This is a new faction that expands on the current PMC Russian faction by
adding in a substantial number of new units for additional variety and
challenge. It'll be the default faction for my helicopter campaign (I'll
open a PR for that tomorrow. It's all done apart from the campaign
description).
This PR refactors the Doctrine class to load from YAML files in the
resources folder instead of being hardcoded as a step towards making
doctrines moddable (Issue #829).
I haven't added anything to the changelog as a couple of things should
get cleaned up first:
- As far as I can tell, the flags in the Doctrine class (cap, cas, sead
etc.) aren't used anywhere. Need to test further, and if they're truly
not used, will remove them.
- Probably need to update the Wiki
I've come to realise that two external tanks is overkill for pretty much
all A2G mission types. The AI no longer have a problem with fuel, and
player flights will essentially never run out of fuel with the 2 CFTs
and a single external tank. I have done 700+ mile trips at mil power the
whole way with fuel to spare. I have therefore switched all A2G mission
loadouts to a single tank. A2A loadouts still carry 2 tanks, as players
may require the extra fuel if they make very extensive use of
afterburner in air combat.
It turns out the GBU31v3 JDAMs are bugged in more than one way. We've
known that they vanish if carried in pairs on the CFT pylons, but now it
turns out their penetration doesn't actually work. This means they are
no better in any way than the GBU31v1s, which are not bugged on CFT
pylons.
I have therefore removed the penetrator JDAMs from all loadouts,
replacing them with regular JDAMs.
Adds the Aim-9P3 between the Aim-9P5 and the Aim-9P. Also adds fallback
support for sidewinder versions for the VSN 104 mod, the JAS39 mod, and
the AJS-37.
If we don't do this, the uvicorn server may log its shutdown after the
Qt application has closed, and the signal this attempts to emit may not
be valid. Disconnect the log signals when the application exits to
prevent that.
There's actually another solution that I thought would be better, but I
couldn't get it to work:
https://www.pyinstaller.org/en/stable/feature-notes.html#automatic-hiding-and-minimization-of-console-window-under-windows
describes a way to have pyinstaller hide or minimize the console rather
than disabling it entirely. I was never really fond of getting rid of
the console window in the first place, but it did bother some users. If
we could get the hide or minimize option working, that'd probably avoid
bothering users, but also make the logs much easier to find, get us out
of the trouble of maintaining our own log viewer, and fix the problem
mentioned in the comment I add here (the log window only works if
there's only one in memory log handler).
Another option would be ditching our log window and instead just having
that menu item open the log file or directory in whatever program the OS
defaults to (probably notepad). It would still have the quirk of maybe
needing to open more than one location, since logging is use
configurable.
Fixes https://github.com/dcs-liberation/dcs_liberation/issues/3278.
One of the newer versions got a lot more strict. It now only expects
dicts that match the model, or objects of the model. Previously it also
accepted objects which had the same properties as the model. Convert a
few more LatLngs to LeafletPoints.
Fixes https://github.com/dcs-liberation/dcs_liberation/issues/3279.
I forgot to test the pyinstaller binary when I upgraded all the other
dependencies, and there's a breaking change in 6.0.0:
https://pyinstaller.org/en/latest/CHANGES.html#incompatible-changes
> All of onedir build's contents except for the executable are now moved
> into a sub-directory (called _internal by default). sys._MEIPASS is
> adjusted to point to this _internal directory. The breaking
> implications for this are:
>
> * Assumptions that os.path.dirname(sys.executable) == sys._MEIPASS
> will break. Code locating application resources using
> os.path.dirname(sys.executable) should be adjusted to use __file__
> or sys._MEIPASS and any code locating the original executable using
> sys._MEIPASS should use sys.executable directly.
> * Any custom post processing steps (either in the .spec file or
> externally) which modify the bundle will likely need adjusting to
> accommodate the new directory.
This is actually great because it declutters the top level directory to
just `dcs_liberation.exe` and a directory named `_internal` that has all
the guts, but the CWD is no longer the directory that has `resources/`
in it, so we can't find any of our resources. There are a few options
for fixing that (cd into that directory probably being the easiest, or
we could stop relying on CWD relative paths), but for now just downgrade
to unbreak the build.
A lot of the dependency versions we have pinned don't have wheels for
Python 3.12. Update almost all of them so we can upgrade Python.
The few that weren't upgraded here are black and mypy, since those will
be a bit invasive, and Pillow, which has an API change I don't want to
deal with right now (I've got a commit on another machine that has
already done the migration, so I'll do it later).
Now that the F-15E Suite 4+ has JDAMs and the bug preventing AI from
using LGBs has been fixed, I have removed the AI-only F-15Es from my
campaigns. Also minor tweaks to a couple of squadron types/sizes based
on play-testing results.
There are a few different code paths for deleting packages depending on
the state of the package, and two of them were deleting items from a
list they were iterating over without first making a copy, causing each
iteration of the loop to skip over a flight, making it still used since
the flight was never deleted, but unreachable since the package that
owned it was deleted.
This only happened when the package was canceled in its draft state
(the user clicked the X without ever saving the package), or if the user
canceled a package mid fast forward (the controls for which aren't even
visible to users) while only a portion of the package was active. In
both cases, only even numbered flights were lost.
There's a better fix lurking in here somewhere but the interaction with
the Qt model complicates it. Fortunately that mess would be cleaned up
automatically by moving this dialog into React, which we'll do some day.
Fixes https://github.com/dcs-liberation/dcs_liberation/issues/3257.
Fixes https://github.com/dcs-liberation/dcs_liberation/issues/3258.
It appears the AI is still incapable of using LGBs (and laser JDAMs),
even though Razbam had said the issues was fixed. I have switched
loadouts to JDAMs because the AI will use those.
This fixes a map object strike target (yes, just one. Fortunately!) that
was broken by the latest DCS open beta update that removed the buildings
the strike target was using.
GBUs have been added to the F-15E Suite 4+ loadouts
Also switched CAP loadouts to 2 external tanks instead of 3 to improve
aircraft performance, as 2 tanks is plenty for players and the AI has
infinite fuel now.
This adds LARC-V to Liberation (required by USA 1970)
Also adds Speedboat to Liberation (required by NVA 1970)
Both units are available via pydcs but have not been added to Liberation
thus far as no factions used them (until now).
This is enabled by default because I can't think of a time where it's
ever been more fun to watch the AI run out of fuel after cycling between
afterburner and speedbrake for twenty minutes.
This is only lightly tested (I verified that the task shows up
appropriately in the ME when set, not when unset, and never for
players), since the interesting part of the implementation is up to ED.
Fixes https://github.com/dcs-liberation/dcs_liberation/issues/3201.