This doesn't currently interact very well with the auto purchase since
the procurer might by aircraft that don't have pilots available. That
should be fixed, but for the short term we should just default to not
enabling this new feature.
If these orders can't be fulfilled for the faction it will prevent the
faction from ordering any non-reserve aircraft since transports are
given priority after reserve missions, and they'll never be fulfillable.
As such, no non-reserve aircraft will ever be purchased for factions
without transport aircraft.
Factions without transport aircraft are screwed in other ways, but this
will fix their air planning for campaigns that aren't dependent on
airlift.
Squadron.aircraft is of type AircraftType, while TRANSPORT_CAPABLE is
a list of pydcs DcsUnitTypes. As a result, the intersection was always
empty causing the function to always return 0.
This is an attempt to remove a lot of our supposedly unnecessary error
handling. Every aircraft should have a price, a description, a name,
etc; and none of those should require carrying around the faction's
country as context.
This moves all the data for aircraft into yaml files (only one converted
here as an example). Most of the "extended unit info" isn't actually
being read yet.
To replace the renaming of units based on the county, we instead
generate multiple types of each unit when necessary. The CF-18 is just
as much a first-class type as the F/A-18 is.
This doesn't work in its current state because it does break all the
existing names for aircraft that are used in the faction and squadron
files, and we no longer let those errors go as a warning. It will be an
annoying one time switch, but it allows us to define the names that get
used in these files instead of being sensitive to changes as they happen
in pydcs, and allows faction designers to specifically choose, for
example, the Su-22 instead of the Su-17.
One thing not handled by this is aircraft task capability. This is
because the lists in ai_flight_planner_db.py are a priority list, and to
move it out to a yaml file we'd need to assign a weight to it that would
be used to stack rank each aircraft. That's doable, but it makes it much
more difficult to see the ordering of aircraft at a glance, and much
more annoying to move aircraft around in the priority list. I don't
think this is worth doing, and the priority lists will remain in their
own separate lists.
This includes the converted I used to convert all the old unit info and
factions to the new format. This doesn't need to live long, but we may
want to reuse it in the future so we want it in the version history.
The routes do not need be be recreated each time we create a
`FrontLine`. The front lines follow the convoy routes, which are static.
Add the convoy route data to the `ControlPoint` the way we do for
shipping lanes and have `FrontLine` load the data from there.
Removing the per-transit type supply routes allows us to find the best
route from A to B even if the unit needs to switch transit modes along
the way.
The "best" route is the one that will generate better gameplay. That is,
convoys are preferred to ships (use cases for GMT are rare in DCS), and
ships are preferred to airlift (reasons to attack cargo ships are also
rare). Avoiding airlift is also a good strategic choice generally since
it consumes aircraft that could be performing other missions.
The extreme weight against airlift in the pathfinding algorithm could
probably be scaled way down so that airlift would be given preference
over a very long trip, possibly only for urgent transfers.
Later when we add rail that will probably be given the most preference,
but possibly between road and shipping.
https://github.com/Khopa/dcs_liberation/issues/823
Shipping lanes that received a ship would never lose their ships when
transfers completed, so the line on the map was staying solid (and
probably targetable).
The simple form of this works, but without the multi-mode routing it'll
only get used when the final destination is a port with a link to a port
with a factory.
These also aren't targetable or simulated yet.
https://github.com/Khopa/dcs_liberation/issues/826
Also changes when we clear the convoys. Because we plan when transfers
are added (to plan UI orders immediately) we were planning convoys when
delivering units, then clearing the convoys, then planning them again.
Aside from the wasted effort, when we cleared the convoys we forgot to
tell the transfer that they no longer had transport, so when replanning
they did not get a new convoy.
This gives a clean break between the transfer request and the type of
transport allocated to make way for transports that need to switch
types (to support driving to a port, then getting on a ship, to a train,
then back on the road, etc).
https://github.com/Khopa/dcs_liberation/issues/823
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
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
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.
