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
- 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.
We had this for the old style in-flight spawns, but not for mid-mission
spawns. Aircraft that were spawning soon after takeoff could potentially
be close to (or under) the ground, causing them to "crash" at game
start. The altitude is different here than for the old style in-flight
spawns to try to get closer to the intended spawn location.
Fixes https://github.com/dcs-liberation/dcs_liberation/issues/1941
Helipads at airfields don't work well right now because they are not
counted as additional parking, but we should still allow them to take
off from the airfield parking.
Follow up work would be to fix the parking problem and allow adding
helipads to airfields, or maybe to just "ground" start helicopters at
airfields so they take off from parking rather than the runway.
May fix https://github.com/dcs-liberation/dcs_liberation/issues/1890
Kneeboard improvements:
* Optional (aircraft specific) metric speeds/distances/altitudes.
* Heading to waypoint.
Fuel still needs to be converted to metric, but good enough for now.
Fixes https://github.com/dcs-liberation/dcs_liberation/issues/915
- removed the map_object_id from the TGO
- add a new TriggerRule with the MapObjectIsDead Condition which adds the map object to the killed_map_objects array in the state.json
- Use the trigger_zone_name as the unique identifier used for the unit_map to recognize the kill
CPU load seems to scale with route length, so add an option to limit
the length of the convoy route. The tradeoff is that the performance
sensitive route won't necessarily be a correct route.
* 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.
These should be uncontrolled rather than late activation so that they
are present in the parking area as OCA targets. This bug was introduced
as a mistranslation when I was moving from strings to StartType.
Fixes https://github.com/dcs-liberation/dcs_liberation/issues/1695
There's nothing the user can do about this and it's somewhat expected,
so downgrade to a warning so users don't think it's a bug.
If we ever get around to doing more cautious parking allocation this
should become a generation-halting error, but until then we expect it to
happen somewhat often.
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
