Combat skill: attacks, raids, defense

Combat exists to move ore. Raiding is how you take another player’s mined ore; attacks soften defenses and kill structs; defense keeps your own ore and infrastructure alive. Raids steal ore. That’s it. Your account is never at risk from raids. The single most important fact: raidability is a live state predicate about the defender’s fleet and Command Ship — not the shield level number. The displayed shield value (e.g. 25–125) only sets raid PoW difficulty (a timer). “Shields are up” does not mean “cannot be raided.” Gate = IsDefenderCommandStructVulnerable() (no owner / no fleet / fleet off-station / no CMD ship / CMD destroyed / CMD offline). Keep your fleet on station with the Command Ship online and you are effectively unraidable; to raid someone, you must catch them with the gate open — or open it by destroying (or power-starving) their Command Ship. Vulnerability is a state you can force, not just one to wait for. (The Command Ship only defends home while the fleet is on station, so sending your fleet away to raid opens your gate until it returns.)

Conventions (TX_FLAGS, -- rule, -D 3 PoW, the per-player charge bar, one-tx-at-a-time) come from conventions.md. Interface: if Structs Desktop MCP is connected, prefer structs_intel (scout, valid_targets, raid_readiness, battle_log) and structs_action/structs_strike for engagements — simulate and strike_options are struct-scoped (there is no planet-raid preflight simulator). Use raid_readiness {only_gaps:true} before combat to find READY/PARTIAL/BLIND ambit coverage, and battle_log {category:"all"} when you need all planet activity rather than only struct_attack. The structsd commands below are the complete fallback.

When to use it

• You spotted a target with stored ore and want to raid it.
• You’re under attack or expect to be (a refine window, a hostile fleet nearby).
• You need to kill a specific enemy struct (a generator, a defender, a Tank).
• You’re setting up standing defense for your planet.

Decisions

Two ways to raid: opportunistic vs siege

Shield-vulnerability is a state you can create, not just one you wait for. This is the most-missed idea in raiding. There are two modes:

• Opportunistic — the defender is already vulnerable when you scout (fleet off-station, or Command Ship already offline/destroyed/absent). Move in and grind. Cheap, but truly-vulnerable ore-holders are rare.
• Siege (force vulnerability) — the defender is shielded (Command Ship online, fleet on station). You manufacture the window: move in, strip same-ambit blockers, destroy their Command Ship, then complete before they rebuild. “Their Command Ship is online” is not a dead end — it is the thing you go and break.

An online Command Ship should trigger the question “can I destroy it?”, not “next target.” See the siege procedure below.

Idle is not vulnerable (and the fleet-move trap)

A dormant owner (idle for days) is not a vulnerable one. Powered structs stay online with no player action, so an idle owner’s Command Ship keeps defending indefinitely — the opportunistic gate stays shut. Never infer raidability from an inactivity signal or a UI “vulnerable”/”inactive” badge (those are derived from activity, not the live shield predicate). Confirm the live state: Command Ship online + fleet on station.

The trap this avoids is real and strictly-negative: moving your fleet to a not-yet-vulnerable target drops your own shields (fleet off-station) and exposes your stored ore, for a raid that can never complete. If you move your fleet, commit to the siege, not just the move. (The upside: a dormant owner who holds ore and won’t rebuild is the best siege target — the window you force open stays open.)

Raid go/no-go (the most important decision)

Use scripts/scout.sh [planet-id] for a structured read, then decide by mode:

1. Is there ore to take? — defender player storedOre > 0 (StoredOreAttributeId on the player object; do not read the planet’s buriedOre). A successful raid seizes all of it at MsgPlanetRaidComplete (atomic; no partial loot). No ore → no raid, in either mode.
2. Is the raidability gate open right now? — fleet off-station, or Command Ship offline/destroyed/absent. This is not the displayed shield number.
   • Yes → opportunistic go. Confirm you out-damage the defenders within the window, blockStartRaid != 0, and the shield PoW is feasible (base 25, +online defense-struct contributions — that number is a timer, not the gate).
   • No (Command Ship online, fleet on station) → siege decision. Can you reach and destroy their Command Ship (6 HP, usually defended), and is the ore worth leaving your own home exposed while your fleet is away? A dormant defender who won’t rebuild tips this toward go; a watchful, well-defended one tips it toward wait/watch.
3. Will you survive the resolution and the window? — your fleet must out-damage the defense, and (for a siege) kill the Command Ship before an active defender rebuilds it.

There is no planet-raid simulator (simulate/strike_options are struct-scoped). Run the three reads — player storedOre, the gate, blockStartRaid — per candidate. Do not declare the network empty from a partial sample.

When NOT to raid: no/low stored ore; a shield so high the PoW outlasts your window; a well-defended Command Ship guarded by a bloc that will retaliate for less ore than you’d lose; or you cannot reach the Command Ship’s ambit. Raiding is an expedition — it costs you a fleet locked away and your home undefended by fleet. Expected ore must beat that cost. An honest no-go (or “watch and wait”) is a win, not a failure.

Defense doctrine

• Keep your Command Ship online and your fleet on station — always. That combination makes you unraidable. Most “I got raided” stories are “my CMD ship went offline (usually power) and I didn’t notice” — or “I sent my fleet off to raid and left my own shields down.” Watch for it (scripts/watch-defense.mjs alerts on your CMD ship dropping and on raids against you). Treat raiding with your own fleet as a deliberate trade: while it’s away, your home is exposed.
• Stack shields. Orbital Shield Generator and Ore Bunker are unlimited — build several to push raid difficulty up as a second layer behind the CMD-ship gate. Mid-raid: do not start a new refine (~34h); only finish one already completable — see under-attack.
• Refine fast. Defense protects structs, never ore. The only defense for ore is turning it into Alpha Matter (structs-production).
• Assign defenders across ambits to protect the Command Ship and key structs.

Desktop autonomous-combat controls

Current Desktop schemas are intentionally small:

• autoresponse: enabled, autonomy, interval_secs, max_shots_per_hour, include_primary_shooters, now. It restores/recalls the defender’s fleet and fires co-located shooters; the rolling hourly ceiling is the only shot cap.
• autoraid: enabled, autonomy, posture, interval_secs, min_ore, min_score, give_up_after_mins, max_concurrent_raids, target_cooldown_mins, w_ore, w_opening, w_weakness, w_grudge, now. cautious uses open windows only; opportunist and aggressive may siege.

Legacy response modes/per-incident caps, time windows, mid-raid refining, and separate vulnerability/siege gates are not current controls. Evaluate loops with autonomy:"advise"; preview-only strike planning is separate. Mid-raid refine is paused by chain v0.21.0, so response hardening recalls/restores the fleet instead.

Decisions live in playbooks/situations/under-attack, guild-war, and playbooks/meta/counter-strategies.

How a raid resolves

blockStartRaid is the defender’s vulnerability clock, and raid PoW age is measured from it:

• It starts when the raidability gate opens — their Command Ship goes offline or their fleet leaves station (or when you arrive to find it already open).
• It resets to 0 if the defender closes the gate (Command Ship back online with the fleet on station) — and completion is rejected (raid_clock_unset when 0; the raid status flips to ongoing with the gate closed).
• Raid statuses you’ll see: initiated → shieldsVulnerable (gate open, clock running, winnable) → raidSuccessful / attackerRetreated. attackerDefeated means your raiding Command Ship was destroyed while away. demilitarized means no defenders to resolve against.

The clock only runs while your raider is present at the target — it is set at arrival if the defender is already vulnerable (opportunistic), or the moment their Command Ship drops while you’re there (siege). So a raid is a race against the defender noticing and restoring the gate. Scout the CMD ship and fleet position first. For an opportunistic raid, don’t move your fleet until the gate is already open; for a siege, moving in is step one and you open it yourself.

A raid steals ore. A successful raid seizes all of the defender’s storedOre (StoredOreAttributeId on the player) and nothing more — it does not destroy the player or their structs. Settlement is atomic at MsgPlanetRaidComplete; there is no partial loot and no refund. Killing the defender’s Command Ship opens the shieldsVulnerable window so the raid can complete; if the defender restores or rebuilds it before you finish, completion is rejected (shields_active) and you get nothing. Beware the reverse: trigger_raid_defeat_by_destruction is on the Command Ship, so if your raiding CMD ship is destroyed while away, your fleet is defeated (attackerDefeated) and sent home. Win path for ore: strip same-ambit blockers → destroy the defender’s CMD ship → complete the raid before they rebuild it (most reliable vs an offline defender).

Procedure — opportunistic raid (defender already vulnerable)

1. Scout — scripts/scout.sh [planet-id] (or structsd query structs planet [id] + player + struct queries). Confirm the go conditions above: player storedOre, Command Ship status (offline/destroyed/absent or fleet off-station), and blockStartRaid. Do not treat the planet’s buried ore or the shield number as the loot or the gate.
2. Optional stealth — stealth a unit before approach (struct-stealth-activate, 2 charge); attacking later auto-drops it.
3. Move fleet to the target (instant). Your fleet (and your Command Ship) is now away; you can’t build/mine at home while away, and your own planet’s shields are now vulnerable until the fleet returns — refine your home ore before you leave.

   structsd tx structs fleet-move TX_FLAGS -- [fleet-id] [destination-location-id]
   

4. Approval Block — fleet is your raider and now at the target; defender’s CMD ship is down (verified); your home ore is refined or below your theft tolerance; you accept an auto-submitted completion landing minutes-to-hours out.
5. Raid compute (expedition, auto-submits completion — the documented -y exception):

   nohup structsd tx structs planet-raid-compute -D 3 --from [key] --gas auto --gas-adjustment 1.5 -y -- [fleet-id] \
     > memory/jobs/raid-[fleet-id].log 2>&1 & echo $! > memory/jobs/raid-[fleet-id].pid
   

6. Move fleet home and refine the stolen ore immediately — it’s stealable in your hands now too.

If the defender restores their Command Ship mid-raid, the clock resets — withdraw or wait for it to drop again.

Procedure — siege raid (force the window open)

Use this when the target holds ore but is shielded (Command Ship online, fleet on station) — the case an opportunistic raid can’t touch. It costs a fleet engagement and leaves your home exposed, so run the go/no-go above first. Best against a dormant defender who won’t rebuild.

1. Scout the Command Ship’s ambit and defenders — scripts/scout.sh [planet-id] surfaces the defender’s Command Ship id and status; query it directly with structsd query structs struct [commandStruct-id] for its operatingAmbit. To enumerate the same-ambit structs that can block for it, use the Guild Stack (“defenders by planet” — there is no structsd CLI command that lists a planet’s structs). Confirm you have weapons that reach the Command Ship’s ambit.
2. Refine your own ore and move your fleet to the target. Your home shields drop while away — accept that exposure as the cost of the siege. A planet holds one visiting fleet by default; if the slot is taken, fleet-move is queue_full.

   structsd tx structs fleet-move TX_FLAGS -- [fleet-id] [destination-location-id]
   

   At this point planet-raid-compute will still reject (no active raid window) — that is expected; the window isn’t open yet.

3. Strip same-ambit blockers, then destroy the Command Ship with struct-attack (space repeated attacks; the charge bar is per-player and doesn’t bank — coordinate multiple accounts to focus-fire if you have them). Destroying it fires the chain’s vulnerability hook and opens shieldsVulnerable with your raider present.

   structsd tx structs struct-attack TX_FLAGS -- [operating-struct-id] [target-id] [weapon-system]
   

4. Verify the window is open — structsd query structs planet [planet-id] shows blockStartRaid != 0 (raid status shieldsVulnerable). Only now is compute worthwhile.
5. Raid compute (same command as opportunistic step 5), then move home and refine the seized ore immediately.

Watch for the defender rebuilding the Command Ship (an active defender will) — if it comes back online with the fleet on station before your proof lands, the clock resets and completion fails. Never let your raiding Command Ship die while away (attackerDefeated).

For Desktop structs_hash start, RAID and BUILD require the real block_start; the hasher refuses to guess because a current-block anchor always produces a chain-rejected proof. MINE/REFINE may omit it: Desktop resolves the struct’s planet and reads the shared planet ore clock.

Procedure — direct attack

Scout the target’s ambit and defense type, position (Command Ship only) into range, then fire. The attack needs only the attacking struct and its owner online — your Command Ship does not need to be online to attack, change defenders, or change stealth. The target must be a built struct: a struct that is still building cannot be attacked (unbuilt), and a destroyed one is rejected (destroyed); the target’s online status is irrelevant. The CLI prompts; verify target IDs and that you aren’t crossing guild lines you didn’t intend to (attacking another guild’s structs is a Tier 2 act of war). Note most weapons are single-target (primaryWeaponTargets = 1) — the comma list only spreads damage for weapons whose target count is > 1.

Planner false-negative fallback. structs_strike and structs_intel {query:"strike_options"} are advisers, not chain authority. A 2026-09-24 playtest saw both report “no reach” while an online, land-operating Mobile Artillery was co-located with a land Command Ship; the direct attack succeeded. Before accepting an “unreachable” verdict, refresh the raw attacker, target, and fleet records and independently confirm:

1. attacker is built, online, not destroyed, and its owner is online;
2. attacker and target resolve to the same planet (a fleet struct’s locationId is a fleet id, so follow that fleet’s locationId to the planet);
3. the selected weapon’s reach bitmask includes the target’s current operatingAmbit;
4. target is built, not destroyed, and not hidden from that attacker.

If all four hold, the planner refusal is a Desktop bug or stale-cache result, not proof that the chain will reject. Use the ordinary struct-attack action/preflight and let the chain arbitrate; record the planner output plus the fresh raw reads for a bug report. This fallback does not waive normal approval or rules of engagement.

structsd tx structs struct-attack TX_FLAGS -- [operating-struct-id] [target-id,target-id2,...] [weapon-system]

Attacks cost 3-5 charge from your per-player bar; space repeated attacks accordingly.

Procedure — defense setup

structsd tx structs struct-defense-set TX_FLAGS -- [defender-struct-id] [protected-struct-id]
structsd tx structs struct-defense-clear TX_FLAGS -- [defender-struct-id]

Only fleet structs can be assigned as a defender (canDefend: true; 1 charge each; stagger ~6 s on one key) as long as the defender is built, online, and co-located with the protected struct — ambit is not required to assign. Planetary types (Ore Extractor, Refinery, Ore Bunker, PDC, generators, …) are rejected. Ambit decides what the defender can do: same-ambit is required only to block (intercept a hit), while a cross-ambit defender still counters whenever its weapon can reach the attacker. Spread fleet defenders across ambits for counter coverage; keep same-ambit defenders where you need real interception. Minimum viable defense: at least one combat struct per ambit guarding the Command Ship (6 HP; most fleet structs are 3 HP).

Tactical reference

Targeting (which struct hits which ambit)

The Command Ship is the only struct that can change ambits (struct-move); it attacks only its current ambit. Reposition it into range to attack, or out of range to hide.

Weapon control vs defense (evasion + armour-piercing)

Use unguided vs Signal Jamming, guided vs Defensive Maneuver. Armour reduces damage by 1 — except against armour-piercing weapons (the Battleship primary), which ignore it. The Battleship is the dedicated answer to Tanks and to the (now armoured) power generators. Minimum damage after reduction is always 1.

Combat resolution notes

• Counters are ambit-gated, blocks are ambit-matched. A defender counters whenever its weapon can reach the attacker’s ambit (regardless of what it’s defending); it can only block when it shares the target’s ambit. Consequence: attacking land structs from air/water/space (an ambit the defenders can’t reach) takes zero counter damage — the single biggest combat lever. Pick your attacking ambit to dodge counters.
• Each struct counters at most once per struct-attack invocation (not per target/shot). Defender counter fires before block and even on evaded shots; target counter fires after all shots (destroyed targets can’t counter).
• Block only fires on non-evaded shots and only from a defender in the target’s ambit.
• Counters are a backstop, not a damage plan — counter values are small (typically 1; Command Ship 2) and a cross-ambit attacker takes none at all. Win with active struct-attack volleys from a safe ambit, not by baiting counters.
• Single-target: every weapon has primaryWeaponTargets = 1 (one struct per volley) — no multi-target weapon exists. The comma-list in struct-attack doesn’t make a single-target weapon spread.
• No charge banking: any action resets your shared charge bar to 0 and it refills ~1/block — you cannot stockpile for a multi-attack burst. Plan combat as spaced single actions. Because the bar is per-player, the way to land many hits at once is parallel: coordinate multiple accounts to focus-fire one target — N players land N attacks per charge cycle. See team-operations.
• Planetary defenses (attacking a planet): the Jamming Satellite runs a low-orbit ballistic interceptor network that can evade your guided ordnance against planetary structs on their own planet — regardless of ambit (evadedByPlanetaryDefenses). Ambit no longer matters and unguided ordnance passes through untouched, so bring unguided weapons against a planet with interceptors, or expect 0s from guided fire. This is on top of any unit-level signalJamming the target itself carries (both layers stack against guided). The PDC and the interceptor network are the planetary defenses that affect combat.
• PDC auto-fires after all targets resolve (it does not counter); multiple players’ PDCs stack.
• A successful raid seizes all of the defender’s storedOre and nothing else — there is no player-elimination outcome (see raid section). Destroyed structs are gone forever but can be rebuilt (full PoW). Losing your Command Ship disables the whole fleet until you build a new one — protect it above all, and never let your raiding CMD ship die while away (attackerDefeated).

Commands reference

Raid flow: scout → (CMD ship down?) → fleet-move → raid-compute → fleet-move home → refine. planet-raid-compute is the documented -y exception; your Approval Block is the gate. planet-raid-complete does not consume charge.

Requires: structsd on PATH and a signing key.

Verification

• structsd query structs fleet [id] — location and onStation/away.
• After a raid: your storedOre rose (refine it). For the exact grams seized, the authoritative source is ledger rows with action = 'seized', not planet_raid.seized_ore — the ledger even records 0-gram seizures (a raid that reached the planet but took nothing, e.g. a repelled probe). See database-schema.md — planet_raid.
• A raidSuccessful event plus the ore ledger/state delta proves settlement. Do not require a Desktop tx_settled row for an auto-submitted raid proof: that synthetic receipt is produced by the MCP action bridge, and PoW completions can bypass it. To recover the completion tx hash, query Tendermint/Cosmos transactions at the raid-success block and select the tx carrying EventHashSuccess(category=raid, objectId=[fleet-id], planetId=[planet-id]) plus EventRaid(status=raidSuccessful). See chain-events — recovering a PoW completion hash.
• After attacks: events include remaining-health values — use them to assess damage.
• Broadcast ≠ success: a raid can land but resolve as defeat/ongoing. Query the raid status.

Errors

• “shields are not vulnerable: no active raid window (defending Command Ship may still be online)” — the CLI-side planet-raid-compute pre-check when blockStartRaid == 0. This is the message you usually hit first. It does not mean “grind harder”: the defender is shielded. Either wait/watch for them to slip (opportunistic), or open the window yourself by destroying their Command Ship with your fleet present (siege procedure above).
• “cannot raid_complete while shields_active” / raid rejected — the chain-side planet-raid-complete rejection: the defender is not vulnerable at completion (fleet on station with the Command Ship online). You cannot win until they’re vulnerable again — force it or wait.
• “cannot raid_complete while raid_clock_unset” — blockStartRaid is 0 (no live raid window). Get your fleet to the target and make the defender vulnerable (their CMD ship offline/destroyed, or fleet off-station) before computing.
• “unbuilt” / “destroyed” (attack) — the target struct isn’t a valid combat target: it’s still building or already destroyed. Pick a built target.
• “unreachable” / “out_of_range” — your weapon can’t reach that ambit; reposition the Command Ship or use a different struct.
• “fleet not away” — move the fleet to the target first.
• “insufficient charge” — per-player bar too low; wait (see conventions).
• “queue_full” — the destination planet already has its visiting-fleet cap (1 + locationListExtra, default 1). Wait for the parked fleet to leave, or pick another target.
• “cannot defend” / StructCannotDefend — you tried to assign a planetary struct as a defender. Only fleet types (canDefend: true) work.
• “under_raid” — mine/refine is paused while a visitor heads the queue. Do not retry those computes until they leave.

See also

• knowledge/mechanics/combat — damage, evasion, raid phases, SHIELDS_VULNERABLE
• knowledge/mechanics/defense — raid loot limits, shield vulnerability, minimum posture
• knowledge/mechanics/fleet — fleet status, raid window
• playbooks/situations/under-attack / guild-war / counter-strategies
• structs-intel — scouting + raid-worthiness scoring; structs-production — refine to protect ore