This looks like it was just a typo. We want to join as late as possible
to allow flights coming from other airfields to take the best route to
the target that is safe, rather than joining as early as possible, which
isn't useful since pre-join and post-split are supposed to be safe areas
anyway.
The for_theater method is always called before for_airport is during
normal gameplay, but I'm writing a linter to show missing airfield data
that calls for_airport first.
This shouldn't be the case for anything shipped, but is typical when new
theaters are still being developed.
We could potentially add an `in_progress` flag to the theater definition
to make this only optionally tolerant, but since that code path would
rarely be exercised it's just likely to bitrot. This data isn't critical
to mission generation anyway, so this is fine. What we should do is add
some linters that document all the data that is missing though (and
ideally publish that to our docs).
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!
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.
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.
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.
