The `FactoryGroundObject` is just a special case of
`BuildingGroundObject` that we maybe don't actually need. For now it
provides some special case logic for the layout, but this allows any TGO
with the "factory" category to behave as a ground unit source.
Note that the "factory" random strike targets are *not* generated
anymore, so this doesn't affect campaign design currently.
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.
A was intended to be the blue point and B was intended to be the red
point. Make this a part of the name so that's clear, and clean up
related code to keep that reliable.
Some of the objective locations for the starting front line are too
aggressive and put opfor at a disadvantage since blue ships might start
so close to their bases.
No sense filling airbases with cheap escorts if we'll never afford the
rest of the package. Filling the airbases with cheap escorts also makes
it impossible to buy the rest of the package when the faction eventually
does have the money since there's nowhere to park the needed aircraft.
https://github.com/dcs-liberation/dcs_liberation/issues/1058
After fulfilling a request we were not exiting the loop, so we'd fulfill
the request for the aircraft at _all_ the bases capable of operating it
until either the bases were full or the budget ran out. In factions like
Iraq 1991 this could cause the budget to be spent on tons of cheap
MiG-19s while never buying the more expensive Su-17s or Su-24s that they
need to actually complete a package.
https://github.com/dcs-liberation/dcs_liberation/issues/1058
This allows users to install custom factions to their home directory
rather than the Liberation install directory. Makes it easier to keep
mods across Liberation downloads, and easier for us devs to keep custom
factions without git always wanting us to add them.
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
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.
