The weapon laser codes can be set more easily from the weapon laser code
combo box. Setting the properties explicitly here will just cause
conflicts and annoying UI bugs. Hide those properties from the UI.
This makes it possible to have the right laser code set for hot start
aircraft that (typically) do not allow changing laser codes when the
engine is on.
The release behavior isn't used yet, but I'm working on pre-allocating
laser codes for front lines and flights to make it easier for players to
pick the laser codes for their weapons.
* Store a deque rather than an iterator so it can be pickled
* Remove mangling from staticmethod (and rename now that it's no longer
a generator)
* Rename "get" to "alloc" to make the mutation clear
* Move to its own package (the changes I'm working on make this no
longer mission generator specific)
* Remove useless exception class. It's never caught so the unique type
isn't needed
Use the new data from pydcs to improve the properties UI:
* Use human readable names
* Use appropriate control types
* Limit min and max values as appropriate for each property
* Show labels
Fixes https://github.com/dcs-liberation/dcs_liberation/issues/3090.
These are read unconditionally, but were only initialized when the
coalition had nodes. When a coalition had no nodes, this caused a nil
access. It's unclear if that had any symptoms, but I expect at the very
least it would break the remainder of the script (so a non-functioning
blue IADS if the red IADS had no nodes).
There's a very small chance this is the culprit behind
https://github.com/dcs-liberation/dcs_liberation/issues/3073.
The flight plan used to not include a waypoint for departure, so a few
places would create one for the sake of the UI, or were built to assume
there was a missing waypoint that was okay to ignore. At some point we
added them to the flight plan, but never updated the UI, so the waypoint
list in the flight dialog started counting from 1 instead of 0, and the
openapi endpoint wrongly reported two departure waypoints to the front-
end.
Fixes https://github.com/dcs-liberation/dcs_liberation/issues/3037.
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.
