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