If the package does not have a tanker, the refueling task will cause AI
flights to go to an arbitrary tanker, which may cause them to fly
through enemy territory or even go farther than their arrival airbase.
It's also not remotely possible for every AI flight in the game to
refuel in most missions. There's typically one tanker and dozens of
aircraft that would previously attempt to refuel.
Fixes https://github.com/dcs-liberation/dcs_liberation/issues/2716.
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.
```
>>> class Foo:
... bar = 0
... @classmethod
... def set_bar(cls, v):
... cls.bar = v
...
>>> class Bar(Foo):
... ...
...
>>> Bar.set_bar(1)
>>> Bar.bar
1
>>> Foo.bar
0
>>> class Foo:
... bar = {}
... @classmethod
... def add(cls, k, v):
... cls.bar[k] = v
...
>>> class Bar(Foo):
... pass
...
>>> Bar.add(0, 1)
>>> Bar.bar
{0: 1}
>>> Foo.bar
{0: 1}
```
The collections are copied by reference into the descendants, whereas
_loaded is copied by value, so that one can stay. Before this patch,
every subtype was loading because _loaded was set per subclass, but they
were all registering with a common collection defined by UnitType rather
than their own class.
mypy update is needed for typing.Self support. It caught an existing bug
(missing @property on override), and fixed a bug so we can drop an
ignore.
Upgrading mypy requires upgrading pydantic to get the newest pydantic
mypy plugin, and since that's what's driving fastapi it's probably smart
to upgrade those together.
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.
Trying to fix the singleton-ness in the plugin manager because it
prevents injecting settings until the game is fully committed (new game
wizard completed). Added the docs describing what I think I've been able
to discover.
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.
After this change, players will always have the final say in what
missions a squadron can be assigned to. Squadrons are not able to
influence the default auto-assignable missions either because that
property is always overridden by the campaign's air wing configuration
(the primary and secondary task properties). The `mission-types` field
of the squadron definition has been removed since it is no longer
capable of influencing anything. I haven't bothered cleaning up the now
useless data in all the existing squadrons though.
Fixes https://github.com/dcs-liberation/dcs_liberation/issues/2785.
A lot of campaigns want to define custom factions. This allows them to
do so without us having to fill the built-in factions list with a bunch
of campaign-specific factions. It also makes custom campaigns more
portable as they don't need to also distribute the custom faction files.
Comments! No more failures because you accidentally used a trailing
comma!
JSON still supported since it's basically free, but we should probably
remove that in 8 just so the docs can be less confusing for users who
will be confused if only one format is documented (and we definitely
won't maintain duplicate docs).
Eager loading meant that users would need to restart Liberation to pick
up changes to faction files. That's annoying for modders, slows down
start up, and uselessly sits in RAM when it's not needed after game
creation.
Also removes the __getitem__ and __iter__ methods in favor of named
methods, since the dunder methods are more or less impenetrable for IDEs
and grep.
These are only used during mission generation. Remove them from the save
state to reduce compatibility requirements. We also have at least one
report of this data being corrupted... somehow. I don't know how that
could have happened, but if there's no data to corrupt in the first
place that's not a problem. If the corruption _does_ recur, it'll be
much easier to repro if it corrupts during mission generation rather
than during turn initialization.
Fixes https://github.com/dcs-liberation/dcs_liberation/issues/2729.
We've actually been pretty good at getting this right in most of the
code base, but we've missed it in a few places. Python defaults to the
encoding of the current locale unless otherwise specified, and for a US
English Windows install that's cp1252, not UTF-8. I'm not brave enough
to change the locale at startup because I don't know how that might
affect CJK encoding users (or for that matter, non-Latin derived
alphabet UTF-8 variants).
Fixes https://github.com/dcs-liberation/dcs_liberation/issues/2786.
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.
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).
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
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).
