Changelog

Changelog

Current version: 1.0.0

The canonical notes for every version live on the Releases page. This page is the running summary, newest first.

---

Unreleased

Every scripting symbol is now TLB_CARP_ instead of USAFDC_. The prefix was the old product name — USAF Drop Computer — and it outlived the rename to TLB CARP by a long way. 426 symbols, and the addon path inside the PBO with them: x\usafdc\addons\drop_computer became x\tlbcarp\addons\drop_computer.

What this means if you run a server or write missions:

• cba_settings.sqf needs the new prefix. force USAFDC_setting_requireComputer does not error, it simply stops doing anything — so this is worth doing deliberately rather than discovering later.
• Script hooks renamed too: USAFDC_dropPos and USAFDC_loadPos are now TLB_CARP_dropPos and TLB_CARP_loadPos.
• Do not mix builds in one aircraft. A pre-rename client keeps its shared record under the old variable, which the new build never reads — both crews would see a perfectly coherent CARP and never see each other. Opening the panel now says so when it detects one, because the existing version warning cannot: that version number travels inside the record that is no longer being read.

Also: the 24 compiled .sqfc files were deleted. Each had the old names compiled in and shadowed the .sqf beside it, so any survivor would have silently run pre-rename code.

Source-verified, not yet loaded in Arma. A rename that misses one of the three places the addon path is written fails silently: the PBO mounts where nothing is looking, and every function is nil with nothing in the RPT to explain it. The test suite pins all three against each other, but confirm the addon loads before flying it.

---

1.0.0

The first public release. What it contains, by the area it changed:

Release and cargo

• CARP runs the whole release sequence itself. The USAF mod is optional rather than required; Use USAF Release Sequence exists only so the two paths can be compared.
• CARP loads cargo too. Three mechanisms — vehicle-in-vehicle, a USAF load position read from config, or a hold derived from the bounding box — so a vehicle no longer has to arrive through somebody else's loader to be droppable.
• Four cargo sources answered by one manifest: CARP, USAF, ACE (real objects) and vehicle-in-vehicle.
• Unloading refuses above 3 m, deliberately.

Accuracy

• The canopy now opens facing backward. A steerable canopy pointed into the airflow balloons and levels off high; flown on one line minutes apart, 42.9 s / 113.5 m facing forward against 35.1 s / 21.1 m facing backward. Every calibration run was flown backward, so that is the canopy the tables describe. Confirmed on the fix at 19.3 m radial.
• The canopy trigger is a per-frame test, not a scheduled poll.
• No DEGRADED tier. A solution is GOOD or it does not exist. The five calibration warnings, the amber HUD block and the allowDegradedAuto gate are gone; every genuine failure still exits INVALID and stops the drop.

Flying

• The autopilot flies with forces and torques by default, so the aircraft banks and pitches like an aeroplane. The old direct-write behaviour is still a setting.
• One steering reference — the flight director needle and the autopilot read the same smoothed track. They read different ones before.
• The release drift limit is a setting, default 25 m.
• The map no longer disconnects the autopilot.

Crew

• Crew sync rewritten: the record lives on the aircraft, the server is the only writer, and edits merge field by field so two people changing different things both keep theirs.
• The CARP Computer item gates access, switchable off per mission.
• Guided cargo runs where the canopy lives, with a heartbeat so the HUD can tell "another machine has it" from "nobody has it".

Guided cargo

• Each load in a stick gets its own slot along the run-in, so they stop landing on top of each other.
• Steering flares below 25 m, keeping the wind term in full.

Packaging

• Every release is signed. One persistent key, tlb_carp.bikey, installed once rather than per release.
• config.bin is a build artifact again: config.cpp is the source of truth and the panel layout is generated from a spec that refuses to emit overlapping controls.

Known limits at 1.0.0

• Multiplayer is source-verified, not flown. Everything from v0.10.0 on still needs a two-player dedicated-server pass.
• Guided accuracy on a dedicated server is unmeasured.
• Signing has not yet been through a live verifySignatures = 2 connection.

See Accuracy for the full list.

---

Before 1.0.0

The pre-1.0 history is in the development repository, one commit per change. It is not reproduced here: the versions before 1.0.0 were never published, and a changelog of unreleased builds is noise rather than a record.

---

How a changelog entry gets made

This is the process, so entries stay consistent whoever writes them.

The release notes on GitHub come from the commit body of the tag, and after a squash merge that body is whatever the release pull request's description was. So:

1. Bump TLB_CARP_VERSION in addon/functions/fn_postInit.sqf.
2. Build and verify:

   python tools/build_release.py --version <x.y.z.0> --label <slug>

   It runs the test suite, builds and signs both PBOs, writes the release and source ZIPs, and re-runs the suite from a fresh extraction of the source ZIP. It fails rather than shipping something unverified.
3. Open the release pull request. Title it v1.2.3 - short title, and make the description the release notes themselves — no checklists, no test plan, nothing that should not appear on the Releases page.
4. Merge, tag main, and publish:

   python tools/publish_release.py --tag v1.2.3

5. Add the same summary at the top of this page.

The full workflow is in CONTRIBUTING.md.

What belongs in an entry

• What changed and why, in plain words. The reasoning that would otherwise be lost.
• Measured numbers where a decision rests on one. Every accuracy figure in this project traces to a flown or benched drop; quote the measurement, not an impression.
• What has not been tested. If a change is source-verified but has not been flown, the entry says so. That is not a caveat to bury — it is the most useful line in the entry.

What does not

• Marketing, emoji, "as requested", or a restatement of the diff line by line.
• Review scaffolding — checklists, "ready for review", screenshots of a terminal.
• Any claim that a flight-behaviour fix works because the test suite is green. The suite proves the source says what it should; it proves nothing about how the mod behaves in Arma.