This is used to provide a UI hint to guide players towards campaigns
that have been updated to work with the current version of the game.
All the campaigns we currently have were made for an unknown version of
the game, so they're all flagged as incompatible.
The version field is not the DCS Liberation version number because the
campaign format may change multiple times during development. Instead
the version number is a monotonically increasing integer that we
increment whenever a game change requires campaign updates.
On station time for CAP is only 30 minutes, so plan three cycles to give
~90 minutes of CAP coverage.
Default starting budget has increased significantly to account for the
greatly increased aircraft needs on turn 1.
Fixes https://github.com/Khopa/dcs_liberation/issues/673
This didn't do what it claimed to (it actually just determines the
threshold for whether a control point shoudl be a *preferred* canidate
for purchasing ground units), and the income multipliers offer the
intended behavior.
To have an effect on turn zero these need to be enabled in the wizard.
Since the last page was getting quite full I've split it into two pages:
one for the objective generation options and a second for the difficulty
and player assist options.
I also added an option to set the inital budget for opfor.
This adds both player and enemy income multiplier options. Note that
previously the AI was only getting 75% of their income. I've changed
that to give them their full income by default since the player can now
influence it.
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.
Logging before we've made it to the logging setup was causing the root
logger to be permanently configured to the default (warning) log
level, so we weren't getting any info or debug logs any more.
Defer the campaign data load until it is needed rather than doing it
at import time. I've also cleaned up a bit so we only load each
campaign once, rather than re-loading the campaign to create the
theater again after the wizard is finished.
