Fixed (zombie) carrier killed in state.json but always respawning in-game, issue #2405. GenericCarrierGenerator.generate() will now generate the ship group with an array that only contains alive ship units, just like GroundObjectGenerator.generate() has previously done.
Carrier groups will now also show up as destroyed/damaged on the map when the carrier is sunk.
Causes an exception otherwise, and at the same time a perfect example why a strongly typed language would be better in this case, because this would've been caught by a compiler!
Added weapons fallback data for the laser guided rockets, AIM-54's,
AGM-65 E/F, 4X Hellfire and TOW carried by US helis, rockets for them
to fall back to, all of the USSR IR missiles, R-3R, Mk-83 & Mk-84 and
adjusted the dates for the R-27ER &ET to 1990.
It replaces the FRONTLINE_LENGTH constant, which was used previously. The default setting for the frontline length has been set to match the FRONTLINE_LENGTH value (80 km), but I feel the default should be a bit shorter. Discussion on the topic would be welcome.
The next step in splitting up the layout and scheduling phases. This
facilitates splitting flights into two classes where one has a full
flight plan, but one used in the earlier phases of planning has only a
layout. Layout-only flights won't need TOTs, which will make them much
easier to work with once we've migrated TOTs from timedeltas to
datetimes.
Layout-only flights of course aren't actually usable, but it lets us
avoid dealing with the current sim time until we're certain the Flight
will even survive planning.
I'm not actually sure if we'll be able to split the two phases any more,
but this ends up being a nice cleanup anyway.
We can always estimate a startup time now. Remove the nullability from
the result, cleanup the callsites, and eliminate
TotEstimator.mission_start_time since it no longer does anything useful.
Flights without a meaningful TOT make the code around startup time (and
other scheduling behaviors) unnecessarily complicated because they have
to handle unpredictable flight plans. We can simplify this by requiring
that all flight plans have a waypoint associated with their TOT. For
custom flight plans, we can just fall back to the takeoff waypoint. For
RTB flight plans (which are only synthetic flight plans injected for
aborted flights), we can use the abort point.
This also means that all flight plans now have, at the very least, a
departure waypoint. Deleting this waypoint is invalid even for custom
flights, so that's no a problem.
This field is optional. Omitting the field (or using only a date instead
of a full timestamp) will use the old behavior of picking a random
daylight hour to start the campaign.
This doesn't include any UI in the new game wizard yet. This is only a
campaign yaml option.
https://github.com/dcs-liberation/dcs_liberation/issues/2400
Squashing 8 commits by DanAlbert:
- Track theater in ControlPoint.
Simplifies finding the owning theater of a control point. Not used yet.
- Clean some cruft out of FlightPlanBuilder.
- Clean up silly some exception handling.
- Move FlightPlan instantiation into the builder.
I'm working on moving the builder to be owned by the Flight, which will simplify callers that need to create (or recreate) flight plans for a flight.
- Simplify IBuilder constructor.
We have access to the theater via the flight's departure airbase now.
- Move FlightPlan creation into Flight.
For now this is just a callsite cleanup. Later, this will make it easier
to separate unscheduled and scheduled flights into different classes without complicating the layout/scheduling.
- Remove superfluous constructors.
- Remove unused Package field.
Previously, only the insurgent variant was used because the names were
identical. Also added descriptions to all ZU-23 variants and specified that the
insurgent variants are used with both Insurgent factions.
I tracked down the problem to `dataclass.replace` because it generates a new object.
Turns out the check for "claimed" squadrons is somehow linked to the original object.
Simply overwriting the original object fixes the problem.
3 items handled:
- Enable/Disable player checkbox if (not) flyable
- Disable player list in air wing config dialog for non-flyable aircraft
- Update changelog
The CSS used to grey out the checkbox and label for
advanced IADS should be refactored so it can be reused for
disabling player checkboxes in the flight edit/create dialogs.
The solution is applied to all checkboxes/labels, so that
there's a consistent way of showing users when a
checkbox/label is disabled.
Solution exists in using the 'get' method
of the "Weapons dictionary", and
subsequentially guarding against
None. Aside from that I created
a method to validate a payload,
which uses this None value to
determine validity.
The following things were handled:
- Typos in A-10C squadrons
- Updated livery names for F-14 squadrons
- Replacing custom liveries with pre-installed ones
The workflow UI works best if there's only a single main workflow in a
PR. We can keep things organized similarly by turning the test workflow
into a reusable workflow. Same code (mostly), better UI.
This is just the first step to prove the concept. Most of the work done
in our workflows can be split into separate jobs to parallelize the
workflow. This will also make the checks page more readable.
This change alone probably won't speed up CI much.
