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