This PR fixes a regression introduced in
https://github.com/dcs-liberation/dcs_liberation/pull/2792 where
refactoring meant that scenery deaths were not tracked correctly.
This PR has been tested by striking a scenery target and confirming that
it appears in state.json and is updated in Liberation. I've also
confirmed that ground units are tracked.
It's not feasible to actually check the parking limits because we can't
identify parking limits for carriers until the theater is populated.
Doing so is expensive (and depends on other NGW inputs). Instead,
compare against the version of the campaign and guess.
A new (minor) campaign version has been introduced which makes this
required to improve the UI hint. Campaigns that are compatible with the
new rules should update their version to advertise support.
Fixes https://github.com/dcs-liberation/dcs_liberation/issues/2909.
This does show the theoretical parking use of full squadrons even when
the new rules are not enabled. Since limits can be enabled manually
later in the game, it's still useful information, even if it's a bit
misleading.
https://github.com/dcs-liberation/dcs_liberation/issues/2910
This PR adds utility functions that import/export landmap files to .miz
polygons. In addition to the unit test, this PR has been tested by
writing the Caucuses & Syria landmaps to a .miz file, loading the
generated .miz file back in and checking that the loaded landmap object
is identical to the original files.
This is optional because I really don't know if I trust it. I don't see
much wrong with it (aside from the warning about not using it with auto-
resolve, because it won't restore lost aircraft), but it's really not
something I'd built for since it's not going to be possible as the RTS
features grow.
Fixes https://github.com/dcs-liberation/dcs_liberation/issues/2735.
The previous method of using a uniform scalar of the MSL wind speed for
higher altitudes didn't offer enough control. In particular, the shape
needs to be quite different to skew low, mid, high.
This patch reworks that system so the parameters of each distribution
are configured per-altitude level. To keep some continuity between
altitudes (on a windy day, all levels should have higher wind speeds on
average), the wind speed of the lower altitude will be added to the
scale value of the higher altitude.
Since it wasn't practical to approximate the previous behavior with the
new system, this also handles the tuning of each. The low altitude
speeds remain mostly unchanged (typically around 5 knots expect for
thunderstorms), but the average speeds for other altitudes went up to
more closely match the previous intent but without the massive
overshoot. At 2000m wind speeds are typically in the 20-25 knot range
now, and 8000m 30-50 knots.
https://www.quora.com/What-is-the-average-wind-speed-at-different-altitudes
has some of the source data, and Quora is the most authoritative source
there is. It claims that cruise altitude winds can get "as high as 150
knots", but doesn't claim anything about the average. I had a
surprisingly difficult time finding good data for cruise altitude air
speeds for non-jet stream paths (though many of our maps are in jet
streams), so I just eyeballed it from
https://turbli.com/wind-during-flights/.
https://github.com/dcs-liberation/dcs_liberation/issues/2861
Fixes https://github.com/dcs-liberation/dcs_liberation/issues/2863.
Wind speeds should not be uniformly distributed. This switches to a
Weibull distribution which allegedly (see the bug) is good enough.
Experimentally that seems true as well, though I know nothing about how
wind works irl. This at least looks like it'll generate reasonable
variation in missions while keeping the 1st through 3rd quartile
behaviors from getting out of hand.
I'm very uncertain about the scaling factor aspect of this. Naively the
wind speeds at different altitudes ought to be somewhat correlated, but
I'm not sure how much, and whether this kind of scaling is at all the
right way to do it. As before, meh, close enough?
Fixes https://github.com/dcs-liberation/dcs_liberation/issues/2861.
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.
