Create a WaypointAction class that defines the actions taken at a
waypoint. These will often map one-to-one with DCS waypoint actions but
can also be higher level and generate multiple actions. Once everything
has migrated all waypoint-type-specific behaviors of
PydcsWaypointBuilder will be gone, and it'll be easier to keep the sim
behaviors in sync with the mission generator behaviors.
For now only hold has been migrated. This is actually probably the most
complicated action we have (starting with this may have been a mistake,
but it did find all the rough edges quickly) since it affects waypoint
timings and flight position during simulation. That part isn't handled
as neatly as I'd like because the FlightState still has to special case
LOITER points to avoid simulating the wrong waypoint position. At some
point we should probably start tracking real positions in FlightState,
and when we do that will be solved.
There's an ugly special case in flight simulation to handle hold points
because we don't differentiate between the total time between two
waypoints (which can include delays from actions like holding) and
travel time. Split those up and remove the special case.
When a new flight is added to a package, if the TOT is early enough the
new flight might have a startup time in the past. Clamp the TOT when
adding new flights to the package to avoid this.
https://github.com/dcs-liberation/dcs_liberation/issues/1680
This makes the start time in WaitingForStart dynamic, which is more
expensive but probably still cheap enough.
It also checks that the new TOT will not result in a start time in the
past when the player changes the TOT.
https://github.com/dcs-liberation/dcs_liberation/issues/1680
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.
There are some TODOs here but th behavior is flagged off by default. The
biggest TODO here is that the time spent frozen is not simulated, so
flights that are engaged by SAMs will unfreeze, move slightly, then re-
freeze.
https://github.com/dcs-liberation/dcs_liberation/issues/1680
This is briefly moving us over to my fork of pydcs while we wait for
https://github.com/pydcs/dcs/pull/206 to be merged. The adaptation is
invasive enough that I don't want it lingering for long.
Rather than polling at 60Hz (which may be faster than the tick rate,
wasting cycles; and also makes synchronization annoying), collect events
during the tick and emit them after (rate limited, pooling events until
it is time for another event to send).
This can be improved by paying attention to the aircraft update list,
which would allow us to avoid updating aircraft that don't have a status
change. To do that we need to be able to quickly lookup a FlightJs
matching a Flight through, and Flight isn't hashable.
We should also be removing dead events and de-duplicating. Currently
each flight has an update for every tick, but only the latest one
matters. Combat update events also don't matter if the same combat is
new in the update.
https://github.com/dcs-liberation/dcs_liberation/issues/1680
This doesn't do anything yet, but sets up the data model handling for
frozen combat. The next step is to show combat in the map view, since
that will be helpful when debugging the step after that one: resolving
frozen combat.
This would benefit from caching the Shapely data for SAM threat zones.
Right now it's generating them once per tick and the stuttering is
visible at max speed.
https://github.com/dcs-liberation/dcs_liberation/issues/1680
This is the first step in a larger project to add play/pause buttons to
the Liberation UI so the mission can be generated at any point.
docs/design/turnless.md describes the plan.
This adds an option to fast forward the turn to first contact before
generating the mission. None of that is reflected in the UI (for now),
but the miz will be generated with many flights in the air.
For now "first contact" means as soon as any flight reaches its IP. I'll
follow up to add threat checking so that air-to-air combat also triggers
this, as will entering a SAM's threat zone.
This also includes an option to halt fast-forward whenever a player
flight reaches a certain mission-prep phase. This can be used to avoid
fast forwarding past the player's startup time, taxi time, or takeoff
time. By default this option is disabled so player aircraft may start in
the air (possibly even at their IP if they're the first mission to reach
IP).
Fuel states do not currently account for distance traveled during fast
forward. That will come later.
https://github.com/dcs-liberation/dcs_liberation/issues/1681
