Skip to content

Crew and Multiplayer

godgutten edited this page Sep 21, 2026 · 1 revision

Crew and Multiplayer

Everyone in the aircraft carrying a CARP Computer shares one CARP. Set the drop zone in the left seat and it appears in the right.

Status: the multiplayer layer is source-verified, not flown. Everything from v0.10.0 onwards still needs a two-player dedicated-server pass. If you find it misbehaving, that is worth an issue.

What is shared

Only intent — the values a human chose:

drop zone · mode · aircraft profile override · manual wind · target AGL · target GS · cargo count · run-in lock and heading · smoke · JPADS · stick size · opening height · and the two "want guidance / want auto drop" flags.

Nothing derived is shared. Not the solution, not the path, not the HUD state, not the package tracker. Each client recomputes those from its own view of the aircraft, because that is the only view that is correct on that machine. Sending them would replace a correct local answer with a stale remote one twenty times a second.

How it stays in sync

The shared record lives on the aircraft, not on a player. That means it is scoped to the airframe, so two aircraft running CARP cannot collide; it reaches players who join mid-flight automatically; and it outlives any one crew member.

  • The server is the only writer. A client sends just the fields it changed, as individual patches, and the server lands each one on the record as it stands. Two people changing different fields in the same second both keep their change.
  • Publishing happens only where a human just acted — not on a poll. A poll cannot tell "I changed this" from "I failed to apply what somebody else changed", and sending the second clobbers the author.
  • A client adopts any record that is not the one it last adopted, rather than only newer ones. The event that announces a change is a doorbell; the record is read at 5 Hz regardless, so a missed event costs latency and never correctness.
  • Without CARP on the server, a client merges for itself and says so once.

The CREW line on the panel shows who is sharing the drop and the record's revision number. Two panels showing the same REV are in sync.

CARP also names a crew member running a different version of the mod.

Authority

Intent is shared. Control is not.

Who
Drop zone, mode, heights, speeds, cargo count, toggles Either crew member
Locking the run-in Either crew member
The autopilot The driver only
The release command The driver only
Latching a missed pass, calling GO AROUND The owner only

The release gate is the reason for the last three. Shared auto drop would mean every client crosses the release point within milliseconds of the others and each one commands a release, which takes a load each time. And a non-driver is solving against a replica updated at roughly 10 Hz and extrapolated in between — at 140 m/s that error is the same order as the 25 m and 2° gate it would be judging.

A client that does not own the aircraft sees [OBSERVING], and the autopilot refuses to arm with AIRCRAFT NOT LOCAL.

The one thing that must be on the server

The mod. Not just on the clients.

On a dedicated server the cargo is usually owned by the server, and that is the machine that:

  • performs the release,
  • flies guided canopies,
  • and merges the crew's edits.

Without CARP there, drops quietly do nothing. This is the single most common multiplayer problem — see Troubleshooting.

Markers

Every marker CARP draws — the DZ, the run-in line, the release point, the canopy point, the touchdown — is local to the client that drew it.

That is deliberate rather than a limitation. Global markers with fixed names collide: a second aircraft's marker would simply move the first one's. Crew visibility comes from sharing intent and letting each client draw its own map.

Zeus

  • Zeus can place the CARP Computer as an item, and can place or spawn loads — but a spawned vehicle still has to be loaded to be droppable.
  • Teleporting a crew member between aircraft is handled: they adopt whatever CARP state that airframe holds within about a second.

Diagnosing a sync problem

  1. Both need a CARP Computer (or the requirement switched off).
  2. Compare the CREW line on both panels. Same REV means in sync.
  3. Look at system chat. CARP names a version mismatch and warns when the server is not running the mod.
  4. Run testing/mp_carp_diagnostic.sqf in the debug console on both machines and compare the access: and SHARED record lines.

Clone this wiki locally