This allows for customizing OPFOR liveries, checking whether pilots are assigned, number of pilots available, and more stuff to get information & debug in an easier way...
* Don't generate runway data for heliports.
Fixes https://github.com/dcs-liberation/dcs_liberation/issues/2710.
* Remove dead code.
* Implemented support for Chiller Juice Studios F/A-18E/F/G Super Hornet mod
The Chiller Juice Studios Super Hornet mod works like this: it changes the stock F/A-18C Hornet into F/A-18E/F/G Super Hornet / Growler. The exact variant is selected with argument 999 in the livery description.lua, which is why I chose to add the three variants in the FA-18C_hornet.yaml. This way, we can use the squadrons mechanism in Liberation to select the appropriate variant by specifying the correct livery for the squadron.
Current properties injected are wingspan / width and the custom ordnance added by the mod.
Added F/A-18E/F/G banner by Schmokedpancake and F/A-18F icon.
Resolves https://github.com/dcs-liberation/dcs_liberation/issues/2681
* Added a separate loadout file for the Chiller Juice Studios F/A-18E/F/G Super Hornet mod. Currently only replaces the FPU-8A fuel tanks with FPU-12s.
* Added the possibility to use the AI variant of the F/A-18C in campaigns, allowing different loadouts and in the future, the Super Hornet mod alongside legacy Hornets in the same campaign.
* Updated Chiller Juice Studios F/A-18E/F/G Super Hornet mod support to version 2.0. Removed the 1.x version property and pylon injection since they are no longer necessary, since 2.0 adds the Super Hornet variants as separate aircraft. For the same reason, removed the AI-only F/A-18C from the faction files (still retained the aircraft yaml, loadout files and icon/banner in case someone still wants to use it).
Includes F/A-18E/F/G banner by Schmokedpancake, loadouts by @sgtfuzzle17 and F/A-18E/F icons.
* Added Super Hornet, Growler squadrons and Growler banner by @sgtfuzzle17
The squadrons include the model of the airframe in their name, so they can be referenced directly from campaign yaml files without the risk of conflicting with the same squadron of a different era, flying a different airframe.
Also updated the E and G model icons.
Resolves#77
* Fixed a bug with the EA-18G banner not being visible in Retribution. Also added the Super Hornet variants to factions bluefor_modern and Israel-USN_2005_Allied_Sword.
* Corrected the descriptions for tandem-seat Super Hornet variants.
* Updated Chiller Juice Studios F/A-18E/F/G Super Hornet mod support to version 2.1
* Anti-ship loadouts are now named properly.
* Update changelog.md
* Update QNewGameWizard.py
---------
Co-authored-by: Dan Albert <dan@gingerhq.net>
Co-authored-by: Raffson <Raffson@users.noreply.github.com>
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.
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 appears to be incompatible with pyinstaller. I get the following
when trying to run the executable generated with pyside6:
```
Traceback (most recent call last):
File "qt_ui\main.py", line 29, in <module>
File "PyInstaller\loader\pyimod03_importers.py", line 476, in exec_module
File "qt_ui\windows\QLiberationWindow.py", line 28, in <module>
File "PyInstaller\loader\pyimod03_importers.py", line 476, in exec_module
File "qt_ui\widgets\map\QLiberationMap.py", line 11, in <module>
ImportError: could not import module 'PySide6.QtPrintSupport'
```
This is an attempt to remove a lot of our supposedly unnecessary error
handling. Every aircraft should have a price, a description, a name,
etc; and none of those should require carrying around the faction's
country as context.
This moves all the data for aircraft into yaml files (only one converted
here as an example). Most of the "extended unit info" isn't actually
being read yet.
To replace the renaming of units based on the county, we instead
generate multiple types of each unit when necessary. The CF-18 is just
as much a first-class type as the F/A-18 is.
This doesn't work in its current state because it does break all the
existing names for aircraft that are used in the faction and squadron
files, and we no longer let those errors go as a warning. It will be an
annoying one time switch, but it allows us to define the names that get
used in these files instead of being sensitive to changes as they happen
in pydcs, and allows faction designers to specifically choose, for
example, the Su-22 instead of the Su-17.
One thing not handled by this is aircraft task capability. This is
because the lists in ai_flight_planner_db.py are a priority list, and to
move it out to a yaml file we'd need to assign a weight to it that would
be used to stack rank each aircraft. That's doable, but it makes it much
more difficult to see the ordering of aircraft at a glance, and much
more annoying to move aircraft around in the priority list. I don't
think this is worth doing, and the priority lists will remain in their
own separate lists.
This includes the converted I used to convert all the old unit info and
factions to the new format. This doesn't need to live long, but we may
want to reuse it in the future so we want it in the version history.
This gives a clean break between the transfer request and the type of
transport allocated to make way for transports that need to switch
types (to support driving to a port, then getting on a ship, to a train,
then back on the road, etc).
https://github.com/Khopa/dcs_liberation/issues/823
UI isn't finished. Bulk transfers where the player doesn't care what
aircraft get used work (though they're chosen with no thought at all),
but being able to plan your own airlift flight isn't here yet.
Cargo planes are not implemented yet.
No way to view the cargo of a flight (will come with the cargo flight
planning UI).
The airlift flight/package creation should probably be moved out of the
UI and into the game code.
AI doesn't use these yet.
https://github.com/Khopa/dcs_liberation/issues/825
This adds the models and UIs for creating ground unit transfer orders.
Most of the feature is still missing:
* The AI doesn't do them.
* Transfers can move across the whole map in one turn.
* Transfers between disconnected bases are allowed.
* Transfers are not modeled in the simulation, so they can't be
interdicted.
https://github.com/Khopa/dcs_liberation/issues/824
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.
