This PR
- Addresses #1511 by setting the tanker on-station time to the desired
mission duration + 30 minutes
- Elaborate on what the desired mission duration setting does in the
Settings UI.
This PR addresses #2778 by:
- Updating the logic for how redeployment of front line units works to
handle "out of order" captures e.g. for control points A->B->C, where A
starts friendly and B, C starts as enemy-controlled, the player captures
C first, typically using air assault.
- Updating the cheat logic so that capturing CPs using cheats behaves
the same way as capturing CPs normally.
… DCS reports multiple hits
This PR fixes a bug introduced when tracking OCA/Aircraft kills that
results in double counting when DCS reports multiple hits, typically
when guns are used.
This PR addresses #3337 by:
- Updating the UI to identify that a destroyed carrier/LHA as "Sunk"
- Fall back on targeting other groups in the NavalControlPoint (e.g.
escorts if present) if the carrier/LHA is sunk.
This PR partially addresses #3313 by:
- Tracking DCS hit events and storing the unit hit point updates in
state.json
- Adding logic to kill aircraft when the hit points is reduced to 1, as
opposed to the DCS logic of hit points to 0. This behavior allows
Liberation to track deaths to parked aircraft, which are uncontrolled
and seem to have different damage logic in DCS.
- Tracking damage to TheaterGroundObjects across turns and killing the
unit when the unit's hitpoints reduces to 1 or lower.
Intention is to build on this PR by also tracking front line objects and
statics (buildings). However, larger refactoring is required and so
splitting those into a separate PR.
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.
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.
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 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
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.
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).
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.
We had two different paths for converting pydcs loadouts because pydcs's
APIs for some reason return the loadouts in different shapes which made
it difficult to share the code for converting them. Rather than fix the
bug in both places, extract the common code and adapt the result of one
API to match the other.
Fixes https://github.com/dcs-liberation/dcs_liberation/issues/3171.
There's more detail in the comment, but this fixes an issue where some
Mosquito loadouts could not be loaded.
Might fix https://github.com/dcs-liberation/dcs_liberation/issues/3171.
There aren't enough instructions in the bug for me to be sure, but it
sounds like a similar problem, although I came across it with bombs
rather than rockets.
The package page shows each flight member in the whole package. The data
shown for now is the callsign, task, radio frequency, and laser code.
The STN for each flight will be added once that's done.
This does generate one package page per flight. That means that packages
where multiple flights have players and use the same aircraft type will
have some duplicated pages, but the alternative is that some players
would need to skip past all their flight members' pages to find their
package page instead of having it grouped with their own.
This is just the refactor to make way for the real change: adding a
package page to the kneeboard so players can get package-level
information like other radio, laser, and STNs.
The old mode where squadrons started empty and had no size limit is
going away.
I bumped the campaign versions for the ones that claimed support and
tested a handful. All of Fuzzle's campaigns actually had the wrong
version in the yaml. They claim support for this but none that I tested
actually fit within the limits (despite having sizes defined). Either it
was supposed to be 10.7, or maybe the airports lost some parking.
1000km isn't large enough in the case where there's an off-map spawn
that's a long way from the target, but still in range for aircraft like
the B-1. Double it, which for now is enough to fix the one pathological
case we know.
Fixes https://github.com/dcs-liberation/dcs_liberation/issues/3156.
Another step in reducing the rigidity of FlightPlan and making it
testable.
There is one intentional behavior change here: escort flights no longer
request escorts. That actually has a very minimal effect because these
properties are only used for two things: determining if a package needs
escorts or not, and determining when the TARCAP should show up and
leave. Since escorts won't have been in the package when the first part
happens anyway, that has no effect. The only change is that TARCAP won't
show up earlier or stay later just because of a TOT offset for an escort
flight.
This doesn't need to be a part of FlightPlan, and it's easier to test if
it isn't. Move it out and add the tests.
It's pretty misleading to allow this in the core of the flight plan code
anything. This is an extremely unreliable estimate for most aircraft so
it should be more clearly just for briefing purposes.
Create a WaypointAction class that defines the actions taken at a
waypoint. These will often map one-to-one with DCS waypoint actions but
can also be higher level and generate multiple actions. Once everything
has migrated all waypoint-type-specific behaviors of
PydcsWaypointBuilder will be gone, and it'll be easier to keep the sim
behaviors in sync with the mission generator behaviors.
For now only hold has been migrated. This is actually probably the most
complicated action we have (starting with this may have been a mistake,
but it did find all the rough edges quickly) since it affects waypoint
timings and flight position during simulation. That part isn't handled
as neatly as I'd like because the FlightState still has to special case
LOITER points to avoid simulating the wrong waypoint position. At some
point we should probably start tracking real positions in FlightState,
and when we do that will be solved.
There's an ugly special case in flight simulation to handle hold points
because we don't differentiate between the total time between two
waypoints (which can include delays from actions like holding) and
travel time. Split those up and remove the special case.
