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.
Includes the rewritten livery scanning code. It might need some more
tweaks to be fast enough, but it at least now doesn't spam the log for
machines that don't have DCS (or Liberation) installed, and it's not
slow until something tries to use it, so until we add the UI we won't
have to pay for it during startup.
1. Removes Flak18 as these currently require Kdo.G.40. (part of the WW2
Asset Pack) to fire at player. ED-supplied single missions are having
Flak18s w/out WW2 Asset Pack firing at a point in the air.
2. Adds Opel Blitz to frontline for more variety, balance, and some
little bit of historical accuracy. My understanding is late war was more
truck strafing than HVARing Panzers.
3. Adds guard tower to AAA units to have a functioning AAA since Flak18s
don't work.
Ported the existing docs, but the real goal is getting the docs for
campaign version moved here, as well as the manual. RTD will have an
"edit on github" button that'll keep this accessible to players, but
it'll be much easier to keep docs up to date while developing features
if it's part of the code base.
No new data (I think), but includes a bunch of fixes for the lua parser
and rewrites some suspicious looking (but probably safe) code in the
livery scanner.
Also changes this dependency to non-editable by default. Pip chose this
automatically for me at some point, but the rules for whether or not a
py.typed file will actually be detected for an editable install are
complicated and sometimes this won't work, leading too a lot of mypy
errors. There's no need for this to be editable anyway.
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.
Leaflet (or maybe react-leaflet?) isn't very testable, so we can really
only test that mocks were called with the right props for the leaflet
components we expect, but that's still better than nothing.
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.
pydcs_extensions.__init__ wasn't actually doing anything because without
an __init__.py each of these "packages" was empty. This has been working
by accident because of ai_flight_planner_db.py.
