Cargo and docking

How the server tells clients who is carrying what, how pad docking opens the service screens, and which cargo rules come from the original client versus recollection or server policy.

0x29 CARRYING_INFO

Announces that a player picked up or dropped cargo. The client handler at 0x00476330 updates its roster entry and, separately, the local HUD. It has no timestamp guard, so the latest packet always wins. recovered

player u32 · +0

carrying u8 · +4

team u8 · +5

item u8 · +6

Body offsets, excluding the opcode and transport envelope. Multi-byte values are big-endian.

offset	field	type	meaning
+0	player	u32	Player whose carrying state changed.
+4	carrying	u8	Whether the player now carries cargo.
+5	team	u8	Team field shown with the cargo.
+6	item	u8	Cargo item code; see item codes.

Item codes

The client maps item codes 0–11 to unit types 25–36 through 0x004E4B00. Any other value maps to sentinel type 39. Item 13 is not a deployable item: the client displays it as enemy cargo, locked. recovered

Note

Our server sends item 13 to observers on the other team, with the carrier’s team in the team field. Whether this matches what original players saw has not been tested yet. policy

0x38 DOCKING

Puts the local vehicle into or out of pad docking. The handler at 0x0046EC50 has no stale-packet guard. recovered

timestamp u32 · +0

target u32 · +4

flag u8 · +8

offset	field	type	meaning
+0	timestamp	u32	Stored as a barrier when docking is set.
+4	target	u32	Pad unit type: 26 opens refuel and inventory, 27 opens repair. A missing target docks without a pad screen.
+8	flag	u8	Set or clear docking.

How docking clears

• Setting docking (0x00446381) stores the target and the timestamp barrier.
• An explicit clear (0x004463A2) does not update the barrier.
• Otherwise docking only clears (0x0047D3FE) on a non-hard local entity update strictly newer than the barrier. Equal-time or hard snapshots keep the vehicle docked.

Our server docks on the ground with target −1. That fits this receiver behavior but doesn’t prove what the official server sent. policy

Server rules

The client can’t tell us everything the official server enforced. These rules come from other sources and are labeled accordingly.

• testimonyStolen cargo stays locked until the carrier lands on a friendly repair pad.
• testimonyCarried cargo drops when the carrier dies in combat, and either team can recover it.
• testimonyWeapons cannot damage an uplink.
• testimonyA stolen uplink self-destructs 10 minutes after the theft unless its own team gets it back, which cancels the countdown. Not implemented yet.

Uplink self-destruct timer

source	value	label	notes
recollection	10 min	testimony	baffler’s memory of the official servers.
older Rust server	600 s	policy	uplink_capture_self_destruct_seconds, with a 180 s reminder.
Wulfram 1.0 params	780	W1 lead	uplink_detonation_time; units unknown, and not Wulfram II evidence.

Open questions

• What counts as stolen (pickup or landing), and what recovery cancels the countdown?
• Reminder messages, blast damage and radius, and what happens to a carrier when the timer expires.
• Whether the client has self-destruct HUD strings or sounds, which would pin down the behavior.
• Cargo placement, disconnect and team-change outcomes.