На этой странице
- Главное за 30 секунд
- Формула storage cap
- Cap enforcement
- Time-to-cap планирование
- Reduction vs Conversion — что выбрать при cap-pressure
- Failure modes (wiki/03)
- Какое точное значение OverflowFactor?
- Если уйду в оффлайн на 24 часа с full storage — что произойдёт?
- Сколько % забирает атакующий?
- Rounding drift — это серьёзно?
- Reduction vs Conversion — что выбрать?
- Для технически подкованных
- Краткая справка для цитирования
- Что почитать дальше
Главное за 30 секунд
- CapEffective = StorageBase × StorageBonuses × OverflowFactor (все три множителя серверные)
- Cap enforcement на каждый production tick — overflow выше cap отбрасывается
- Time-to-cap = (cap − current) / net_perhour — план перед оффлайн-окнами
- Offline burst clipping: большой DeltaT → большой gain → cap clamp немедленно
- Conversion vs reduction: при cap-pressure лучше снизить sliders чем конвертировать с loss
Формула storage cap
Storage cap в Xterium считается через три множителя (wiki/03):
CapEffective = StorageBase × StorageBonuses × OverflowFactor| Компонент | Что значит |
|---|---|
| StorageBase | Base cap от уровня storage building |
| StorageBonuses | Multiplicative модификаторы (tech, premium, events) |
| OverflowFactor | Глобальный overflow multiplier (server-configured) |
| CapEffective | Финальный ceiling — clamp(stock + gain, 0, CapEffective) |
Конкретные значения каждого компонента (StorageBase по уровню, StorageBonuses от tech/premium, OverflowFactor константа сервера) — серверные настройки. Не цитируем точные числа без проверки.
Cap enforcement
Каждый production tick (см. resource-production-formula):
Stock_r = clamp(Stock_r + Gain_r, 0, CapEffective)Если Gain превышает remaining capacity — excess отбрасывается. Это происходит и при online play, и при offline burst. Длинный offline = большой DeltaT = большой Gain = более вероятно clip.
Time-to-cap планирование
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)Пример: 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 часов
- Если ты offline 10 часов: ~5 часов worth будет clipped
Если time_to_cap < expected_offline_window — спланируй: подними storage уровень ДО выхода, или потрать ресурсы в queue, или пониz sliders.
Reduction vs Conversion — что выбрать при cap-pressure
Wiki/03 предлагает чёткое решение:
Reduction (lower sliders) — лучше когда near-term проблема = cap waste (storage скоро заполнится в offline).
Conversion (exchange/sell) — лучше когда bottleneck = build queue mix (например metal-heavy backlog нуждается в crystal).
Конкретно:
WastedIfNoReduction_r = max(0, RawGainWindow_r − RemainingCapacity_r)
SavedByReduction_r = min(WastedIfNoReduction_r, RawGainWindow_r × ReductionPct)Если crystal RawGainWindow = 900,000 а RemainingCapacity = 300,000 → WastedIfNoReduction = 600,000. Reduction slider на 50% за это окно: SavedByReduction = 450,000. Conversion с 25% loss должна beat эти 450k preserved crystal-equivalent чтобы быть лучше.
Failure modes (wiki/03)
- Overflow cap: excess production выше cap отбрасывается at clamp
- Rounding drift: repeated round() через many ticks → micro gain/loss
- Offline burst clipping: большой DeltaT → большой gain → immediately clipped
- Queue race perception: одновременные actions могут выглядеть inconsistent
Какое точное значение OverflowFactor?
Серверная константа — зависит от вселенной. Wiki/03 не цитирует конкретное число. На стандартных WoA-серверах обычно ≥ 1.0 (overflow разрешён выше nominal cap). Проверяй в in-game UI storage building для своей вселенной.
Если уйду в оффлайн на 24 часа с full storage — что произойдёт?
Производство continues, но при следующем триггере (твой логин) DeltaT-вычисление clamps gain к CapEffective. Часть production будет потеряна — это overflow clipping. Чтобы избежать: подними уровень storage ДО ухода ИЛИ снизь sliders.
Сколько % забирает атакующий?
Этот процент НЕ задокументирован в wiki/03 — combat loot logic в combat-системе. В этой статье мы намеренно не цитируем «50%» без verified источника. Жди отдельную combat-loot статью после verify wiki/07 или wiki/11.
Rounding drift — это серьёзно?
Нет — round() per tick создаёт крошечный cumulative drift около fractional boundaries. На больших масштабах теряются единицы или десятки ресурсов из миллионов — не критично.
Reduction vs Conversion — что выбрать?
Зависит от bottleneck. Cap waste (storage скоро заполнится) → reduction (lower sliders). Build queue mix (нужен другой ресурс) → conversion (но учти exchange loss).
Для технически подкованных
Формулы wiki/03. Игроку достаточно: «cap = base × bonuses × overflow; если уйдёшь в оффлайн с full storage — потеряешь production».
Источники:
includes/pages/game/class.ShowResourcesPage.php— storage display и summary- Production tick reconciliation reuses Max × OverflowFactor clamp (wiki/10 cross-reference)
Важно: точные значения OverflowFactor и StorageBonuses зависят от конфига вселенной. На стандартном WoA-сервере обычно OverflowFactor ≥ 1.0 (overflow allowed выше nominal cap). Но конкретное значение проверяй в in-game UI на странице конкретного storage building.
Combat loot: формула захвата ресурсов при атаке НЕ документирована в wiki/03 (это combat-mechanics модуль). В этой статье мы намеренно НЕ цитируем «50% loot» как универсальную константу. Для точных loot чисел смотри wiki/07_Combat_System.md или wiki/11_Multiplayer_Interaction.md (отдельная статья будет когда verified).
Краткая справка для цитирования
Источник: wiki/03_Resources_and_Economy.md. Формула: CapEffective = StorageBase × StorageBonuses × OverflowFactor. Cap enforcement: каждый production tick (lazy reconciliation). Failure modes: overflow clip, rounding drift, offline burst clipping. Combat loot %: НЕ verified в wiki/03 — отдельная статья после wiki/07 или wiki/11 verify. Last verified: 2026-05-22 (wiki/03).
