Economy

Astra upkeep and starvation

confirmedPatch 11.75Build a7b5c7cCore rulesReviewed
Patch
11.75
Build
a7b5c7c
Scope
Core rules
Reviewed

Astra supports construction and stationed fleets. A colony whose stationed upkeep exceeds its Astra supply can begin losing garrisoned ships. Evidence

The safe operating rule is to use the live hourly trend: estimate the runway from current Astra and the displayed net drain, then include incoming or departing reinforcements before relying on that colony.

Upkeep modifiers and starvation timing can vary with the current roster, structures, SPUs, and world settings. This wiki therefore does not publish a universal loss interval. Confirm the destination’s Astra runway before reinforcing an ally. Evidence

Reading the runway

The resource panel provides the three inputs that matter: current Astra, its capacity, and the present hourly trend. A negative trend is not automatically a crisis; it becomes one when the remaining amount cannot cover the time until the next shipment, fleet departure, or other change in demand.

Reinforcement check

Before sending ships to an ally, ask for the destination’s current Astra amount and trend, then have the recipient preview the state after the reinforcement is stationed. Ships that arrive safely but create an unsustainable garrison have not solved the defensive problem.

Recovery options

Reduce stationed demand, increase or redirect Astra supply, arrange a shipment, or shorten the period the fleet must remain. Exact attrition timing is intentionally omitted because the current roster and world settings can alter the result. Evidence

Recovery sequence

  1. Reopen the affected colony and record current Astra, capacity, and hourly trend.
  2. Identify newly stationed or returning fleets that changed demand.
  3. Check incoming supply and the time until it arrives.
  4. Compare that arrival with the displayed runway; do not rely on a remembered balance.
  5. Reduce stationed demand or increase supply before beginning optional construction.
  6. Reopen the resource panel after each major change and confirm that the trend moved as expected.

Common mistakes

  • Treating capacity as production: a larger Astra cap does not itself correct a negative hourly trend.
  • Sending more defenders without checking the destination’s demand.
  • Counting an incoming shipment as already available.
  • Assuming a loss interval copied from another world is current.
  • Starting another Astra-consuming commitment during recovery without rereading the trend.

Needs verification

The exact ordering of ship losses, grace periods, and any world-specific starvation modifier requires current runtime evidence. A useful capture includes the colony’s Astra panel, full stationed roster, active modifiers, world, build, and timestamps before and after the transition.

Evidence

Sanitized transcripts from the current client. Raw player captures remain private.

  1. Installed client identityThe installed Windows client reports patch 11.75, build a7b5c7c, built 2026-07-31 15:16:13 UTC.Patch 11.75 · build a7b5c7c · verified 2026-08-01 · Riftborne.exe --build-info and Content/build_info.json.
  2. Current economy and storage implementationProduction, storage capacity, upkeep, hidden-resource, and transmutation behavior is taken from the executable paths used by the running client.Patch 11.75 · build a7b5c7c · verified 2026-07-30 · Read-only inspection of BuildingConfig and EconomySystem.
  3. Current fleet and movement implementationFleet role, movement, infrastructure, and roster statements are limited to behavior exposed by the current client implementation and Codex.Patch 11.75 · build a7b5c7c · verified 2026-07-30 · Read-only inspection of ShipTravelSpeedSystem, ShipInfrastructureSystem, and Codex ship screens.
  4. Installed 11.75 data tablesDirective and SPU tables were read from the same installed 11.75 build. Values are used only where the current table exposes them directly.Patch 11.75 · build a7b5c7c · verified 2026-07-30 · Content/Data/directive_paths.csv and Content/Data/spu_bonuses.csv.
  5. Active multiplayer-world boundaryThe multiplayer operator owns the world seed, pacing, simulation time, factions, global modifiers, and ship roster. World-specific values must therefore be labeled separately from core rules.Patch 11.75 · build a7b5c7c · verified 2026-07-30 · Current multiplayer client contract and read-only world/session telemetry.