* 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>
- Unit yamls for several ships and added some new ones to uk_1990.json
- 2 new layouts: Aircraft Carrier / LHA with Frigate escorts
- Add "HMS Invincible" as Control Point
Fixed (zombie) carrier killed in state.json but always respawning in-game, issue #2405. GenericCarrierGenerator.generate() will now generate the ship group with an array that only contains alive ship units, just like GroundObjectGenerator.generate() has previously done.
Carrier groups will now also show up as destroyed/damaged on the map when the carrier is sunk.
Squashing 8 commits by DanAlbert:
- Track theater in ControlPoint.
Simplifies finding the owning theater of a control point. Not used yet.
- Clean some cruft out of FlightPlanBuilder.
- Clean up silly some exception handling.
- Move FlightPlan instantiation into the builder.
I'm working on moving the builder to be owned by the Flight, which will simplify callers that need to create (or recreate) flight plans for a flight.
- Simplify IBuilder constructor.
We have access to the theater via the flight's departure airbase now.
- Move FlightPlan creation into Flight.
For now this is just a callsite cleanup. Later, this will make it easier
to separate unscheduled and scheduled flights into different classes without complicating the layout/scheduling.
- Remove superfluous constructors.
- Remove unused Package field.
- Add the new airassault mission type and special flightplans for it
- Add the mission type to airbase and FOB
- Add Layout for the UH-1H
- Add mission type to capable squadrons
- Allow the auto planner to task air assault missions when preconditions are met
- Improve Airlift mission type and improve the flightplan (Stopover and Helo landing)
- Allow Slingload and spawnable crates for airlift
- Rework airsupport to a general missiondata class
- Added Carrier Information to mission data
- Allow to define CTLD specific capabilities in the unit yaml
- Allow inflight preload and fixed wing support for air assault
- factor out own class for the iadsnetwork within the conflicttheater
- This class will handle all Skynet related things - no specific group_name handling necessary in future
- make iadsbuilding own TGO class because SAM & EWRs are Vehicle Groups. IADS Elements dont have any groups attached.
- added command center, connection node and power source as Ground objects which can be added by the campaign designer
- adjust lua generator to support new iads units
- parse the campaign yaml to get the iads network information
- use the range as fallback if no yaml information was found
- complete rewrite of the skynet lua script
- allow destruction of iads network to be persistent over all rounds
- modified the presetlocation handling: the wrapper PresetLocation for PointWithHeading now stores the original name from the campaign miz to have the ability to process campaign yaml configurations based on the ground unit
- Implementation of the UI representation for the IADS Network
- Give user the option to enable or disable advanced iads
- Extended the layout system: Implement Sub task handling to support PD
This allows unique identification across saves. The front-end needs to
be able to differentiate the first carrier in game A and the first
carrier in game B, but because carriers (and other non-airfield CPs) are
assigned IDs sequentially, collisions were to be expected. The front-end
can't tell the difference between a reloaded game and a new turn, so we
need to ensure different IDs across games.
This is a handy cleanup anyway, since callers constructing CPs no longer
need to manually track the CP ID counter.
Fixes https://github.com/dcs-liberation/dcs_liberation/issues/2078.
The UI needs to be able to identify these to the server and vice versa,
so they'll need IDs that don't change. Rather than constructing an ID
based on the control points names, make them an owned part of the
control point. The constructed ID would be fine, but a UUID will make
them more suitable for the database, and this was always fairly gross
anyway.
Some follow up work if anyone is interested: a bunch of the data that's
computed in the various properties can now probably be computed *once*
and persisted to the FrontLine type.
This gets us out of the business of maintaining our own icons. The
milsymbol library generates the SVG data needed to display anything
covered by APP-6.
- 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.
This exports all the old AIRFIELD_DATA to yaml files. It's easier for
users to send fixes if it's defined this way, and they can also fix it
in their install without having to wait for a new release.
This also switches the indexes from the unstable DCS airfield names to
airfield IDs, so this fixes another case of DCS updates occasionally
breaking Liberation.
I also ended up finding quite a few typos in airfield names, and
incorrect theater names in the process. Those have been fixed.
