Fixes https://github.com/Khopa/dcs_liberation/issues/417, though the
notes on that bug about this being non-optimal for skynet are still
true. This doesn't make skynet behavior any worse though, and does
improve it some compared to not having PD.
Adds two new SA-10 generator variants:
* Tier 2, with SA-15 for point defense
* Tier 3, with SA-15 for point defense and the Shilka upgraded to a
Tunguska.
Updated factions that are capable of those systems, added missing SAMs
to those factions, and removed use of SA-19 as an independent SAM from
those factions. Will do a larger audit of faction SAMs later.
Enabled for bluefor modern, since they ought to have GPS but seemingly
don't.
This change does nothing until https://github.com/pydcs/dcs/pull/102
lands and we update to it.
Generated units are added to this during mission generation so we can
map destroyed units back to the data that generated them. Currently only
implemented for aircraft as a proof of concept.
The AI isn't making use of these yet, but it's not smart enough to do so
anyway.
Would benefit from an icon to differentiate it on the map.
I'm stretching the definition of "control point" quite a bit. We might
want to put a class above `ControlPoint` for `AirSpawnLocation` to
represent types of spawn locations that can't be captured and don't have
ground objectives.
Fixes https://github.com/Khopa/dcs_liberation/issues/274
"Required" SAMs (designative by redfor long range SAM launchers in the
ME) will always be spawned during campaign generation. This makes it
possible to build a semi-guaranteed IADS (the exact type of SAM is
dependent) on the choice of faction.
Requierd SAMs will consume the slots of random SAMs during generation.
Later we should differentiate between strategic SAMs like SA-10s and
tactical SAMs like SA-11s so we can fill in the medium range SAMs at
random locations among the fixed long range SAMs.
When a base is captured we clear its defenses. Those locations need to
be returned to the preset location pool so they can be used for the new
base defenses.
Defining a campaign using a miz file instead of as JSON has a number of
advantages:
* Much easier for players to mod their campaigns.
* Easier to see the big picture of how objective locations will be laid
out, since every control point can be seen at once.
* No need to associate objective locations to control points explicitly;
the campaign generator can claim objectives for control points based
on distance.
* Easier to create an IADS that performs well.
* Non-random campaigns are easier to make.
The downside is duplication across campaigns, and a less structured data
format for complex objects. The former is annoying if we have to fix a
bug that appears in a dozen campaigns. It's less an annoyance for
needing to start from scratch since the easiest way to create a campaign
will be to copy the "full" campaign for the given theater and prune it.
So far I've implemented control points, base defenses, and front lines.
Still need to add support for non-base defense TGOs.
This currently doesn't do anything for the `radials` property of the
`ControlPoint` because I'm not sure what those are.
