How It Works

How It Works

What actually happens between pressing RUN-IN and a load hitting the drop zone. You do not need any of this to fly a drop — read the Pilot Guide for that. This is for people who want to know why it behaves the way it does.

The shape of it

DZ + locked run-in + profile ──> path manager ──> autopilot ──> aircraft
actual aircraft state + wind + model ──> ballistic solver ──> LIVE RP ──> auto drop / cue
cargo leaves the aircraft ──> package tracker ──> RELEASED -> CHUTE -> ARRIVED

Three loops that run at the same time and talk to each other as little as possible.

The governing rule

The live ballistic solver is authoritative for release geometry. The path manager is best-effort flight-path compliance, and it does not get to veto a release.

That is why a high or fast aircraft still drops accurately: being off plan moves the release point rather than blocking the drop. It is also why there are no altitude, ground-speed or vertical-speed gates, and why adding one would be a real change rather than a tweak.

The ballistic solver

Works out where cargo has to leave the aircraft, from your actual current state — height, speed, vertical speed, and wind — re-solving several times a second.

It is built on an empirical model rather than a physics derivation: tables measured off real drops in the engine, per airframe. When a measurement disagreed with the model, the measurement won, and every number carries a note recording how many runs it came from and how it was measured.

The model knows about the things that actually cost accuracy:

• Release delay — the fixed script latency between "release now" and the load leaving. For the calibrated airframes that is 0.5607 s, measured across two airspeeds. It is a time, not a distance, which is why it does not scale with speed.
• Release offset — where on the aircraft a load actually leaves from.
• Forward throw — the load carries the aircraft's velocity and decelerates from about 140 m/s to near nothing over roughly five seconds. That deceleration is the geometry the release point is built around.
• Canopy behaviour — descent rate and drift under an open canopy, per airframe table.
• Wind — read from the engine, or entered by hand.

A solution is GOOD or it does not exist. There is no partial-confidence tier: a genuine failure — unsupported profile, failed solve, missing canopy model — exits as INVALID and stops the drop.

The path manager

Turns "the DZ, the locked run-in and your target height and speed" into a route, through five states:

INTERCEPT → CAPTURE FINAL → FINAL RUN → RELEASE STABLE → POST DROP

It builds a capture gate upstream on the locked final line, follows the line with a look-ahead, and then holds the exact locked heading.

Vertically it aims for DZ terrain elevation + your selected AGL, a fixed altitude — it does not terrain-follow. It starts the capture early rather than diving late, and clamps commanded vertical speed to between −20 and +12 m/s.

The autopilot

Consumes the path manager's desired track and commanded vertical speed and flies the aircraft to them.

By default it applies forces and torques and lets Arma's flight model fly, so it banks and pitches like an aeroplane. The older behaviour — writing velocity and heading directly — is still available as a setting.

It is a deterministic mission autopilot, not an aerodynamic PID, and it is explicitly best-effort. It hands back the instant you move a control past the override threshold, and names the reason on the HUD.

One steering reference. The flight director needle and the autopilot read the same smoothed track. Until v0.16.0 they read different ones, so the aircraft and the instrument were flying to different numbers.

The release gate

Inside the final envelope, auto drop requires all three of:

Limit	Default
Cross-track	≤ 25 m
Track error	≤ 2°
Predicted pre-chute lateral drift	≤ 25 m

Geometry only. The drift term is there because runtime data showed misses correlating with the aircraft's sideways velocity during the load's freefall — measured at about +1.3 m/s producing +30 m, and −2.9 m/s producing −68 m, over roughly 24 seconds of fall.

The release

CARP runs the whole sequence itself: open the doors and wait, drop collision, attach at the release offset, a half-second hold, detach, inherit the carrier's velocity, then the canopy.

It runs where the cargo is local — on a dedicated server, usually the server. That one fact explains most multiplayer behaviour in this mod.

The canopy opens facing backward, deliberately. A steerable canopy pointed into 106 m/s of forward airflow balloons, brakes to −1.8 m/s and levels off 41 m high, then spends that altitude at terminal. Flown minutes apart on the same line: 42.9 s and 113.5 m facing forward, against 35.1 s and 21.1 m facing backward. Every calibration run was flown with it backward, so that is the canopy the tables describe, and CARP now forces it regardless of how the load was packed.

The canopy trigger is a per-frame test, never a scheduled poll. A scheduled script shares a few milliseconds of frame time with everything else, and at 230 m/s of freefall that is metres per frame. One late canopy destroyed a load in flight; the check runs on the frame loop now.

The package tracker

Once something leaves, it is tracked independently of whether a release solution still exists:

IDLE → ESTIMATE → RELEASED → CHUTE → ARRIVED (or LOST)

Release is detected by the load disappearing from the aircraft's manifest, which catches a drop made any way at all. Canopy is detected when the load's parent becomes a parachute, at which point the time on target is rebased on the real event rather than the prediction. Arrival needs low-AGL ground contact held for half a second after airborne confirmation.

Cargo sources

One function answers "what is aboard and droppable", across four physical sources:

Source	Where it comes from
CARP	Its own load action
USAF	The USAF cargo system, if that mod is loaded
ACE	ACE cargo — real objects only, not ACE's virtual class-name entries
Vehicle-in-vehicle	The engine's own carriage

Order matters: loads stack forward from the ramp and leave back to front, which is also the order guided loads are spaced along the run-in.

Multiplayer

Only intent is shared — the fourteen-odd values a human chose. Everything derived from them is recomputed locally by each client, because those calculations read that client's own view of the aircraft. Putting the solution or the HUD state on the network would replace a correct local answer with a stale remote one twenty times a second.

The record lives on the aircraft, the server is the only writer, and patches are merged field by field so two people editing different things both keep their change. The details are on Crew and Multiplayer.

Guided cargo

Covered on its own page — Guided Cargo — including the three things that each cost a release to discover.

How the numbers were got

Two harnesses: one runs many independent drops per descent, one measures the interval between releases in a stick. Both feed a model whose every value records its sample size and method.

What the bench structurally cannot test is the cockpit: it calls the release directly, so it never exercises the pilot seat, the autopilot, the release gate, the HUD or the cue-to-release path. It once validated a wrong release delay across forty batches while every actually-flown drop landed 44 m short.

The rule the project keeps re-learning: when a measurement implies something physically impossible, suspect the instrument before the physics. A lag shorter than a hardcoded half-second sleep, or a canopy opening below a fixed trigger altitude, is an instrument problem every time.

Further reading

• Accuracy — the measured figures and what each one is worth
• Settings — every knob, and which are server-forced
• Repository — the source, and the comments in it carry the reasoning for most of the above