Here's a full cycle, idle to depletion:

https://youtu.be/iOcMrlmxFsw

The five layers I keep talking about

When I say "the mining loop", I mean a chain that threads spec → server → protocol → bridge → client. I'm going to refer to these by name through the rest of the post, so quickly:

• spec: my source of truth for cycle length, range, yield per tick, and what I count as a valid target.

• server: authoritative state. I keep the cycle, the asteroid's remaining ore, and the pilot's cargo here.

• protocol: the wire format the server and the client both compile against. Same crate, no drift.

• bridge: the boundary I use to translate server intent into client messages and back.

• client: input, rendering, and the small bits of optimistic state I use to make the game feel responsive.

The path I've verified

What I can do right now, end to end:

1. I target an asteroid and pick the mining laser from the hotbar.

2. The server validates: target exists, in mining-laser range (5km), laser fitted, capacitor has headroom.

3. The cycle starts. S_MINING_CYCLE_PROGRESS streams from server to client.

4. Each completed cycle adds ore to my hold server-side.

5. The 3D beam fires between my ship's hardpoint and the asteroid.

6. When the cycle ends, for any reason, S_MINING_STOPPED carries a typed reason byte back.

7. If the asteroid's ore hits zero, it despawns. The field replenishes per spec.

The beam is doing something a little weird

I want to be honest about how the beam actually works, because I'm not totally sure I love it.

When I click mine, the beam appears immediately. The client flips is_mining = true and starts rendering the beam before the server has confirmed anything. The server then sustains it via cycle-progress messages, and S_MINING_STOPPED is what kills it. If the server rejects my action, mining_stopped lands within a frame or two and clears the optimistic beam.

There's no beam opcode. I recompute the geometry (muzzle hardpoint to target position) client-side every render frame in player_ship.gd:_update_mining_beam. The server never sends beam coordinates.

So the precise framing for what I built: the beam is a pure client-side visual, shown optimistically on the player's own click, sustained by server cycle-progress, and extinguished by an authoritative stop reason. The server governs mining state. The client owns the line and redraws it itself.

I went back and forth on this. The argument for it: the player gets instant feedback on their own click, and a rejection lands fast enough that the desync window is invisible in practice. The argument against: a desync window exists, however small, and "invisible in practice" is the kind of phrase that ages badly under real network conditions. For now I'm leaving the optimistic version in because it feels right, but I want to revisit it once I get latency under real co-op load. idk if this is the shape it ends up in.

Typed stop reasons

Every cycle I run ends for a specific reason, and I made that reason a typed enum on the wire instead of a string:

#[derive(Debug, Clone, Copy, PartialEq, Eq)]
#[repr(u8)]
pub enum MiningStopReason {
    Manual = 0,      // pilot manually stopped the cycle
    OutOfRange = 1,  // target drifted outside mining range
    Capacitor = 2,   // insufficient cap to keep cycling
    HoldFull = 3,    // ore hold reached capacity
    Destroyed = 4,   // asteroid depleted, no longer a valid target
    NoLaser = 5,     // no mining laser fitted (or it vanished)
}

A generic "mining stopped" line in my logs is a bug magnet. I can't tell from it whether the player flew out of range, the asteroid emptied, the cap drained, or the cargohold filled up. Named variants make every cycle's tail inspectable. When I scale this loop to fleets and combat-site interrupts, I want to grep for HoldFull vs OutOfRange without parsing prose.

How well-tested is this, honestly

Not very, lol. The mining loop is lightly tested compared to the rest of what I've built so far.

• 3 tests I have directly on systems/mining.rs: asteroid_depletes_after_its_stock_runs_out, no_laser_fitted_stops_with_no_laser_reason, non_ferrite_ore_flows_from_asteroid_to_event_and_hold.

• +1 data-validation guard (runtime_warnings_flag_missing_mining_effect) that fails my build if the mining effect data isn't wired.

• +7 on the refining side that consume mined ore, ore-to-mineral conversion.

So I've got about 3 tests directly on the mining loop, plus another 7 covering the refining path the ore feeds into. My combat code has 21 tests. Warp has 11. Mining isn't where I've put the test density, and I'd be flattering it if I said "the loop is covered". It works because the loop is short and the failure modes all live on typed MiningStopReason paths, but I want a lot more tests here before I trust it under real network strain.

The crack I haven't fixed: the cargohold gauge

S_CARGO_UPDATE exists in my protocol. The client decodes it. The constant is defined. But the server never emits it, and the bridge explicitly drops it on the floor, so the hold count in the UI gets reconstructed one ore at a time from MiningCycleCompleted.total_in_cargo (player_state.gd:310-313).

What that means in practice:

• On the happy path, the gauge is right. The per-cycle total comes back authoritatively each tick.

• Mid-cycle there's no whole-hold resync, so the "cargo full" toast I have in spec can't fire from a CargoUpdate. I have to infer it from HoldFull.

• If anything mutates the hold outside a mining cycle and the client misses the event, my gauge drifts until the next authoritative snapshot.

I don't think of this as its own bug. It's part of a cluster. I have about 14 server opcodes in the same shape: client-side decoder exists, no server-side emitter, the bridge silently swallows whatever the protocol said it could carry. The decoder for S_CARGO_UPDATE has been waiting for its emitter since day one.

So the credible fix isn't a one-line patch for cargo specifically. It's doing the whole decoder-without-emitter class at once, and I'd rather not promise that for Devlog 2. Bundling it into a single subsystem post would either rush the cleanup or pad the post. For now I'm naming the crack, bounding it, and leaving it on the list.

Next week

I'm doing the combat cascade: shields, armor, hull, resists, module cycling, lock hysteresis, the death-to-respawn flow. Same teardown as this one, what I've verified and what's still cracked. Combat is where I've actually put the test density (21), so the honesty knob points the other way. The question stops being "did I test this enough" and starts being "why isn't the player seeing most of what my cascade does". That's the post.

Anyway, this is probably the most identifier-dense thing I'll write all month. The next ones get more pictures.