- Fix tgogenerator
- Fix UI for ForceGroup and Layouts
- Fix ammo depot handling
- Split bigger files in smaller meaningful files (TGO, layouts, forces)
- Renamed Template to Layout
- Renamed GroundGroup to TheaterGroup and GroundUnit to TheaterUnit
- Reorganize Layouts and UnitGroups to a ArmedForces class and ForceGroup similar to the AirWing and Squadron
- Reworded the UnitClass, GroupRole, GroupTask (adopted to PEP8) and reworked the connection from Role and Task
- added comments
- added missing unit classes
- added temp workaround for missing classes
- add repariable property to TheaterUnit
- Review and Cleanup
Added serialization for loaded templates
Loading the templates from the .miz files takes a lot of computation time and in the future there will be more templates added to the system. Therefore a local pickle serialization for the loaded templates was re-added:
- The pickle will be created the first time the TemplateLoader will be accessed
- Pickle is stored in Liberation SaveDir
- Added UI option to (re-)import templates
Improvement for factions and templates which will allow decoupling of the templates from the actual units
- Implement UnitGroup class which matches unit_types and possible templates as the needed abstraction layer for decoupling.
- Refactor UnitType, Add ShipUnitType and all ships we currently use
- Remove serialized template.json and migrated to multiple yaml templates (one for each template) and multiple .miz
- Reorganized a lot of templates and started with generalization of many types (AAA, Flak, SHORAD, Navy)
- Fixed a lot of bugs from the previous reworks (group name generation, strike targets...)
- Reorganized the faction file completly. removed redundant lists, added presets for complex groups / families of units like sams
- Reworked the building template handling. Some templates are unused like "village"
- Reworked how groups from templates can be merged again for the dcs group creation (e.g. the skynet plugin requires them to be in the same group)
- Allow to define alternative tasks
- completly refactored the way TGO handles groups and replaced the usage of the pydcs ground groups (vehicle, ship, static) with an own Group and Unit class.
- this allows us to only take care of dcs group generation during miz generation, where it should have always been.
- We can now have any type of unit (even statics) in the same logic ground group we handle in liberation. this is independent from the dcs group handling. the dcs group will only be genarted when takeoff is pressed.
- Refactored the unitmap and the scenery object handling to adopt to changes that now TGOs can hold all Units we want.
- Cleaned up many many many lines of uneeded hacks to build stuff around dcs groups.
- Removed IDs for TGOs as the names we generate are unique and for liberation to work we need no ids. Unique IDs for dcs will be generated for the units and groups only.
* Initial refueling definitions.
* Adding refuel definitions.
* Initial functionality changes
* Regenerate package when adding refueling flight.
* Recursively change package waypoint.
* Fix mypy errors.
* Regenerate flight plans when tanker is added to package.
* Give tanker better starting position on package recovery.
* Add TOT calculation for refueling waypoint.
* Timing changes to Strike split point and Refueling start time.
* Add correct waypoint builder for refuel in tarcap and sweep. Remove restrict afterburner on refuel point.
* Always generate a refuel point for a package.
* Less arbitrary altitude in Refuel track start time calculation.
* Refueling waypoint no longer optional.
* Fix mypy gen error.
* Better discrimination of which tanker flight plan to make.
* Remove refuel tot calculations.
* Remove package regeneration on tanker flight addition.
Implement custom behavior for some of the flight plans but also add a
base implementation that just returns the empty set.
Use ABC for FlightPlan so that we can fail-fast on these kinds of
problems.
Fixes https://github.com/dcs-liberation/dcs_liberation/issues/1711
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
Forces carrier planes with original start_time of zero seconds to have a start time of 1 second. This will prevent them from spawning on the 'sixpack' and functions as a workaround for a DCS problem (deadlock / traffic jam).
Fixes#1309.
* Addresses #478, adding a heading class to represent headings and angles
Removed some unused code
* Fixing bad merge
* Formatting
* Fixing type issues and other merge resolution misses
It's rare with the current 5NM buffer around the origin, but if we use
the hold distance as the buffer like we maybe should it's possible for
the preferred join locations to fall entirely within the home zone. In
that case, fall back to a location within the max-turn-zone that's
outside the home zone and is nearest the IP.
Test cases:
1. Target is not threatened.
The IP should be placed on a direct heading from the origin to the
target at the max ingress distance, or very near the origin airfield
if the airfield is closer to the target than the IP distance.
2. Unthreatened home zone, max IP between origin and target, safe
locations available for IP.
The IP should be placed in LAR at the closest point to home.
3. Unthreatened home zone, origin within LAR, safe locations available
for IP.
The IP should be placed near the origin airfield to prevent
backtracking more than needed.
4. Unthreatened home zone, origin entirely nearer the target than LAR,
safe locations available for IP.
The IP should be placed in LAR as close as possible to the origin.
5. Threatened home zone, safe locations available for IP.
The IP should be placed in LAR as close as possible to the origin.
6. No safe IP.
The IP should be placed in LAR at the point nearest the threat
boundary.
This places the split point based on the best path from the IP to home,
rather than the best path from home to the target. The outcome is that
the planner might choose an alternate route out of a threatened area
based on the safest escape from the IP, which is where the aircraft
should be when it releases its weapons, rather than at the target.
That's of course not always perfect since the IP distance is not based
on the carried weapon, but it's a better choice when it matters more
(when carrying standoff weapons attacking a more dangerous target).
Try all the nav points between the origin and the target rather than
just the first non-threatened point. This prevents us from using the
fallback behavior for any target that's sufficiently far from the
package airfield.
This is as much as we can do until pydcs actually adds the py.typed
file. Once that's added there are a few ugly monkey patching corners
that will just need `# type: ignore` for now, but we can't pre-add those
since we have mypy warning us about superfluous ignore comments.
The loadout case actually could (and previously did) hide bugs from the
type checker, since mypy was smart enough to see that we were removing
None from the input it assumed that the member was non-optional, but
later modifications could cause null values, and since those came from
the UI mypy couldn't reason about this. This meant that mypy assumed the
type could not be optional and wouldn't check that case.
This Pull Request lets users plan Tanker flights.
Features:
- Introduction of `Refueling` flight type.
- Tankers can be purchased at airbases and carriers.
- Tankers get planned by AI.
- Tankers are planned from airbases and at aircraft carriers.
- Tankers aim to be at high, fast, and 70 miles from the nearest threat.
(A10s won't be able to tank)
- Tankers racetrack orbit for one hour.
- Optional Tickbox to enable legacy tankers.
- S-3B Tanker added to factions.
- KC-130 MPRS added to factions.
- Kneeboard shows planned tankers, their tacans, and radios.
Limitations:
- AI doesn't know whether to plan probe and drogue or boom refueling
tankers.
- User can't choose tanker speed. Heavily loaded aircraft may have
trouble.
- User can't choose tanker altitude. A-10s will not make it to high
altitude.
Problems:
- Tanker callsigns do not increment, see attached image. (Investigated:
Need to use `FlyingType.callsign_dict`, instead of just
`FlyingType.callsign`. This seems like it might be significant work
to do.).
- Having a flight of two or more tankers only spawns one tanker.
- Let me know if you have a solution, or feel free to commit one.
https://user-images.githubusercontent.com/74509817/120909602-d7bc3680-c633-11eb-80d7-eccd4e095770.png
The usual symptom here was the game breaking when a carrier is
destroyed. The carrier would no longer be operational but missions would
be assigned there that could not generate flight plans.
We shouldn't consider the non-escorted parts of the flight path when
checking for threats to determine if escorts should be used or not,
since escorts can't help in those areas anyway. This was causing escorts
to be overly requested since the bullseye is now a part of the
"flight plan", but could have also triggered for divert waypoints, or
for aircraft taking off in a retreat from a threatened location.
A was intended to be the blue point and B was intended to be the red
point. Make this a part of the name so that's clear, and clean up
related code to keep that reliable.
