This doesn't need to be a part of FlightPlan, and it's easier to test if
it isn't. Move it out and add the tests.
It's pretty misleading to allow this in the core of the flight plan code
anything. This is an extremely unreliable estimate for most aircraft so
it should be more clearly just for briefing purposes.
Putting the ingress point directly on one end of the FLOT means that AI
flights won't start searching and engaging targets until they reach that
point. If the front line has advanced toward the flight's departure
airfield, it might overfly targets on its way to the IP.
Instead, place an IP for CAS the same way we place any other IP. The AI
will fly to that and start searching from there.
This also:
* Removes the midpoint waypoint, since it didn't serve any real purpose
* Names the FLOT boundary waypoints for what they actually are
Fixes https://github.com/dcs-liberation/dcs_liberation/issues/2231.
This property affects safe compat because the ID is what gets preserved
in the save, but it's unfortunately also used as the display name, which
means changing the display name breaks save compat. It also prevents us
from changing display names without breaking faction definitions.
This is the first step in fixing that. The next is adding a separate
display_name property that can be updated without breaking either of
those.
This isn't a great fix for the reason I mention in the comment, but it's
quick and actually is accurate since it looks like we don't actually
handle formation speeds correctly in most cases...
This is probably as "fixed" as this is going to get for now since most
of the flight planning code is in the process of being rewritten.
https://github.com/dcs-liberation/dcs_liberation/issues/3113
We don't need explicit configuration of initial points. The plane
automatically configures any steerpoint immediately before a target
point as an initial point.
Target offset points and aim points have not been implemented because I
can't find any information the describes their intent.
Fixes https://github.com/dcs-liberation/dcs_liberation/issues/3088.
This makes it possible to have the right laser code set for hot start
aircraft that (typically) do not allow changing laser codes when the
engine is on.
The release behavior isn't used yet, but I'm working on pre-allocating
laser codes for front lines and flights to make it easier for players to
pick the laser codes for their weapons.
* Store a deque rather than an iterator so it can be pickled
* Remove mangling from staticmethod (and rename now that it's no longer
a generator)
* Rename "get" to "alloc" to make the mutation clear
* Move to its own package (the changes I'm working on make this no
longer mission generator specific)
* Remove useless exception class. It's never caught so the unique type
isn't needed
These are read unconditionally, but were only initialized when the
coalition had nodes. When a coalition had no nodes, this caused a nil
access. It's unclear if that had any symptoms, but I expect at the very
least it would break the remainder of the script (so a non-functioning
blue IADS if the red IADS had no nodes).
There's a very small chance this is the culprit behind
https://github.com/dcs-liberation/dcs_liberation/issues/3073.
Added a new option in settings: Convert untasked OPFOR aircraft into client slots. This option will essentially convert the campaign into a sort of team vs. team engagement. There is still no way to plan the OPFOR missions, and there are no guarantees that there even will be any untasked aircraft available for players.
Split the Disable idle aircraft at airfields setting into Disable untasked BLUFOR aircraft at airfields and Disable untasked OPFOR aircraft at airfields.
- Plan number of aircraft more accurately
- Fine-tuning ingress waypoint tasks
- Add lineup waypoint for STRIKE flights, 10NM in front of ingress on the same heading as the target
Restores handling of TheaterGroundObject targets in antishipingress.py
This is needed when anti-ship missions are planned against other ship groups than NavalControlPoints (carrier groups or LHA strike groups).
* Added a separate Doctrine page in settings with the following new options:
- Minimum number of aircraft for autoplanner to plan OCA packages against
- Airbase threat range (nmi)
- TARCAP threat buffer distance (nmi)
- AEW&C threat buffer distance (nmi)
- Theater tanker threat buffer distance (nmi)
Implemented handling for the OPFOR autoplanner aggressiveness in objectivefinder.py vulnerable_control_points().
* * Added three new options in Settings:
- Autoplanner plans refueling flights for Strike packages
- Autoplanner plans refueling flights for OCA packages
- Autoplanner plans refueling flights for DEAD packages
Fixed a bug in faction.py where F-16Ds were not correctly removed from the faction when the F-16I/F-16D mod was not selected.
* Renamed Maximum frontline length -> Maximum frontline width.
