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.
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.
