Predictions

Everything the dashboard forecasts, explained without the math. The detailed methods — every model, every failed attempt, every number's origin — live on the Attacks and Defends pages. Short version: attacks are solved; defends are one dice roll wrapped in mechanics we've fully mapped.

Tracking 5,099 defends and 926 attacks across 160 seasons · live · refreshes hourly

Two kinds of prediction

Everything on this page falls into one of two boxes, and the site never mixes them up — one is mechanical (a game rule we measured, worth a real countdown), the other requires actual prediction (a guess that had to beat a pass mark we wrote down before testing, worth a time window at best):

⚔️ Attacks: arithmetic, not fortune-telling

A homeworld assault is not random. It fires the moment a faction's campaign bar fills — the instant the last of its 10 sectors completes. We've checked this against every attack across ~160 recorded wars: it's a hard trigger, not a tendency.

That turns "when is the next assault?" into a school problem:

time left = points still needed ÷ how fast points are moving

The dashboard measures the pace over the last 24 hours, corrects for how old the latest reading is and for the weekly rhythm (weekends run faster), and shows the answer as a window rather than a single number — asymmetric on purpose, because arrival = work ÷ pace, and a slowdown delays the arrival more than an equal speedup hastens it. We replayed this forecast against every recorded war as if it were running live, and it beat the pass mark we had written down beforehand — which is why it gets to be a real ETA on the dashboard.

The same division powers the sector ETA on faction cards — aimed one sector boundary early instead of at the campaign's end (details on the Attacks page).

Full method: pace windows, staleness anchoring, why the window is lopsided →

🔮 While an event runs: the outcome verdict

Every live event — a 150-minute defend or a 48-hour assault — resolves one of exactly two ways, and they end at different times: a loss runs out the clock (the countdown on the card is the loss time), a win ends early, the moment the points fill (rule 6 below). So the cards don't show a bare fill ETA; they name the outcome:

• On track → "Holds ~2h" on a defend, "Taken ~12h" on an assault — the fill ETA is the win time, and it beats the countdown.
• Behind pace → "Falls" / "Fails" — no number, because the loss time is already on the card: it's the countdown itself.

The math is one line — at the average pace since the event started, does the bar fill before the deadline? — and it's the same comparison that drives the ▲/▼ pace arrow on the right of the bar, so the two can never disagree (an automated test keeps them locked together). Replayed over every completed event with minute-level progress history (130 events, 2,193 rendered moments), the verdict calls the final outcome correctly 91.6% of the time, and it sharpens as the event ages:

The shaded band is why the cards stay silent for the first quarter of every event: that early, the average pace is still dominated by whatever happened in the opening minutes (~72% accuracy — barely better than a blind guess), so the verdict is hidden rather than shown flickering. Past 60% elapsed it's calling 96–99% correctly.

What the shipped functions say right now:

🛡️ Defends: three mechanics and one dice roll

Defend waves look random. Most of the pattern turns out to be machinery, measured across 5,000+ recorded defends:

1. The chain. Lose a defend and the next one starts within minutes (~97% of the time). Win, and the "train" ends. Everything inside a train is mechanical — only the first wave of a train needs forecasting.
2. The counterattack clock. A failed homeworld assault always runs exactly 48 hours, and the moment it times out a counterattack lands on that same faction — within minutes, every time in recorded history. While an assault is running, the dashboard shows this as a real countdown: "if the assault fails, counterattack at ⟨time⟩." That line is a mechanic, not a model.
3. The gate. No random defend ever starts while an assault is running — the hidden invasion timer is paused. Win the assault and the held timer releases: the next wave often lands within minutes of the victory.
4. The dice roll. Strip all of that away and what's left is one global hidden timer: after a train ends, the next free wave arrives ~32 hours later on average, with genuine randomness no model has beaten — five attempts, each scored against the same pass mark written down in advance, each miss recorded on the Defends page.

So the dashboard's Predicted Wave card runs two separate forecasts, because these are two different problems. No assault running: it looks up every moment in ~160 wars that looked like this one and shows the middle estimate with the middle-50% window around it — "~20h (14-32h) · 63% within 24h" — percentages that verifiably come true at those rates, never a fake countdown. Assault running: the dice are paused (mechanic #3), so the band steps aside and the card shows mechanic #2's deterministic clock instead — "counterattack ⟨time⟩" — phrased through the assault's live pace: "behind pace" means expect it, "on pace to succeed" means only if the players falter.

Full story: five attempts, the placebo discipline, the reverse-engineered scheduler →

The rule book

Every rule below is confirmed against the full recorded history (the exact counts, and the committed script that re-verifies each one, are on the detail pages):

1. Two defends never run at the same time. Zero overlaps across 120,000+ defend pairs — there is a single global "invasion slot."
2. A faction never defends while you're assaulting its homeworld. Cross-faction overlap is fine (a defend and a different faction's assault co-run routinely).
3. At most three events run at once — up to three simultaneous assaults, or two assaults plus one defend. Never two defends.
4. The chain: a lost defend is followed by another within ~10 minutes (~97%); a won defend ends the train.
5. Assaults trigger deterministically the instant a faction's campaign bar fills (9 of 10 sectors is therefore the "assault pending" window, and defend waves go quiet through it).
6. Losses run out the clock; wins end early. Failed assaults last exactly 48 hours — a timeout, 544 of 544 in history — and failed defends run their full timer too, 3,179 of 3,260 at exactly 150 minutes. Wins are the opposite: they end the moment the points fill (1,681 of 1,833 won defends finish inside the timer; won assaults at a median 37h). So while an event is live, its countdown is the loss time and its fill ETA is the win time — which is why the event cards name the outcome instead of showing a bare ETA.
7. A failed assault is answered immediately: the counterattack lands on that faction within minutes of the timeout, almost always on region 9 — and counterattack trains are harder to stop than normal ones (players win the first defend ~23% vs ~47%).
8. The invasion timer is gated during assaults: no random defend has ever started while an assault was running.
9. Victory releases the held timer: after a won assault, the next wave often lands within minutes — the timer had already fired and was waiting for the gate to open.
10. The free waves are genuinely random: one global timer, ~32h average delay (gamma-shaped), faction drawn at spawn — mostly evenly, with a ~61% tilt toward a faction sitting one sector from its assault.

Sources

Prior art credited: much of the mechanic set was independently inferred by the community — notably this Steam guide — which we treated as hypotheses and verified against the event log (its 48h/2h30m durations, the assault gate, and the region-9 counterattack all confirmed; exact numbers on the Defends page). Original findings (counterattack timing, victory release, the scheduler's gamma shape) are ours, each reproducible from scripts/analysis/.

What would make these better

Data, not cleverness — and it matters which data. The game only started recording minute-by-minute event progress a few wars ago, so anything that needs that detailed footage is working from a handful of examples, while everything built on the ~160-war event log is already as good as it can get. Where each forecast stands:

Nothing above gets worse by waiting — the shipped forecasts already use everything the current record supports. The rows marked final are done; the rest upgrade themselves as wars end.

---

This hub and the detail pages carry live figures refreshed hourly from the database (labeled as such); backtest verdicts everywhere are static, each reproducible from a committed script in scripts/analysis/.