We were calculating the TOT based on travel time to the *flight's*
target, but the ingress point based on the travel time to the target
area. If the difference in travel time between the center of the
target area and the first target were different then we'd calculate
the start time incorrectly even for single flight packages.
Seems to fix https://github.com/Khopa/dcs_liberation/issues/295
The increased precision that we had everywhere except the UI and the
interface with DCS was causing issues with ASAP creating barely
negative start times. The main cause of this was that we'd compute the
earliest possible TOT, it would result in, for example, 23:10.002.
When we then set the QTimeEdit for the TOT, we have to round because
it does not support (nor do we really want to display) sub-second
values, which then caused the previously 0 start time to be -0.002.
Instead, since the sub-second values aren't really interesting anyway,
we now just round TOTs up and start times down. This should prevent
negative start times from occurring (except when they've been manually
planned as such), and also prevents start times of 00:00:01.
Also rounds the package waypoint times to avoid the same issues, but
it's not really important which direction we round these.
Fixes https://github.com/Khopa/dcs_liberation/issues/295
first pass briefing refactor
briefing fixes
briefing fixes
Stop briefing generate being called twice
Stop frontline advantage string being appended
when there are no units.
jinja template
always return enum instance in Strategy Selector
For some reason on DEFENSE, enum is appended to control point stance,
but on all other the enum.value is added instead.
I don't see any case where the value is used, but there are many
cases that the enum instance is evaluated against.
type issue
junja's not a thing
swap mapping with dict
jinja template
always return enum instance in Strategy Selector
For some reason on DEFENSE, enum is appended to control point stance,
but on all other the enum.value is added instead.
I don't see any case where the value is used, but there are many
cases that the enum instance is evaluated against.
type issue
Update build.yml
junja's not a thing
swap mapping with dict
Restore build job
Previously we were trying to make every potential flight plan look
just like a strike mission's flight plan. This led to a lot of special
case behavior in several places that was causing us to misplan TOTs.
I've reorganized this such that there's now an explicit `FlightPlan`
class, and any specialized behavior is handled by the subclasses.
I've also taken the opportunity to alter the behavior of CAS and
front-line CAP missions. These no longer involve the usual formation
waypoints. Instead the CAP will aim to be on station at the time that
the CAS mission reaches its ingress point, and leave at its egress
time. Both flights fly directly to the point with a start time
configured for a rendezvous.
It might be worth adding hold points back to every flight plan just to
ensure that non-formation flights don't end up with a very low speed
enroute to the target if they perform ground ops quicker than
expected.
When we don't coalesce target points on the kneeboard we call
add_waypoint_row multiple times, so calls after the first were using
the travel time from one strike target to the next. Since they were so
close that rounded down to zero and caused a divide by zero error.
Update the last waypoint in add_waypoint instead.
We were only getting BARCAP results right in BARCAP packages. This
fixes calculations of TOTs and start times for BARCAPs in strike
packages.
The probably needs some refactoring. BARCAP is just the symptomatic
example at the moment, but the real problem is that different mission
profiles exist and we currently only handle one. Making profiles
explicit in mission planning will clean this up, will be needed for
other future mission types, and makes it easier for us to alter
behavior for waypoint and timing decisions based on the aircraft or
mission type.
