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 makes long squadron names more likely to fit. I also added a
horizontal scroll bar for the cases when this still isn't enough space
and made the vertical scroll bar only appear when necessary. Typically
aircraft purchase menus are neither wide enough for long enough to need
either scroll bar.
Fixes https://github.com/dcs-liberation/dcs_liberation/issues/1592
This is needed fairly often, and we have a lot of Game being passed
around to ControlPoint methods specifically to support this. Just store
the owning Coalition directly in the ControlPoint to clean up. I haven't
cleaned up *every* API here, but did that aircraft allocations as an
example.
when a cp capture happens and the next cp has pending unit deliveries then they will be redeployed to the newly captured cp. The redeploy was drecreasing the num of pending unit deliveries for the old cp but was not removing them completly from the dict when all were removed
Much of the UI was using the old budget which wasn't removed from Game
like it should have been when Coaltion was introduced. The UI displayed
(and in some cases pulled from) the starting budget rather than the real
budget.
* Fixes#1310 by only refunding GUs if no faction CP has an attached factory. Previously it would refund all units at the CP, including aircraft.
Also changes the CP CAPTURE cheat to work at any CP regardless of adjacency to frontline or BLUEFOR/OPFOR state.
* Fixing typing issues, changint all Dict[] types to dict[]
* Updating changelog
The new class PurchaseGroup coming in with commit 9bb986c was not
initiallized correctly.
This causes the bug that the update function is not working when you
for example open the AircraftRecruitmentMenu press "+" or "-", close
the dialog and then open ArmorRecruitmentMenu. If you then want to buy
or sell the update function will raise an error "Internal C++ Object
Already Deleted".
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 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 AI purchaser will aim to have a 50/50 ground/air investment mix.
This allows it to overspend on one category if significant losses were
taken the previous turn.
The total purchase amount is still limited, so if the bases are full
when only 10% of the investment is in ground units, the full budget for
the turn will still go to air.
Disables the 'create transfer order' button in the unit transfer dialog if no units are actually selected for transfer (including when the dialog is first loaded).
To avoid confusion, use only the aircraft list for the purchasable
aircraft. This fix also caught a faction's Tu-142 that was not actually
purchasable. Invalid aircraft in the faction aircraft list will now
raise an error.
Fixes https://github.com/dcs-liberation/dcs_liberation/issues/1074
Removing the per-transit type supply routes allows us to find the best
route from A to B even if the unit needs to switch transit modes along
the way.
The "best" route is the one that will generate better gameplay. That is,
convoys are preferred to ships (use cases for GMT are rare in DCS), and
ships are preferred to airlift (reasons to attack cargo ships are also
rare). Avoiding airlift is also a good strategic choice generally since
it consumes aircraft that could be performing other missions.
The extreme weight against airlift in the pathfinding algorithm could
probably be scaled way down so that airlift would be given preference
over a very long trip, possibly only for urgent transfers.
Later when we add rail that will probably be given the most preference,
but possibly between road and shipping.
https://github.com/Khopa/dcs_liberation/issues/823
