refactor to enum
typing and many other fixes
fix tests
attempt to fix some typescript
more typescript fixes
more typescript test fixes
revert all API changes
update to pydcs
mypy fixes
Use properties to check if player is blue/red/neutral
update requirements.txt
black -_-
bump pydcs and fix mypy
add opponent property
bump pydcs
* Roadbase and ground spawn support
Implemented support for roadbases and ground spawn slots at airfields and FOBs. The ground spawn slots can be inserted in campaigns by placing either an A-10A or an AJS37 at a runway or ramp. This will cause an invisible FARP, an ammo dump and a fuel dump to be placed (behind the slot in case of A-10A, to the side in case of AJS37) in the generated campaigns. The ground spawn slot can be used by human controlled aircraft in generated missions. Also allowed the use of the four-slot FARP and the single helipad in campaigns, in addition to the invisible FARP. The first waypoint of the placed aircraft will be the center of a Remove Statics trigger zone (which might or might not work in multiplayer due to a DCS limitation).
Also implemented three new options in settings:
- AI fixed-wing aircraft can use roadbases / bases with only ground spawns
- This setting will allow the AI to use the roadbases for flights and transfers. AI flights will air-start from these bases, since the AI in DCS is not currently able to take off from ground spawns.
- Spawn trucks at ground spawns in airbases instead of FARP statics
- Spawn trucks at ground spawns in roadbases instead of FARP statics
- These settings will replace the FARP statics with refueler and ammo trucks at roadbases. Enabling them might have a negative performance impact.
* Modified calculate_parking_slots() so it now takes into account also helicopter slots on FARPs and also ground start slots (but only if the aircraft is flyable or the "AI fixed-wing aircraft can use roadbases / bases with only ground spawns" option is enabled in settings).
* Improved the way parking slots are communicated on the basemenu window.
* Refactored helipad and ground spawn appends to static methods _add_helipad and _add_ground_spawn in mizcampaignloader.py
Added missing changelog entries.
Fixed tgogenerator.py imports.
Cleaned up ParkingType() construction.
* Added test_control_point_parking for testing that the correct number of parking slots are returned for control point in test_controlpoint.py
* Added test_parking_type_from_squadron to test the correct ParkingType object is returned for a squadron of Viggens in test_controlpoint.py
* Added test_parking_type_from_aircraft to test the correct ParkingType object is returned for Viggen aircraft type in test_controlpoint.py
---------
Co-authored-by: Raffson <Raffson@users.noreply.github.com>
If a user removes all squadrons manually, the faction may still contain aircraft but no budget for aircraft should be allocated at all. In such a case, all money should go to ground units...
- 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
- Factored out the current generators to use a better approach with Templates build from the dcs mission editor.
- This information is extended with a template-mapping in a json file which allows to logically group together multiple dcs groups and even statics to one template
- The combination of mapping and miz will be serialized to a template.json which is only used for loading.
- Factions now load templates during initialization and hold all the templates they can really use. This is based around the faction file.
- Implemented a template randomizer which allows to add some randomization to templates
- Each Template Group can have 1 randomizer which randomizes unit_type and size based on the mapping definition. Larger groups need to be devided in more fine detailed groups as we can now handle them better due to the change from dcs group types to our own classes.
- Rewritten the ArmorGroup, Naval and EWR template handling
Rework GroundObjectBuyMenu to support templates
- Added expected_pilots_next_turn() to Squadron. The procurement AI now correctly compares to it when evaluating if planes should be bought, instead of the maximum possible number of pilots.
- Added replenish_rate method to squadron.py to prevent expected_pilots_next_turn from returning an incorrect (too large) number when replenish rate > pilots required.
#1837
This doesn't do anything yet, but sets up the data model handling for
frozen combat. The next step is to show combat in the map view, since
that will be helpful when debugging the step after that one: resolving
frozen combat.
This would benefit from caching the Shapely data for SAM threat zones.
Right now it's generating them once per tick and the stuttering is
visible at max speed.
https://github.com/dcs-liberation/dcs_liberation/issues/1680
This also does improve the over-purchase problems, though I can't spot
the behavior change that's causing that. Presumably the old
implementation had a bug I can't spot and in rewriting it I solved the
problem...
Fixes https://github.com/dcs-liberation/dcs_liberation/issues/1582
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.
Since the theater commander runs once per campaign action, missions that
do not have aircraft available may be checked more than once a turn.
Without deduping requests this can lead to cases where the AI buys
dozens of tankers on turn 0.
Fixes https://github.com/dcs-liberation/dcs_liberation/issues/1470
The doctrine/task limits were capturing a reasonable average for the
era, but it did a bad job for cases like the Harrier vs the Hornet,
which perform similar missions but have drastically different max
ranges. It also forced us into limiting CAS missions (even those flown
by long range aircraft like the A-10) to 50nm since helicopters could
commonly be fragged to them.
This should allow us to design campaigns without needing airfields to be
a max of ~50-100nm apart.
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.
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.
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.
This changes the ground unit purchase behavior such that the supply
limit is exceeded by 30%, with the extra units kept in reserve.
The old hard cap of 50 units is no longer needed, since the ammo supply
now does the same task, so that's been removed.
Unit composition is defined by the doctrine. The most understaffed CP
will now get the most underrepresented unit type. Previously a random
understaffed CP would get a random unit type.
Fixes https://github.com/dcs-liberation/dcs_liberation/issues/1057.
This limit is determined by the number of buildings that belong to Ammo
Depots at the front line's connected Control Point. The limit increases
for every surviving building at ammo depot objectives.
There is a lower limit to the number of units that will spawn, so that
if there are no surviving ammo depot buildings at a control point, there
will still be some ground conflict.
Without this, *this turn's* urgent requests are lower priority than last
turn's stretch goals. The requests are remade every turn so we lose
nothing by removing this.
Bug was introduced by f69450e2ae24df81d42b1ebc63d8375731154612, so this
doesn't affect 2.5.
We were accidentally iterating over the faction list and checking it
against the priority list rather than the other way around, so the
faction's aircraft list was being used for purchase priority rather than
the actual priority list in the game.
No sense filling airbases with cheap escorts if we'll never afford the
rest of the package. Filling the airbases with cheap escorts also makes
it impossible to buy the rest of the package when the faction eventually
does have the money since there's nowhere to park the needed aircraft.
https://github.com/dcs-liberation/dcs_liberation/issues/1058
After fulfilling a request we were not exiting the loop, so we'd fulfill
the request for the aircraft at _all_ the bases capable of operating it
until either the bases were full or the budget ran out. In factions like
Iraq 1991 this could cause the budget to be spent on tons of cheap
MiG-19s while never buying the more expensive Su-17s or Su-24s that they
need to actually complete a package.
https://github.com/dcs-liberation/dcs_liberation/issues/1058
The purchase system will seek out a source for its units when the
purchase is completed. If no source is available the order will be
refunded. Orders with no source available are prevented, so this only
happens when the source was cut off from the destination during the
turn.
There's still some funkiness going on with the first turn (but possibly
only when the first turn includes a cheat to capture) where the AI buys
a ton of units somewhere other than the front line. First turn behavior
should probably be different anyway, with the first turn allowing
purchases anywhere to avoid empty front lines while troops reinforce if
the front line isn't a factory.
https://github.com/Khopa/dcs_liberation/issues/986
