F/A-18E and F/A-18F are added to their factions, Growler is currently in
its respective factions but was released in 2009, this will be changed
if needed.
This PR:
- Introduces a new member of UnitType, hit_points, which is an abstract
representation of the durability of a unit, and loads it in from the
YAML files in the various subclasses (Ship, Ground etc).
- Adds scripts for populating/updating the unit YAML files with hit
point data from DCS. This script also gets the data for static objects,
but I'll leave the plugging in of static object data into Liberation for
another PR.
- Updates the unit YAML files by running the above scripts.
I did toy with the idea of adding this data to the unit definitions in
pydcs via an export from DCS, but it would be a more involved change,
since the current pydcs export script runs in the Hooks Lua environment
in DCS and AFAICT the hit points (via Unit.getLife()) is run in the
mission scripting environment.
This PR:
- Refactors the doctrine class to have a bit more structure, in
anticipation of adding more elements to Doctrine.
- Moves previously hard coded helo-specific altitudes into the Doctrine
class, aligning a bunch of altitudes ~200ft in the process.
- Refactors ingress_altitude to combat_altitude to clarify that the
altitude is applied to multiple waypoint types, not just the ingress
altitude.
Campaign update of Falcon Went over the Mountain (Syria map) to v11.0
1. Added squadron sizes
2. Rebalanced scenario
3. Added (non zero) heading to all SAM and EWR sites
This PR 1) introduces a cruise_speed parameter to the AircraftType class
and uses it as an override for default TOT/Ground Speed calculations and
2) sets this for the AH64.
The reason for this change is that air starts with the Apache at a speed
>130kt seems to completely break the FCR, even if you subsequently slow
down. In the development branch, Liberation sets the Apache to travel at
168kt, so any player air starting won't be able to use their FCR and it
wouldn't be readily apparent as to why.
In the longer run this parameter may also be useful for other aircraft
e.g. to override the cruise speed to the most efficient etc.
We want the selected flight plan to show on top of all the other flight
plans, and because we can't properly z-order with the other elements of
the map (see the code comment), this is probably the best we can do.
This means that the selected flight will be drawn on top of the front
line again, and will in some cases intercept mouse clicks meant for the
front line, but it's much less of a problem than when all the paths were
drawn on top.
Fixes https://github.com/dcs-liberation/dcs_liberation/issues/3305.
This PR makes sure that the Payload tab of the Edit Flight window shows
the correct property values (with `default_overrides` applied in the
aircraft YAML). It looks like the issue only affects an obscure
parameter on F14s (INS reference alignment stored) so may not have been
noticed until now.
This fixes the unusual case where the `interactive: false` property had
no effect, which would make it impossible to plan missions against UI
elements that were overflown by many flights (such as the front line).
As an added bonus, it looks a bit nicer.
This impacts the test in an odd way, but the cure for that is probably
rewriting the test to not use a mock now that we've figured out how to
do that.
Fixes https://github.com/dcs-liberation/dcs_liberation/issues/3295.
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.
