Downside to the current implementation is that whether or not transports
that were purchased last turn will be available for airlift this turn is
arbitrary. This is because transfers are created at the same time as
units are delivered, and units are delivered in an arbitrary order per
CP. If the helicopters are delivered before the ground units they'll
have access to the transports, otherwise they'll be refunded. This will
be fixed later when I rework the transfer requests to not require
immediate fulfillment.
https://github.com/Khopa/dcs_liberation/issues/825
Historically this inherited from Event but there was no reason for that.
That's gone now. Finish the separation and move the unit order tracking
class out of the combat results reaction class's file.
This is an interim improvement since we should probably be pushing the
BARCAPs into TARCAP roles when the front line is so close. This does
regress flight pathing for anything that should route around the front
(to avoid getting shot at by SHORADS and TARCAPs), but for now it's one
or the other and this is the one everyone's complaining about.
UI isn't finished. Bulk transfers where the player doesn't care what
aircraft get used work (though they're chosen with no thought at all),
but being able to plan your own airlift flight isn't here yet.
Cargo planes are not implemented yet.
No way to view the cargo of a flight (will come with the cargo flight
planning UI).
The airlift flight/package creation should probably be moved out of the
UI and into the game code.
AI doesn't use these yet.
https://github.com/Khopa/dcs_liberation/issues/825
Like the comment says this rarely has any effect due to the ordering of
flight planning and convoy creation. Could be separated, but opfor will
still not be able to target any convoys that the player creates in the
UI on that turn because they planning is done before the player can use
the UI.
Multi-turn transfers will be targetable, however.
The previous flight plan only makes sense if the convoy will make it a
significant distance from its starting point. At road speeds over the
typical mission duration this is not true, so we can actually plan this
as if it was a strike mission near the origin point and that's close
enough.
There's some cleanup work to do here that I've added todos for.
Fixes https://github.com/Khopa/dcs_liberation/issues/996
This currently is only supported for player flights. I have no idea how
to create an AI flight plan that won't just get them killed. AI-only BAI
missions against supply routes will warn the player on mission creation.
A CP with a factory would be able to supply itself, but was not in a
supply route if it was the only connected friendly CP. When the player
starts with only one base against an enemy base this meant that it was
in no supply route, causing it to not be a recruitment location or a
place to buy more than a reserve of vehicles automatically.
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
This also removes the "factory" type from the normal strike target
(money generating) generators to avoid confusion. Later only control
points with factories will be able to spawn ground units, at which point
these will no longer generate income.
https://github.com/Khopa/dcs_liberation/issues/986
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.
This adds the models and UIs for creating ground unit transfer orders.
Most of the feature is still missing:
* The AI doesn't do them.
* Transfers can move across the whole map in one turn.
* Transfers between disconnected bases are allowed.
* Transfers are not modeled in the simulation, so they can't be
interdicted.
https://github.com/Khopa/dcs_liberation/issues/824
* A Bluefor EWR 55GS in the campaign miz defines an optional EWR site. There is no distinction between how close or far it is to a base, so it's possible that there will be many EWRs within an airbase.
* A Redfor EWR 1L13 in the campaign miz defines a required EWR site.
It would be a good future idea to limit the amount of EWRs within a certain distance from an airbase. That way there's no chance of 5 EWRs all at the same airbase. Even better if there were something preventing any two EWRs from being right next to each other.
No campaigns take advantage of this yet.
Fixes https://github.com/Khopa/dcs_liberation/issues/524
`Game.date` is actually the start date, not the current date. Not renaming to
avoid breaking save compat.
This fix won't have any effect on existing saves until they pass the turn
because this is encoded into the conditions generated at the start of the turn,
but it will fix on the next turn.
Fixes https://github.com/Khopa/dcs_liberation/issues/973
