These are assigned a squadron even though they're unused as a hack. We
need to tolerate these aircraft having no pilot assigned since that's
the desired case for unused aircraft (though only happens when the
squadron runs out of pilots, which should be fixed).
This PR allows campaign creators to incorporate map objects (referred to as Scenery in the code) into their Liberation campaign.
Map objects are defined using white trigger zones created by right clicking on scenery and clicking `assign as...`. Objective groups are defined by creating a blue TriggerZone surrounding the centers of the white trigger zones. The type of objective is determined by the campaign creator, assigning the value of the first property of the blue TriggerZone with the objective type.
Map objects maintain their visually dead state by assigning a `Mission Start` `Scenery Object Dead` trigger to the trigger zone. It is important for the Liberation generated TriggerZone to be as small as possible so that no other scenery is marked dead by DCS.
TriggerZones are hidden during gameplay (DCS behavior. I don't know if it's possible to turn that off.) TriggerZones are visible in the mission editor and mission planner however. If a player is using an older plane, it is important for them to remember where the target is.
In the mission planner, the trigger zones' will be blue or red depending on which faction the map objects belong to.
Inherent Resolve campaign has been modified to integrate scenery objects.
### **Limitations:**
- Objective definitions (Any Blue TriggerZones) in campaign definition cannot overlap.
- Map object deaths in `state.json` is tracking integers. You won't know what died until debriefing.
- No images for the various buildings. In theory it can be done, but an unreasonable amount of work.
- Every blue trigger zone must have a unique name. (If you let DCS auto increment the names this is not a concern.
- No output to screen when scenery object is dead. You can see the building drawn as dead in the F10 map though.
### **Pictures:**
An objective:
How the objective looks once in the mission planner/editor. This objective belongs to the enemy faction:
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
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
Apparently we were already getting this info because it's a unit like
any other according to the event system, so if runways were actually
sufficiently damaged we'd emit a ton of exceptions.
This doesn't do anything yet, but tracks the damage state. Will add the
ability to repair them next, and then finally make the damage render the
runway inoperable.
The aircraft that have not been fragged will now be spawned in parking
to provide more targets for OCA strikes. We do this only at airports,
not carriers. The AI has enough trouble taxiing around uncrowded carrier
decks that we probably shouldn't make it harder for them, plus most of
the aircraft will be stored below the flight deck (we allow 90 aircraft
to be stored at the carrier, which certainly will not fit on the flight
deck).
The aircraft are spawned in an uncontrolled state and nothing will
activate them, so aside from the cost of rendering them they shouldn't
affect performance.
Fixes https://github.com/Khopa/dcs_liberation/issues/148
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.
