* Change indentation of register_special_waypoints (put out of loop)
* Added Strike Targets as F-15E Mission Target points (Set/Mission 1)
* Set up check for ASM : only if non-human flight lead. Add targets to the kneeboard.
* Generate multiple sets (i-e M2.1) for situations where the number of points is more than 8.
Added check condition to kneeboard (otherwise, may result in multiple writes).
* Change name of register_special_waypoints to register_special_strike_points
Add register_special_ingress_points method for special IPs and add to the appropriate classes
* Add changelog entry for Tomcat's IP wpt
* Avoid depending on client slots for special wpts injection
---------
Co-authored-by: tmz42 <thomas.monnzie@gmail.com>
Co-authored-by: Raffson <Raffson@users.noreply.github.com>
* Unlimited fuel for AI flights. For player flights, included at startup, for AI flights with join/split, applied at join/split.
* Unlimited fuel for AI flights. For player flights, included at startup, for AI flights with join/split, applied at join/split.
* Corrected default value of ai_unlimited_fuel to False in configure_behavior
* ai_unlimited_fuel : set argument based on setting and simplify activation section
* AI Unlimited Fuel : enable at start, disable at racetrack start/join, enable at racetrack end/split
* Correct typing : bool to Optional[bool]
---------
Co-authored-by: tmz42 <thomas.monnzie@gmail.com>
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.
