On this page
- Key facts in 30 seconds
- Storage cap formula
- Cap enforcement
- Time-to-cap planning
- Reduction vs Conversion at cap pressure
- Failure modes (wiki/03)
- Exact OverflowFactor value?
- If I go offline 24 hours with full storage — what happens?
- What % does the attacker take?
- Is rounding drift serious?
- Reduction vs Conversion — which to pick?
- For min-maxers
- Quick citation reference
- What to read next
Key facts in 30 seconds
- CapEffective = StorageBase × StorageBonuses × OverflowFactor (all three are server-configured)
- Cap enforcement at every production tick — overflow above cap is discarded
- time_to_cap = (cap − current) / net_perhour — plan before offline windows
- Offline burst clipping: large DeltaT → large gain → immediate cap clamp
- Conversion vs reduction: at cap pressure, lower sliders beats conversion with loss
Storage cap formula
Storage cap in Xterium uses three multipliers (wiki/03):
CapEffective = StorageBase × StorageBonuses × OverflowFactor| Component | Meaning |
|---|---|
| StorageBase | Base cap от уровня storage building |
| StorageBonuses | Multiplicative модификаторы (tech, premium, events) |
| OverflowFactor | Глобальный overflow multiplier (server-configured) |
| CapEffective | Финальный ceiling — clamp(stock + gain, 0, CapEffective) |
Concrete values for each component (StorageBase per level, StorageBonuses from tech/premium, OverflowFactor server constant) — server-configured. We don't cite exact numbers without verification.
Cap enforcement
Every production tick (see resource-production-formula):
Stock_r = clamp(Stock_r + Gain_r, 0, CapEffective)If Gain exceeds remaining capacity — excess is discarded. Happens both online and during offline burst. Longer offline = larger DeltaT = larger Gain = more likely to clip.
Time-to-cap planning
time_to_cap_r = (storage_cap_r − current_stock_r) / max(1, net_perhour_r)
effective_realized_gain_r = min(raw_gain_over_window_r, remaining_capacity_r)Example: Crystal cap = 5,000,000, current = 4,400,000, net_perhour = 120,000.
- time_to_cap = (5,000,000 − 4,400,000) / 120,000 = 5 hours
- If offline 10 hours: ~5 hours' worth gets clipped
If time_to_cap < expected_offline_window — plan: raise storage level BEFORE leaving, or spend on queue, or lower sliders.
Reduction vs Conversion at cap pressure
Wiki/03 gives a clear decision:
Reduction (lower sliders) — better when near-term problem = cap waste (storage about to fill offline).
Conversion (exchange/sell) — better when bottleneck = build queue mix (e.g. metal-heavy backlog needs crystal).
Concretely:
WastedIfNoReduction_r = max(0, RawGainWindow_r − RemainingCapacity_r)
SavedByReduction_r = min(WastedIfNoReduction_r, RawGainWindow_r × ReductionPct)If crystal RawGainWindow = 900,000 and RemainingCapacity = 300,000 → WastedIfNoReduction = 600,000. Reduction slider 50% over that window: SavedByReduction = 450,000. Conversion with 25% loss must beat those 450k preserved crystal-equivalent to be better.
Failure modes (wiki/03)
- Overflow cap: excess production above cap discarded at clamp
- Rounding drift: repeated round() across many ticks → micro gain/loss
- Offline burst clipping: large DeltaT → large gain → immediate clipped
- Queue race perception: simultaneous actions may look inconsistent
Exact OverflowFactor value?
Server constant — universe-dependent. Wiki/03 doesn't cite a specific number. On standard WoA servers usually ≥ 1.0 (overflow allowed above nominal cap). Check in-game UI of storage building for your universe.
If I go offline 24 hours with full storage — what happens?
Production continues, but at the next trigger (your login) DeltaT calculation clamps gain to CapEffective. Some production is lost — that's overflow clipping. To avoid: raise storage level BEFORE leaving OR lower sliders.
What % does the attacker take?
This percentage is NOT documented in wiki/03 — combat loot logic lives in the combat system. This article deliberately does NOT cite «50%» without a verified source. Wait for a separate combat-loot article after wiki/07 or wiki/11 verify.
Is rounding drift serious?
No — per-tick round() creates a tiny cumulative drift around fractional boundaries. At scale you lose single units or dozens out of millions — not critical.
Reduction vs Conversion — which to pick?
Depends on bottleneck. Cap waste (storage about to fill) → reduction (lower sliders). Build queue mix (need another resource) → conversion (but factor exchange loss).
For min-maxers
Wiki/03 formulas. Player TL;DR: «cap = base × bonuses × overflow; offline with full storage → lost production».
Sources:
includes/pages/game/class.ShowResourcesPage.php— storage display and summary- Production tick reconciliation reuses Max × OverflowFactor clamp (wiki/10 cross-reference)
Important: exact values of OverflowFactor and StorageBonuses are universe-config dependent. On standard WoA servers OverflowFactor typically ≥ 1.0 (overflow allowed above nominal cap). For your universe's specific value, check in-game storage building UI.
Combat loot: the raid-time resource capture formula is NOT documented in wiki/03 (combat-mechanics module). This article deliberately does NOT cite «50% loot» as a universal constant. For exact loot numbers see wiki/07_Combat_System.md or wiki/11_Multiplayer_Interaction.md (separate article when verified).
Quick citation reference
Source: wiki/03_Resources_and_Economy.md. Formula: CapEffective = StorageBase × StorageBonuses × OverflowFactor. Cap enforcement: every production tick (lazy reconciliation). Failure modes: overflow clip, rounding drift, offline burst clipping. Combat loot %: NOT verified in wiki/03 — separate article after wiki/07 or wiki/11 verify. Last verified: 2026-05-22 (wiki/03).
