2255 Commits

Author	SHA1	Message	Date
Evan	0c83444dc9	feat(client): custom plutonium amount purchase in store (#4515) ... ## Summary Adds a **custom plutonium amount** purchase option to the Store, wiring the client to the new `POST /stripe/create-custom-currency-checkout` endpoint (infra [PR #400](https://github.com/openfrontio/infra/pull/400)). Players can buy any integer **20–2000** plutonium, priced inline server-side at **20 plutonium = \$1.00**. A new `<custom-currency-card>` renders as the **last tile in the Store "Packs" tab** — a slider + number input with a live price and a "Buy for \$X.XX" button that redirects to Stripe Checkout. ## Changes | File | Change | |---|---| | `src/client/Api.ts` | New `createCustomCurrencyCheckout(hardAmount)` — POSTs `{ hardAmount, hostname }`, returns the Stripe `url` (mirrors `createCheckoutSession`). | | `src/client/components/CustomCurrencyCard.ts` | New `<custom-currency-card>` component: plutonium slider + number input, live price, clamps to 20–2000 integer client-side, redirects to Stripe on buy. | | `src/client/Store.ts` | Renders the card after the fixed packs in the "Packs" tab; drops the now-unreachable "no packs" empty state. | | `src/client/Main.ts` | Handles `type=custom_currency` in the `#purchase-completed` redirect (success alert + strip hash; balance refetches from `/users/@me` on load). | | `src/client/LangSelector.ts` | Registers `custom-currency-card` for translation-reload re-render. | | `resources/lang/en.json` | Adds `store.buy_for`, `store.custom_amount`, `store.custom_currency_purchase_success`; removes the orphaned `store.no_packs`. | ## Notes - **No catalog product** — unlike currency packs, the custom amount is priced inline server-side, so the card is standalone (not a `resolveCosmetics` item). - **Async credit** — no optimistic balance bump; the balance reflects the Stripe webhook via `/users/@me` on return, matching the currency-pack flow. - Server is authoritative on bounds/rate; client-side clamping is UX-only. ## Testing - Full suite green: **1842 tests / 153 files**; `tsc --noEmit` and eslint clean. - Manually verified in the running app (headless Chromium): card renders in the Packs tab; amount/price stay in sync across slider + number field; clamping confirmed (5000→2000/\$100.00, 5→20/\$1.00, 750→\$37.50 — matches the pricing table). 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-authored-by: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-07-06 17:23:58 -07:00
Evan	46b9fe88bb	fix: survive host modal close during listed-lobby auto-start (#4514) ... Follow-up to the listed-lobby auto-start feature (`2a82b01e3`, on main). ## Bug When a listed lobby auto-started (and in some paths on manual start), the game began server-side but a player got ejected back to the menu before it loaded. Root cause: `BaseModal.close()` navigates via `showPage()`, which **force-closes whichever page-modal is currently visible**. During the game-start transition that is the *other* lobby modal — closing the join modal first cascade-closed the host's modal with `leaveLobbyOnClose` still armed (host disconnected → host-left teardown killed the game); reversing the order just moved the victim to the joiner. No close order fixes both sides. ## Fix - **Disarm both lobby modals before closing either** in the prestart transition (`disarmLeaveOnClose()` on `HostLobbyModal` and `JoinLobbyModal`), so no cascade order can disconnect anyone mid game-start. - Both modals re-arm `leaveLobbyOnClose` in `onOpen` instead of `onClose`'s state reset, so once disarmed no later cascade close can re-arm it until the modal is reopened. - `HostLobbyModal.closeWithoutLeaving()` (pattern `JoinLobbyModal` already used), called explicitly instead of the generic modal-close loop. - **Server hardening:** `handleClientDisconnect` bails on `hasStarted()` (which includes prestart) instead of raw `_hasStarted`, so host socket churn during the lobby → game transition can never tear down a starting game regardless of client behavior. Regression test included. ## Verification Headless end-to-end (two browser contexts, host + joiner, `leave-lobby` stack-trace tripwire armed on both pages): - **Manual start:** host and joiner both receive prestart/start and enter the game; zero `leave-lobby` dispatches. - **Auto-start:** same, with nobody interacting after listing. Also confirmed manually in a real browser. The auto-start deadline was temporarily 30s during testing and is restored to 5 minutes in the final commit. Full suite green (1843 + 161), tsc/eslint/prettier clean. 🤖 Generated with [Claude Code](https://claude.com/claude-code) --------- Co-authored-by: Claude Fable 5 <noreply@anthropic.com>	2026-07-06 10:55:16 -07:00
evanpelle	2a82b01e30	feat: auto-start listed lobbies after 5 minutes ... Hosts can't sit on a public listing: setListed(true) records listedAt, and once listedAt + HOSTED_LOBBY_AUTO_START_MS passes, GameManager's tick arms the normal start countdown (same path as the host's Start button, honoring startDelay). Cancelling the countdown re-arms on the next tick; unlisting cancels the deadline and relisting starts a fresh one. Duplicate setListed(true) calls don't extend it. The deadline rides to the host as autoStartAt in lobby info, rendered as an amber countdown next to the Public/Private switch in the host modal header (hidden once the real start countdown takes over). Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>	2026-07-06 09:11:13 -07:00
Evan	5d21be826d	feat: subscriber-hosted public lobby listing (#4480) ... Part of #4040 (v1 scope: listing + browser + per-subscriber limit; custom lobby name/description left for a follow-up). ## What Subscribers can toggle their **private lobby** to be **publicly listed**; a browsable **"Open Lobbies"** list appears in the Join Lobby modal. Hard limit of **one listed lobby per subscriber**, enforced cluster-wide. ## How **Semantics** — a listed lobby stays `GameType.Private`: the host keeps full control and starts the game manually; the toggle only controls visibility. The `listed` flag lives on `GameServer` (not `GameConfig`), so it cannot be smuggled in through `update_game_config` and never touches core/sim/records. **Distribution** — reuses the existing public-lobby pipeline end to end: a new `"hosted"` `PublicGameType` bucket flows worker → master IPC → `/lobbies` websocket → `PublicLobbySocket`. Master scheduling now iterates only `SCHEDULED_PUBLIC_GAME_TYPES` (`ffa`/`team`/`special`), so it never sets countdowns on or schedules replacements for hosted lobbies. Lobbies delist automatically when the game starts/fills/dies (phase change). The broadcast fingerprint now includes browser-visible config, so host edits (map/mode) refresh the list even though the gameID doesn't change. **Gating** — new authenticated endpoint `POST /api/game/:id/listing`: - creator-only (403), private + not-started only (409) - fresh subscription check via server-side `getUserMe` using the shared `hasActiveSubscription()` helper (`active`/`trialing`); skipped in `GameEnv.Dev` (same precedent as Turnstile) so it's testable locally - one-lobby-per-creator (409): a SHA-256 hash of the creator's persistentID rides worker↔master IPC (`PublicGameInfo.creatorID`); the master dedupes as a race backstop. The hash — and host-only config (whitelist, name reveals) — are **stripped from every client payload** (broadcast + primed snapshot). **Client** — subscriber-gated "List lobby publicly" toggle in the host modal (server rejection reverts the toggle and shows a translated message); "Open Lobbies" rows (map, mode, player count) in the Join Lobby modal that reuse the existing private-join flow. **Compat** — `PublicGames.games` is now a `partialRecord`, so newer clients tolerate servers that don't send every bucket. Note: already-open old clients will fail to parse broadcasts containing the new `hosted` key until refreshed (closed Zod enum) — same class of break as previous wire-schema changes. ## Testing - `tests/server/HostedLobbyListing.test.ts` (15 tests): listed-lobby filtering, flag not settable via config intent, master aggregation + creator dedupe + no scheduling of hosted, creatorID stripping (broadcast + primed snapshot), `creatorHasListedLobby` (broadcast + local), fingerprint refresh on config change - `hasActiveSubscription` cases in `ApiSchemas.test.ts`; hosted counts-delta patch in `LobbySocket.test.ts` - Full suite green (1723 + 141 tests), tsc/eslint/prettier clean - **E2E in the real app** (headless Chromium, two browser contexts): host lists lobby → appears in second browser's Join Lobby list (creatorID absent from payload) → join succeeds (2 players in lobby) → same creator's second lobby rejected 409 with toggle revert → unlist removes it from a fresh browser's list. Curl negatives: missing auth 400, bad token 401, non-creator 403, missing game 404, bad body 400. ## Known follow-ups - Custom lobby name/description in the browser (needs the censor pipeline) — rest of #4040 - A listed lobby whose host closes the tab stays advertised indefinitely (an empty private lobby never leaves the Lobby phase) — pre-existing lifecycle, now more visible; consider delisting on creator disconnect 🤖 Generated with [Claude Code](https://claude.com/claude-code) --------- Co-authored-by: Claude Fable 5 <noreply@anthropic.com>	2026-07-05 20:25:56 -07:00
Evan	22c873cf55	perf(client): tick-dispatch timing harness + main-thread tick optimizations (late-game p95 −65%) (#4512) ... ## Problem Every 100 ms the main thread's worker `onmessage` callback processes a full game tick (`gameView.update` → `webglBuilder.update` → `renderer.tick`). At 60 fps this competes with the 16.7 ms frame budget, and on the Giant World Map it takes several ms — frame drops on low-end hardware. ## Harness (`npm run perf:client-tick`) Headless-Chromium harness that times every worker→main `game_update` dispatch on the main thread, with structured-clone deserialization measured separately from the handler body (via a `Worker.prototype.addEventListener` wrapper installed as a page init script — no product-code changes). It reports windowed distributions, captures `.cpuprofile` files at chosen ticks, writes raw samples and an end-of-run screenshot. `AnalyzeCpuProfile.ts` breaks a profile down by inclusive time under the dispatch subtree. Init scripts are passed as **strings**: tsx compiles function-form init scripts with esbuild `keepNames`, whose injected `__name` helper doesn't exist in-page and silently kills the game worker setup. ## Baseline (Giant World Map, 400 bots, headless) Dispatch handler ms — cost **grows with game progression**: | window | mean | p50 | p95 | max | |---|---|---|---|---| | tick 506 | 2.22 | 2.20 | 3.40 | 5.00 | | tick 1506 | 2.60 | 2.00 | 7.00 | 10.40 | | tick 2000 | 2.67 | 1.90 | **8.70** | **12.70** | Deserialization is negligible (0.12 ms mean). CPU profiles attributed the growing tail to the leaderboard's once-per-second refresh: its Max-troops column calls `config().maxTroops(p)` for **all ~508 players**, and `PlayerView.units()` scanned **every unit in the game** per call — O(players × units), growing as units accumulate. ## Round 1 — algorithmic fixes - **GameView**: new `unitsOwnedBy(smallID)` — an active-units-by-owner index built lazily at most once per tick. `PlayerView.units()` reads its own units from it: O(own units) instead of O(all units). Also speeds up unit display, player panel, and buildables queries. - **NamePass.updateNames**: reads player state directly from the caller's map by smallID instead of rebuilding three lookup maps per tick; skips the slot-assignment sweep once every player has a slot. After (same map, same spawn tile): | window | mean | p50 | p95 | max | |---|---|---|---|---| | tick 506 | 2.12 | 2.00 | 3.10 | 5.20 | | tick 1506 | 1.86 | 1.80 | 2.90 | 4.30 | | tick 2000 | 1.74 | 1.60 | **2.40** | **4.70** | Late-game p95 −65% (8.7 → 2.4 ms), worst dispatch −63% (12.7 → 4.7 ms), and per-dispatch cost no longer grows with game progression. The leaderboard disappeared from the dispatch profile entirely. ## Round 2 — allocation churn + time slicing Aimed at GC pauses and low-end CPUs; measures flat vs round 1 on a fast machine, as expected: - **`FrameData.changedTiles`** is now the plain tile-ref array GameView already builds instead of a per-tile `{ref, state}` object copy — heavy battle ticks allocated tens of thousands of objects per tick for a `state` field that was always 0. `TilePair` removed; `TerritoryPass` buckets refs synchronously, so the live reference is safe. - **`UnitView.lastPos`** is only re-sliced when a move actually appended a position — the unconditional `slice(-1)` allocated an identical 1-element array per unit per tick, including for structures that never move. - **`NamePass.updateNames`** refreshes slots round-robin, a quarter per tick — the full per-player diff pass spreads over ~400 ms, under the existing 500 ms troop-text cadence; positions lerp continuously. Unnamed slots and snap passes (seeks) are always processed so nothing pops in late. Dispatch share: 17% → 13%. Not sliced on purpose: tile ingest and frame upload need a consistent per-tick snapshot (stale `GameMap` reads would leak into hover queries, minimap, attack targeting) — a correctness risk not worth ~1 ms while the worst dispatch already fits in a quarter of the frame budget. ## Verification - `npx tsc --noEmit`, eslint clean; full suite green (1929 tests) - 6 new GameView tests cover the owner index (grouping, inactive exclusion, ownership capture, death, type filtering, copy semantics); changedTiles tests updated to the ref-array contract - Headless end-of-run screenshots verified after each round: leaderboard Max-troops values, map names + troop counts + flags all render correctly (including with name slicing active) 🤖 Generated with [Claude Code](https://claude.com/claude-code) --------- Co-authored-by: Claude Fable 5 <noreply@anthropic.com>	2026-07-05 13:46:02 -07:00
Evan	571f58440d	perf(client): main-thread memory harness + drop three map-sized render buffers (-23%) (#4511) ... ## Summary Follow-up to #4507, moving the memory-footprint campaign to the **main thread** (client). Two parts: a headless browser measurement harness, and a first optimization round that cuts the main-thread live heap on Giant World Map by **23%** (166 → 128 MB at tick 2000). ## Part 1 — `npm run perf:client-mem`: headless main-thread memory harness Drives a real singleplayer game in headless Chromium and measures the **page's isolate only** (the core sim worker is a separate CDP target): - Starts its own vite dev server on a private port (default 9017) so it always measures the current checkout. - Double-forced-GC checkpoints every `--window` ticks: JS heap, ArrayBuffer backing-store bytes (`Runtime.getHeapUsage`), DOM nodes, listeners, ticks/s. - `--snapshot-at <ticks>` writes V8 heap snapshots, analyzable with the retainer/summary tools from #4507. - Spoofs the unmasked WebGL renderer string via an init script so the software-GL gate (#4324) admits SwiftShader — no game code touched; rendering still runs software (hence the rAF throttle). - End-of-run screenshot as a rendering sanity check. Baseline (Giant World Map, 400 bots, 12,000 ticks): ~176 MB live, of which ~116 MB is **static per-tile buffers** allocated up front for the 8M-tile map — flat during play, no leaks. ## Part 2 — drop three map-sized render-layer buffer copies | Buffer | Before | After | |---|---|---| | `TrailPass.cpuTrailState` | 15.3 MB copy | **deleted** — dead code; every upload entry point sets the live reference to TrailManager's array | | `RailroadPass.cpuRailroadState` | 15.3 MB across 2 arrays | references `RailroadCache.railroadState` (stable identity, mutated in place) | | `RailroadPass.cpuGhostRailState` | ↑ | sparse `Map<ref, value>`; preview diffs applied as per-texel `texSubImage2D` writes (path-sized work instead of a full 8 MB texture upload per build-preview mouse move) | | `TerrainPass` + `MapRenderer` terrain bytes | 7.6 MB (one buffer, two retainers) | `terrainSource()` provider — re-bakes (theme change, context restore) regenerate from the live game map, which already reflects water-nuke conversions | Tick-2000 snapshot comparison (giant world, 400 bots): **166.4 → 128.4 MB**. ## Verification - `tsc --noEmit`, eslint, full test suite (1924 tests) pass. - 2000-tick headless giant-world game after the change: no GL pageerrors, end-of-run screenshot renders terrain/territory/borders/names correctly, sim speed unchanged (~5 ticks/s headless). - Ghost-rail ops flush before the zoom-fade early-return, so the op queue can't grow while previewing at low zoom. - WebGL context restore recreates all passes fresh and the owner re-uploads state (existing `onContextRestored` path), consistent with the new reference-based buffers. Note: heap snapshots in `tests/perf/output/` are gitignored; the numbers above are from runs recorded in the PR discussion. 🤖 Generated with [Claude Code](https://claude.com/claude-code) --------- Co-authored-by: Claude Fable 5 <noreply@anthropic.com>	2026-07-04 20:18:52 -07:00
Evan	eae2be6458	feat(store): confirm plutonium and caps purchases before charging (#4510) ... ## Summary Fixes #4218 Currency purchases (Plutonium and Caps) fired immediately on click with no confirmation. This adds a confirmation modal — reusing the existing `confirm-dialog` Lit component — that gates every currency purchase behind an explicit "Confirm". There were two paths that could trigger a currency purchase, and both are now gated: - **The Plutonium / Caps price buttons** — `PurchaseButton` no longer calls `onPurchaseHard`/`onPurchaseSoft` directly; it opens a `confirm-dialog` ("Buy {item} for {amount} {currency}?", warning variant) and only runs the purchase on confirm. Cancel / backdrop click dismisses. - **Whole-card click** — `CosmeticContainer` auto-fires the purchase when there's exactly one payment option, which bypassed the button entirely for currency-only items. That path now delegates to the purchase button's new `requestCurrencyPurchase()` so it goes through the same dialog. The existing purchase flow (busy guard, loading overlay, insufficient-currency dialog) is unchanged and runs after confirmation. Dollar purchases are untouched (they go through Stripe checkout, which is its own confirmation step). New i18n keys: `store.confirm_purchase_title`, `store.confirm_purchase_body` (en.json only, per Crowdin convention). ## Test plan - [x] ESLint, `tsc --noEmit`, Prettier pass - [ ] Manual check in staging: click a Plutonium or Caps price button → dialog appears with the right currency name and amount; confirm purchases, cancel doesn't - [ ] Manual check: click the card body of a currency-only item → same dialog (not an instant purchase) 🤖 Generated with [Claude Code](https://claude.com/claude-code) --------- Co-authored-by: Claude Fable 5 <noreply@anthropic.com>	2026-07-04 18:52:17 -07:00
Zixer1	2a1381b41e	feat(doomsday-clock): show the zone readout to spectators and replay viewers (#4497) ... ## Description: Follow-up to #4469. The Doomsday Clock panel hides itself unless the viewer has a living player, so spectators, replay viewers, and eliminated or not-yet-spawned players see nothing, even though the clock is the most useful thing to watch in those cases. This shows the panel whenever the mode is on and there's no winner yet: - **Live player:** unchanged. Full personal readout (your-share line, Stable/Unstable/Collapsing status, danger pulse). - **Spectator / replay / eliminated / not-spawned:** zone-only readout. The rising threshold bar and the wave countdown ("Rising to X%", "Final X%", "Next wave X% in mm:ss"), with no personal line and no false danger pulse. One gate drives it: `live = me && me.isAlive()`. The zone math was already player-independent, so nothing new there. Tested: `tsc --noEmit`, ESLint, Prettier, the `DoomsdayClockExecution` suite (28/28), and `build-prod`, all clean.	2026-07-03 15:00:32 -07:00
Evan	22d5aba5ae	refactor: standardize cardinal-neighbor iteration on neighbors() N,S,W,E order (#4495) ... ## Summary Follow-up to #4494. That PR added `forEachNeighborNSWE` as a third neighbor iterator because the existing allocation-free helpers (`forEachNeighbor`, `neighbors4`) visit in W,E,N,S order while `neighbors()` visits N,S,W,E — and substituting one for the other changes simulation behavior at order-sensitive call sites. This PR removes that duplication by standardizing on **one order everywhere**: `forEachNeighbor` and `neighbors4` now visit in the same N,S,W,E order as `neighbors()`, and `forEachNeighborNSWE` is deleted. ## ⚠️ Intentional behavior change Callers of the flipped helpers that are order-sensitive now make different (equally valid) decisions: - `AttackExecution.addNeighbors` — PRNG values are drawn per neighbor while building the conquest frontier, so attack expansion patterns differ - `AttackExecution.handleDeadDefender` — a dead defender's tiles go to the *first-visited* adjacent player - `WarshipExecution.bestNeighborToward` — distance ties break by visit order - `PlayerExecution` surrounded-cluster flood fill — set insertion order propagates to conquer order Game outcomes for a given seed differ from previous builds (verified: the 12k-tick reference run ends with 31 players alive vs 24 before). Determinism across clients *within* a build is unaffected — all clients run the same code, so there is no desync risk. Replays/verification pinned to old hashes will not match this build. New reference hashes for the headless perf harness (seed `perf-default`): | Run | Final hash | |---|---| | giantworldmap, 12,000 ticks | `57830793797434300` | | giantworldmap, 2,000 ticks | `55125379638382860` | | world, 1,800 ticks | `32337437717390864` | ## Verification - [x] Full suite green (1,901 tests), including new exact-order contract tests: `forEachNeighbor` and `neighbors4` must match `neighbors()` contents **and order** for every tile - [x] 20-game-minute Giant World Map benchmark: no perf regression (73 ticks/sec, GC 1.2% of wall, allocation profile unchanged) - [x] Order-sensitivity audit of every `forEachNeighbor`/`neighbors4` call site (sensitive ones listed above; the rest are booleans, counts, or min/max accumulations) 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-authored-by: Claude Fable 5 <noreply@anthropic.com>	2026-07-03 12:42:22 -07:00
Evan	be77ab4fc9	feat: structures cosmetic effect (hover-shown gradient/transition recolor) (#4492) ... ## Description: Adds a new `structures` cosmetic effect type: an equippable effect that recolors the owner's structure icons (City, Port, Factory, Defense Post, SAM Launcher, Missile Silo) with gradient or transition color styles. The effect is **shown while the owner's territory is hovered** — structures otherwise keep their normal player colors, so the map stays readable. **Cosmetics / selection** - `StructuresEffectAttributesSchema` (`CosmeticSchemas.ts`): its own discriminated union (`gradient` / `transition`) — structurally identical to the trail attributes today, but structures aren't trails, so it's a separate schema free to diverge. - Slot = the effectType itself: `effectTypeForSlot` is generalized to map any non-nukeExplosion effect type to itself, so server privilege checks (`Privilege.ts`), client selection, and persistence all work with no per-type code. - Effects tab, Default tile, and the store preview (shared color swatch) come from `EFFECT_TYPES`; the only UI addition is the `effects.type.structures` label in `en.json`. **Rendering** - The shared per-player effect palette grows from 2 to 3 blocks (`EFFECT_PALETTE_BLOCKS`; structures = block 2, pinned by a build-breaking guard). `syncPlayerEffects` resolves the `structures` selection through the same `writeEffectEntry` used by trails. - `StructurePass` binds the effect texture plus `uTime` and `uHoverOwner` (fed from the existing `HoverHighlightController` → `setHighlightOwner` path, now forwarded to the pass). - `structure.frag.glsl` recolors the **fill only** — the border keeps the player color for ownership legibility; alt view and construction gray bypass the effect entirely. - Style semantics: - `gradient` — the palette spans each icon's diagonal once (a visible gradient across the shape), sliding one full cycle every `colorSize · 4 · count / movementSpeed` seconds (the trail-equivalent pace; world-space banding like the trail's would put a whole icon inside one band and read as a flat color) - `transition` — the whole icon is one color at a time, cross-fading at `frequency` colors/s - Glyph contrast: the inner icon's black/white decision is now a smooth luminance fade (`smoothstep(0.25, 0.45)`) instead of a hard flip at 0.25, so animated fills cross-fade the glyph instead of snapping it between black and white. ## Please complete the following: - [ ] I have added screenshots for all UI updates - [x] I process any text displayed to the user through translateText() and I've added it to the en.json file - [x] I have added relevant tests to the test directory 🤖 Generated with [Claude Code](https://claude.com/claude-code) --------- Co-authored-by: Claude Fable 5 <noreply@anthropic.com>	2026-07-03 12:41:39 -07:00
Evan	5e4b2791aa	perf: reduce core-sim GC churn 42% and add GC-churn profiling to the perf harness (#4494) ... ## Summary Reduces core-simulation GC churn by **42%** on a 20-game-minute Giant World Map run, and extends the headless full-game perf harness so churn is measurable and regressions are visible. ### 1. GC-churn measurement (`tests/perf/fullgame/GcProfiler.ts`) `npm run perf:game` now reports: - **GC pauses** by kind (minor/major/incremental) via a `PerformanceObserver` on `'gc'` entries, bucketed into tick windows by timestamp (V8 only delivers these entries on a timer task, so they're flushed after the run) - **Allocation rate** per `--window N` ticks (default 1000) from used-heap deltas sampled every tick, so churn can be tracked across game phases - **Top allocating functions** from the V8 sampling heap profiler with `includeObjectsCollectedBy{Major,Minor}GC` — i.e. actual churn including short-lived garbage, not live memory — plus a `.heapprofile` loadable in Chrome DevTools (Memory → Allocation sampling) New flags: `--window N`, `--no-gc-profile`, `--no-alloc-profile`. ### 2. Allocation reductions in the hot paths it found | Site | Change | |---|---| | `GameMap.bfs` | inline neighbor enumeration instead of an array per visited tile | | `GameMap`/`Game` | new `forEachNeighborNSWE` — allocation-free iterator matching `neighbors()` N,S,W,E order for order-sensitive callers (`forEachNeighbor` visits W,E,N,S, so substituting it would change sim behavior) | | `PlayerImpl.nearby` / `sharesBorderWith` / `shoreReachableNeighbors` | no per-call neighbor arrays; no materialized shore-tile array | | `PlayerImpl.units(types)` | gather into a reusable scratch buffer, return one exact-size slice (still a fresh snapshot array per call) | | `AiAttackBehavior.maybeAttack` | single pass over border neighbors replacing the `flatMap`/`filter`/`map` chain over every border tile | | `AiAttackBehavior.isBorderingNukedTerritory` | reusable `neighbors4` buffer with early exit | | `SharedWaterCache.build` | allocation-free neighbor iteration | | `SpatialQuery.bfsNearest` | first-minimum scan instead of collect-then-stable-sort (identical result incl. tie-breaking) | ### Results (Giant World Map, 400 bots, 12,000 ticks ≈ 20 game-minutes, seed `perf-default`) | Metric | Before | After | |---|---|---| | Sampled allocations (incl. collected) | 97.7 GB | **56.9 GB (−42%)** | | GC count / total pause | 1,682 / 3,313 ms (1.8% of wall) | 1,058 / 2,087 ms (1.2%) | | Ticks/sec | 66 | 70 | | p99 / max tick | 49.9 ms / 988 ms | 43.5 ms / 689 ms | | Ticks over 100 ms budget | 31 | 19 | ## Determinism Every rewrite preserves exact iteration order (the new NSWE iterator exists precisely for the order-sensitive sites). Verified by identical final game-state hashes on three runs: Giant World Map 12,000 ticks (`67286276735690560`), Giant World Map 2,000 ticks, and World 1,800 ticks. ## Test plan - [x] Full suite green (1,896 tests) - [x] New tests: `forEachNeighborNSWE` order contract vs `neighbors()` over every tile; `units()` filtering semantics (insertion order, fresh-array guarantee, duplicate types, Set path) - [x] Final-hash equality on 3 seeded headless runs (2 maps) 🤖 Generated with [Claude Code](https://claude.com/claude-code) --------- Co-authored-by: Claude Fable 5 <noreply@anthropic.com>	2026-07-03 12:30:28 -07:00
Zixer1	78ef7b56fd	feat(doomsday-clock): battle-royale style zone gamemode (#4469) ... Resolves Issue #4463 ## Description: An optional game mode that (almost) guarantees a finish instead of letting late-game stalemates drag on. Originally called sudden death, renamed to Doomsday clock Once enabled, every side (each player in FFA, each whole team in team modes) must hold a rising share of the map. A side below the bar is skulled; after a short warn its troops bleed to zero, forcing consolidation to a winner. ### How it works - **Rising zone:** a grace period, then the required share ramps up linearly to each level with 30s pauses between (a battle-royale "zone"). Levels track the ofstats FFA territory median (3/5/10/20/30%). - **Four speed presets** (slow / normal / fast / very fast) change only the pace: normal ends ~30 min, very fast ~15. - **Troop decay:** a linear ramp as a % of max capacity, ~50s from caught to zero (10s warn + ~50s ≈ 1 min total). - **UI:** a HUD panel (live share vs target, wave/decay countdowns, red/orange cues) and an on-map skull above flagged players (blinks in danger, steady while draining). ### Notes for review - Off by default; no effect on existing games. However, as discussed we can add it to the modifier pool for public games to see how popular the gamemode is vs normal play. - Sim is deterministic (integer-only, in `src/core`), covered by unit + integration tests. - One-line addition to `GameServer.updateGameConfig` so the setting survives the host → server → client round-trip. - Status is packed into the existing name-pass data slot (`pd4.w`: 0/1/2 = none/danger/draining); the skull is composited into the icon atlas at load. ### Testing `npm test`, `npm run lint`, `npx prettier --check .`, `npm run build-prod` all pass. ### UI: <img width="243" height="100" alt="Image" src="https://github.com/user-attachments/assets/c4c9eeb0-4feb-437d-9aac-b2786a841b74" /> Dropdown between slow, normal, fast, very fast Before zone: <img width="302" height="175" alt="Image" src="https://github.com/user-attachments/assets/7359a1ea-4951-446d-a23c-0711fe06cc5d" /> Zone started, player not affected the pannel also blinks orange for 10s: <img width="297" height="175" alt="Image" src="https://github.com/user-attachments/assets/fcc565a5-d5d0-47a7-97ea-d0ba9d9ad899" /> Player affected, grace period (Danger): <img width="314" height="170" alt="Image" src="https://github.com/user-attachments/assets/ff96d21e-96f3-4ef9-8190-48eecc7aac0f" /> Skull icon blinking over player (everyone sees it) - older screenshot, the clipping has been fixed <img width="462" height="145" alt="Image" src="https://github.com/user-attachments/assets/53899211-33b1-40e1-83f2-77f2096f0cad" /> Player affected, grace period ended (Draining): <img width="360" height="159" alt="Image" src="https://github.com/user-attachments/assets/4b226d57-da4d-4866-ab5f-db48e4ed1ea2" /> Skull icon no longer blinking, everyone can see you are in a state of decay, and troops are draining: <img width="732" height="146" alt="image" src="https://github.com/user-attachments/assets/cd10fedb-6e87-4dfc-9fbf-55d3945a7901" /> Skull is visible like alliances icon also on player tab <img width="558" height="81" alt="Image" src="https://github.com/user-attachments/assets/6acdbe91-bdd0-40c7-942b-3990d4dae87f" /> (just UI example, best way to see it is to hop on a solo game and play against AI) ## Please complete the following: - [x] I have added screenshots for all UI updates - [x] I process any text displayed to the user through translateText() and I've added it to the en.json file - [x] I have added relevant tests to the test directory ## Please put your Discord username so you can be contacted if a bug or regression is found: zixer._	2026-07-02 18:42:03 -07:00
bijx	ad760a0f3d	feat: Achievement medal overview (#4487) ... ## Description: In the spirit of achievement hunting, seeing how many medals a player has achieved helps show overall progress. Overview only toggles on when user clicks toggle achievements button. Works on mobile too. https://github.com/user-attachments/assets/ea77075b-5e91-4e62-8ac9-52bcdf95cc64 ## Please complete the following: - [x] I have added screenshots for all UI updates - [x] I process any text displayed to the user through translateText() and I've added it to the en.json file - [x] I have added relevant tests to the test directory ## Please put your Discord username so you can be contacted if a bug or regression is found: bijx	2026-07-02 18:31:19 -07:00
Evan	b72956d0c0	Gate users without GPU-accelerated WebGL2 instead of running at ~1fps (#4324) ... ## Problem After the WebGL2 renderer migration, a small number of users (~a dozen of 100k DAU) report ~5fps. Root cause: they run WebGL **without GPU acceleration** (hardware acceleration disabled, blocklisted driver, or a locked-down machine), so they get a SwiftShader/software context. Software-rendered WebGL is hopeless for a real-time game — ~1fps locally. We are not supporting a canvas2d fallback. Instead: demand a GPU-accelerated context, and if we can't get one, **gate** the user with actionable instructions rather than letting the game crawl. ## What this does - **`initGL()`** ([initGL.ts](../blob/webgl-software-render-gate/src/client/render/gl/initGL.ts)) — demands `failIfMajorPerformanceCaveat: true` **and** inspects the unmasked renderer string. The flag alone isn't enough: when hardware acceleration is turned off in browser *settings* (vs. a blocklisted driver), Chrome still hands back a SwiftShader context, so we'd otherwise run at 1fps. Classifies the outcome as `ok` / `software` / `unsupported`. - **`GPURenderer`** throws `GLUnavailableError` on a non-accelerated context; the game-start `catch` shows the gate and removes the orphaned canvas. - **`<webgl-gate>`** Lit component renders a full-screen blocking gate with per-browser steps (Chrome / Edge / Firefox / Safari) for enabling hardware acceleration / WebGL. - **`gl_init` analytics event** fires every session (`status` + `renderer` for non-ok) via the existing Google Tag, so we can size the real affected % within a day. ## Notes / decisions - The gate copy is **intentionally inlined (not translated)** — it's a rarely-seen, browser-specific troubleshooting screen; 28 Crowdin keys would be poor cost/benefit, and a non-English user still has to navigate English browser menus. - `showGLGate` lazy-loads the component (`import()`), so the `render/gl` module that `Renderer.ts` imports doesn't statically pull a UI component into its graph. ## Update: fingerprint-capped contexts (#4357) A third failure class, integrated after the initial PR: `privacy.resistFingerprinting` (default-on in LibreWolf and Mullvad Browser, opt-in in Firefox) caps `MAX_TEXTURE_SIZE` at 2048 on an otherwise hardware-accelerated context. The renderer unconditionally allocates a 4096-wide palette texture, so the oversized `texImage2D` calls fail silently and the whole map renders **black** (#4357). - `initGL` now reads `MAX_TEXTURE_SIZE` after the software check and classifies the context as **`limited`** when it's below `getPaletteSize()` (4096 — the hard floor every game needs). - Unlike `software`/`unsupported`, **`limited` is a warning, not a hard block**: `initGL` still returns the context, the game starts normally, and the gate is shown with a "Continue anyway" button. `GPURenderer` exposes the capped renderer/size via `glLimited` (surfaced through `MapRenderer`), which `ClientGameRunner` uses to show the warning and log analytics. - The gate shows fingerprinting-specific instructions for `limited` (add the site to `privacy.resistFingerprinting.exemptedDomains` in `about:config`) instead of the hardware-acceleration steps. - `gl_init` reports `max_texture_size` alongside the renderer for this status, so we can size the RFP-affected population too. Fixes #4357 ## Test plan - [x] Unit tests for `initGL`'s `ok` / `software` / `unsupported` branching, incl. the "returns a context but renderer is software" case (`tests/client/initGL.test.ts`). - [x] lint / prettier / tsc clean. - [x] **Verified in real browsers (macOS).** All three gate states reproduced: - `software`: Chrome with `--use-gl=angle --use-angle=swiftshader` (confirmed "Software only" at `chrome://gpu`), and Chrome with hardware acceleration toggled off in settings — both show the hard gate instead of a 1fps game. - `unsupported`: Firefox with `webgl.disabled=true` shows the unsupported gate. - `limited`: Firefox with `privacy.resistFingerprinting=true` (MAX_TEXTURE_SIZE capped to 2048, same as LibreWolf's default) shows the dismissible warning; "Continue anyway" starts the game, and exempting the site via `privacy.resistFingerprinting.exemptedDomains` removes the warning. ## Acceptance criteria - Accelerated users: unchanged. - Software / no-accel users: see the enable-acceleration gate, not a 1fps game. - No-WebGL2 users: see the unsupported gate. - `gl_init` fires every session with status (+ renderer for non-ok). 🤖 Generated with [Claude Code](https://claude.com/claude-code) --------- Co-authored-by: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-07-02 15:54:06 -07:00
Evan	b6317964a7	feat: sparkles nuke-explosion visual type (#4490) ... ## Description: Follow-up to #4485: adds a second nuke-explosion visual, `"sparkles"` — a firework burst of twinkling glints that start at the detonation point and ride outward with the expanding front, reaching the cosmetic's full `size` at fade-out. **Schema (`CosmeticSchemas.ts`)** - `NukeExplosionAttributesSchema` is now a discriminated union on `type` (`"shockwave" | "sparkles"`), matching `TrailEffectAttributesSchema`. Old clients drop sparkles entries via `lenientRecord` and render the default ring. - The sparkles member adds `density` (required, positive) — roughly the total number of glints in the burst. - Literal attribute semantics, consistent with shockwave: - `size` — final burst width (diameter) in world tiles at fade-out - `speed` — tiles/s the width grows; duration = size / speed, clamped 0.1–15 s - `thickness` — **average** sparkle size in tiles; each glint hash-varies ±50% around it - `density` — approximate glint count; renderer clamps to 2–5000 - `colors` + `transitionSpeed` — shared palette-cycle semantics, with a hashed per-glint palette offset on top **Rendering** - `NukeExplosionRenderParams` now carries the visual type through to the pass as a matching TS union (previously any cosmetic was hardwired to the EMP style — this closes that gap for future visuals). - Sparkles are style 2 in the same `FxShockwavePass` instance stream: one new float (grid cell pitch, derived CPU-side from density), no other layout changes. - Fragment shader: one hashed glint per rotated front-normalized grid cell (jittered, cell-confined so each fragment samples only its own cell, ~1/3 dropout for organic scatter), hashed birth stagger. Glints are **fully opaque** — twinkle modulates color brightness, not alpha — holding full opacity through life and fading only over the last quarter. - SAM interceptions, the classic ring, and EMP shockwaves are unchanged. **Store / selection** - New `<sparkles-swatch>` preview (burst scales from center, density-scaled dot count, size-varied dots, palette cycling), branched in `CosmeticButton` by `attributes.type`. **Verification** - Schema tests incl. the real `rgb_nuke_sparkles` catalog entry, missing/non-positive `density` rejection. - Verified in-game via headless Chromium: size-250 RGB burst renders opaque red/white/blue glints expanding from the detonation point; sparse (40) vs dense (400) density comparison; no page errors. ## Please complete the following: - [ ] I have added screenshots for all UI updates - [x] I process any text displayed to the user through translateText() and I've added it to the en.json file - [x] I have added relevant tests to the test directory 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-authored-by: Claude Fable 5 <noreply@anthropic.com>	2026-07-02 15:21:26 -07:00
Evan	6ff202afb5	feat: nuke-explosion cosmetic effects (per-bomb-type shockwave customization) (#4485) ... ## Description: Adds a new `nukeExplosion` cosmetic effect type: when a bomb detonates, every client renders the shockwave in the firing player's equipped effect for that bomb type. **Cosmetics / selection** - New `nukeExplosion` effect schema (`CosmeticSchemas.ts`) with per-bomb selection slots — a slot is the effectType for trails and the `nukeType` for explosions (`atom` / `hydro` / `mirvWarhead`), so players can equip a distinct explosion per bomb type. - Slot resolution + validation is one shared helper (`findEffectForSlot`) used by client selection, server privilege checks (`Privilege.ts`), and the renderer; a compile-time guard keeps the nukeType and effectType slot namespaces disjoint. - Effects picker gains an Atom / Hydrogen / MIRV sub-tab bar when browsing nuke explosions; selections persist per slot in UserSettings and are validated/dropped like other cosmetics. **Rendering** - `WebGLFrameBuilder` resolves each dead nuke's owner cosmetic onto the dead-unit event; `FxShockwavePass` renders an EMP-style procedural ring (jagged crackling front, rotating lightning arcs, inner energy fill) from per-instance attributes. SAM interceptions and players with no cosmetic keep the classic white ring. - Catalog attributes have literal units: - `size` — final ring width (diameter) in world tiles at fade-out, absolute — independent of the bomb's blast radius - `speed` — tiles/s the width grows; duration = size / speed, clamped to 0.1–15 s - `thickness` (required) — ring band thickness in tiles, constant while the ring expands - `colors` — palette of up to 4 colors, cycled at `transitionSpeed` steps/s (0 = static, negative = reverse; same semantics as trail transitions) - The shockwave quad is sized radius + thickness so the absolute-width band isn't clipped into a box while the ring is young. ## Please complete the following: - [ ] I have added screenshots for all UI updates - [x] I process any text displayed to the user through translateText() and I've added it to the en.json file - [x] I have added relevant tests to the test directory 🤖 Generated with [Claude Code](https://claude.com/claude-code) --------- Co-authored-by: Claude Fable 5 <noreply@anthropic.com>	2026-07-02 14:21:01 -07:00
bijx	006f1690a5	Warship veterancy (#4433) ... ## Description: Warship veterancy! This is an idea inspired by the unit veterancy feature of games like C&C: Red Alert 2 in which unit eliminations increases the level of individual units. I've been trying to build this mechanic for months with different ideas, and I finally landed on this being one of the more balanced implementation. Warships can earn up to three levels, represented by the gold bar insignia in the bottom right of their warship sprite. <img width="622" height="202" alt="image" src="https://github.com/user-attachments/assets/a8c31a45-4ae9-41a9-b054-9c4a7f4ab1f1" /> A veterancy bar grants 20% health from the base amount, and a 20% increase in shell damage applied _after_ the random damage roll. For example, a level 3 warship will apply a 60% damage boost on top of the random shell damage value (something between 200-325. If the random value is 250, the final damage output will be `250 * 1.60 = 400`. There are three ways to achieve a veteran level: 1. **Eliminate another warship:** any time a warship neutralizes another warship, it immediately get's a veterancy increase. https://github.com/user-attachments/assets/6a9e0958-5171-4ca3-94f6-9c2300a12f8b 2. **Eliminate transport boats:** Destroying 10 transport boats will level a warship to the next veterancy bar. https://github.com/user-attachments/assets/619ce0c0-033c-4e0b-9c64-b41eabaa791b 3. **Steal trade ships:** If the warship captures 25 trade ships, it will earn a veterancy bar. ## Please complete the following: - [x] I have added screenshots for all UI updates - [x] I process any text displayed to the user through translateText() and I've added it to the en.json file - [x] I have added relevant tests to the test directory ## Please put your Discord username so you can be contacted if a bug or regression is found: bijx	2026-07-01 21:38:09 -07:00
Ryan	1d5a6ae246	Account Modal - Games Tab (#4473) ... ## Description: Continuation of https://github.com/openfrontio/infra/pull/386, adds play games sessions <img width="971" height="771" alt="image" src="https://github.com/user-attachments/assets/42c6bcbb-d690-4cd1-b859-3299a03f4350" /> ## Please complete the following: - [x] I have added screenshots for all UI updates - [x] I process any text displayed to the user through translateText() and I've added it to the en.json file - [x] I have added relevant tests to the test directory ## Please put your Discord username so you can be contacted if a bug or regression is found: w.o.n --------- Co-authored-by: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-07-01 14:12:37 -07:00
Evan	2794ab1270	feat: nuke-trail cosmetic effect + tabbed effects picker (#4466) ... ## What Adds a **`nukeTrail`** cosmetic effectType alongside `transportShipTrail`, so nukes leave a trail colored by their own gradient/transition effect — independent of the boat-trail effect (a player can run both). Also reorganizes the effects picker and store into per-effectType **tabs**. ## Rendering Boat and nuke trails are stamped into **one** trail texture keyed only by owner, so independent coloring needs a per-tile unit-class signal: - **Trail texture** `R8UI` → `R16UI`: texel = `ownerID(bits 0-11) | nukeBit(bit 12)`. `TrailManager` stamps the bit (and preserves it when repainting on unit death); the `Uint8Array`→`Uint16Array` ripple + `UNSIGNED_SHORT` uploads flow through `GpuResources`, `TrailPass`, `Upload`, `MapRenderer`, `Renderer`, `FrameData`. - **Effect texture** widened to two stacked blocks (`TRAIL_EFFECT_BLOCKS`): rows 0–7 = transportShipTrail, rows 8–15 = nukeTrail. `writeEffectEntry(…, rowBase)`; `syncPlayerEffects` resolves both effectTypes. - **Shader** masks the owner, derives `rowBase` from the nuke bit, offsets every row, and reuses the gradient/transition decode. - Bonus: the 12-bit owner mask lifts the old `R8UI` >255-player truncation. ## Schema / server / UI - Shared attributes schema renamed `TransportShipTrail…` → **`TrailEffectAttributesSchema`** (it's no longer ship-specific); `NukeTrailEffectSchema` added to `EffectSchema` + `CosmeticsSchema.effects`. `EFFECT_TYPES = [transportShipTrail, nukeTrail]`. - Server `Privilege`, selection, and the picker grid all iterate `EFFECT_TYPES`, so they handle the new type with **no per-type code**. - **Tabs:** the selection modal uses one tab per effectType (`BaseModal`'s native tabs); the **store's** EFFECTS panel gets an internal sub-tab bar (its top-level PACKS/EFFECTS tabs can't nest). Tabs are always present, so a type you own entirely still appears as an empty tab (previously the boat-trail section vanished from the store when you owned everything). ## Review A 3-angle adversarial review (bit-packing, type-ripple, GLSL/data-flow) **refuted** the correctness concerns — the R16UI format, masking, and block layout agree across `TrailManager` / shader / builder. The minor survivors (a preview that only resolved boat trails, stale comments) were fixed. ## Testing - `tsc --noEmit`, ESLint, Prettier, `build-prod` — all clean. - Schema/`Privilege` tests updated for `nukeTrail` (96 tests pass). - The GL trail + tab UI are visual — not yet verified in a running game. - The catalog (`cosmetics.json`, closed-source API) must ship the `effects.nukeTrail` block for the effect to appear in production. 🤖 Generated with [Claude Code](https://claude.com/claude-code) --------- Co-authored-by: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-06-30 20:13:41 -07:00
Evan	cb7f721e73	Restore subscriptions in store and account modal (#4461) ... Reverts cdcc7747 ("Hide subscriptions in store and account modal behind a feature flag"). This re-adds the Subscriptions tab to the store, restores the subscription panel on the account modal, and re-enables the cosmetics fetch — removing the `SUBSCRIPTIONS_ENABLED` feature flag that gated them all behind `false`. 🤖 Generated with [Claude Code](https://claude.com/claude-code)	2026-06-30 12:35:49 -07:00
bijx	36b23d314f	QoL: Add billions to money utils (#4460) ... ## Description: A simple QoL to handle cases where money surpasses $1B. I have seen this happen in both custom games and post-game, and generally looks nicer than just showing a thousand millions. <img width="242" height="71" alt="image" src="https://github.com/user-attachments/assets/abc9adb5-2e8f-485f-93ff-47a43a019d85" /> ## Please complete the following: - [x] I have added screenshots for all UI updates - [x] I process any text displayed to the user through translateText() and I've added it to the en.json file - [x] I have added relevant tests to the test directory ## Please put your Discord username so you can be contacted if a bug or regression is found: bijx	2026-06-30 12:09:30 -07:00
TKTK123456	0d2179f5f3	Input handler.ts rework (#4225) ... > **Before opening a PR:** discuss new features on [Discord](https://discord.gg/K9zernJB5z) first, and file bugs or small improvements as [issues](https://github.com/openfrontio/OpenFrontIO/issues/new/choose). You must be assigned to an `approved` issue — unsolicited PRs will be auto-closed. **Add approved & assigned issue number here:** Resolves #4193 ## Description: Use activeKeys set in places where it is checking if a key is being pressed in a different way, and it makes more sense to use the activeKeys set. Make the overall code of the InputHandler.ts file more consistent and to make it easier to add new keybinds in the future. <img width="1920" height="1080" alt="Screenshot from 2026-06-13 20-49-56" src="https://github.com/user-attachments/assets/94f6f81c-7278-4bca-845c-2442b6caea39" /> ## Please complete the following: - [x] I have added screenshots for all UI updates - [x] I process any text displayed to the user through translateText() and I've added it to the en.json file - [x] I have added relevant tests to the test directory ## Please put your Discord username so you can be contacted if a bug or regression is found: tktk1234567	2026-06-30 14:17:25 +00:00
Evan	200f276ab2	feat: transport-ship trail transition effect + animated store swatch (#4455) ... ## What Adds a second transport-ship trail style, **transition**, alongside the existing **gradient** (#4454). Where `gradient` paints a spatial band of colors along the trail, `transition` makes the whole trail one color at a time, cross-fading through the color list over time. ```json "attributes": { "type": "transition", "colors": ["#002aff", "#4805ff"], "frequency": 1 } ``` ## How - **Schema** ([CosmeticSchemas.ts](src/core/CosmeticSchemas.ts)) — `TransportShipTrailAttributesSchema` is now a discriminated union on `type`: - `gradient`: `{ colors, colorSize, movementSpeed }` - `transition`: `{ colors, frequency }` — `frequency` = color changes per second. - **Renderer** — the effect texture gained a `styleId` discriminator (row 1's alpha; 0 = gradient, 1 = transition), with the gradient scalars shifted down a row. - [WebGLFrameBuilder.ts](src/client/WebGLFrameBuilder.ts) encodes `styleId` + the style's scalars. - [trail.frag.glsl](src/client/render/gl/shaders/map-overlay/trail.frag.glsl): for `transition`, the trail color is `mix(colors[i], colors[i+1], fract(t))` with `i = floor(uTime · frequency) mod count` — one color step every `1/frequency` seconds. - **Store/picker swatch** ([EffectPreview.ts](src/client/components/EffectPreview.ts)) — the swatch is now a `<trail-swatch>` Lit element. For `transition` it cross-fades through the colors via the Web Animations API, timed to match the shader (each step `1/frequency` s); gradient/solid stay static. The animation is canceled on disconnect. ## Notes - Animation is render-only (local time) — no simulation/determinism impact. - `gradient` swatches remain static (they don't scroll like the in-game trail) — easy to add later if wanted. ## Testing - `tsc --noEmit`, ESLint, Prettier, `build-prod` all clean. - Schema tests cover the transition member (parse + required `frequency`); 95 tests pass. - The animated swatch is visual-only (no automated coverage) and not yet verified in a running store. 🤖 Generated with [Claude Code](https://claude.com/claude-code) --------- Co-authored-by: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-06-29 21:53:33 -07:00
Evan	7c151e76ad	feat: render transport-ship trail cosmetic as a gradient (#4454) ... ## What Renders the `transportShipTrail` cosmetic effect in-game. Transport ships already left a trail, but it was always drawn in the player's **territory color** — this wires the selected effect through to the renderer so the trail shows the player's chosen **gradient**. ## How - **Per-player effect texture** (`RGBA32F`, mirrors the palette texture) keyed by `smallID`, sampled by the trail fragment shader. Each row holds a gradient color; spare alpha channels carry the color count, `colorSize`, and `movementSpeed`. - **Shader** ([trail.frag.glsl](src/client/render/gl/shaders/map-overlay/trail.frag.glsl)) cycles a flowing gradient through the color list: 1 color → flat, 2+ → animated bands scrolling along the trail. No effect (count 0) falls back to the territory color; alt-view keeps affiliation colors. - **WebGLFrameBuilder** resolves each player's catalog attributes (the in-game cosmetic is only `{ name, effectType }`; the style/colors live in the catalog) and encodes them. Resolution is decoupled from the first-seen palette path so it retries until the catalog loads, and unparseable colors are dropped so bad catalog data degrades to the territory color rather than rendering black. ## Schema Collapses the trail attributes to a single gradient shape: ```ts { type: "gradient", colors: string[], colorSize: number, movementSpeed: number } ``` - `colors` — solid = one color, rainbow = the spectrum, gradient = two or more. - `colorSize` — band width (tiles per color band; `1` is the default, ~4 tiles). - `movementSpeed` — scroll rate along the trail (tiles/sec; `0` = static). ## Notes - Animation is render-only (local time), no simulation/determinism impact. - The catalog (`cosmetics.json`, served by the closed-source API) must ship effects in this `{ type: "gradient", colors, colorSize, movementSpeed }` shape. - Band thickness (`4.0` base in the shader) and the gradient frequency are visual constants picked without in-game verification — easy to tune. ## Testing - `tsc --noEmit`, ESLint, Prettier, `build-prod` all clean. - Schema + Privilege test suites updated for the gradient shape (92 tests pass). - Not yet visually verified in a running game (effect selection is flare-gated). 🤖 Generated with [Claude Code](https://claude.com/claude-code) --------- Co-authored-by: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-06-29 20:28:47 -07:00
evanpelle	f4b47ce06c	feat: add search bar to effects picker modal ... Mirror the flag/pattern modals with a search input in the EffectsModal header. Filters the effects grid by name — matching either the raw effect id or its displayed label — and hides the Default tile while searching, the same way FlagInputModal hides its no-flag tile. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-06-29 16:38:37 -07:00
Ryan	dae129c6a3	replace leave lobby popup with custom popup (#4449) ... ## Description: old: <img width="1009" height="491" alt="image" src="https://github.com/user-attachments/assets/0b95877c-dac7-4025-bdfa-62ab6879d208" /> new: <img width="1017" height="561" alt="image" src="https://github.com/user-attachments/assets/cfb49b31-eb46-4d64-bd9e-3f25bb7cd0fb" /> ## Please complete the following: - [x] I have added screenshots for all UI updates - [x] I process any text displayed to the user through translateText() and I've added it to the en.json file - [x] I have added relevant tests to the test directory ## Please put your Discord username so you can be contacted if a bug or regression is found: w.o.n	2026-06-29 16:16:46 -07:00
Antonio Lentini	e196d399b4	feat: Change factory icons from circles to hexagons (#4439) ... Resolves #4413 ## Description: The factory and city icons are currently undistinguishable when zooming out, this PR changes the factory icon to be hexagon-shaped. It also increases the icon scale (now equal to port) to put some padding around. *Before* <img width="159" height="154" alt="Before" src="https://github.com/user-attachments/assets/2967fbc1-c775-4281-9592-6a52cbadd5a4" /> *After (with `scale = 1.0`)* <img width="133" height="135" alt="After (with `scale = 1.0`)" src="https://github.com/user-attachments/assets/f2bb9d8a-2f41-434a-b4df-9c1475f51cce" /> *After (with `scale = 1.08`)* <img width="192" height="191" alt="After (with `scale = 1.08`)" src="https://github.com/user-attachments/assets/c81026d2-f6fe-4115-a00e-e7490d342787" /> ## Please complete the following: - [X] I have added screenshots for all UI updates - [X] I process any text displayed to the user through translateText() and I've added it to the en.json file - [X] I have added relevant tests to the test directory ## Please put your Discord username so you can be contacted if a bug or regression is found: lents	2026-06-29 13:42:36 -07:00
Ryan	a05ab1bd60	fix broken import... oops (#4448) ... > **Before opening a PR:** discuss new features on [Discord](https://discord.gg/K9zernJB5z) first, and file bugs or small improvements as [issues](https://github.com/openfrontio/OpenFrontIO/issues/new/choose). You must be assigned to an `approved` issue — unsolicited PRs will be auto-closed. **Add approved & assigned issue number here:** Resolves #(issue number) ## Description: Describe the PR. ## Please complete the following: - [ ] I have added screenshots for all UI updates - [ ] I process any text displayed to the user through translateText() and I've added it to the en.json file - [ ] I have added relevant tests to the test directory ## Please put your Discord username so you can be contacted if a bug or regression is found: DISCORD_USERNAME	2026-06-29 13:41:09 -07:00
Ryan	6a884eba1b	store popup (#4435) ... ## Description: change the generic popup: <img width="1095" height="540" alt="image" src="https://github.com/user-attachments/assets/94d2c120-5ec5-4838-b8b4-09d43b4e83f8" /> into a popup i added for clan system: <img width="1108" height="774" alt="image" src="https://github.com/user-attachments/assets/d7de1666-7667-4422-a1bd-03b90b4ff8ab" /> caps doesn't have a "buy" button: <img width="1141" height="803" alt="image" src="https://github.com/user-attachments/assets/d26dd397-1f14-4963-8ac8-afa5f32ed8ec" /> also works for win modal: <img width="1023" height="766" alt="image" src="https://github.com/user-attachments/assets/83f7bc87-0ecc-4470-b84d-c5783560d6a3" /> ## Please complete the following: - [x] I have added screenshots for all UI updates - [x] I process any text displayed to the user through translateText() and I've added it to the en.json file - [x] I have added relevant tests to the test directory ## Please put your Discord username so you can be contacted if a bug or regression is found: w.o.n --------- Co-authored-by: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-06-29 13:24:09 -07:00
Evan	0f1a95cbeb	Restore default terrain colors changed by #4391 (#4447) ... ## Description The terrain colors settings refactor (#4391) inadvertently changed the **default** land terrain colors. The PR moved the hardcoded terrain colors into configurable settings, but the new default hex values in `render-settings.json` — combined with the new shading math — no longer reproduced the original sand/plains/highland appearance. In particular the new shading formulas use each JSON color as a *base* and apply offsets differently (e.g. highland now adds `2*(magnitude-10)` instead of `2*magnitude`), so the default hex values needed to compensate. ## Fix Surgical, JSON-only change to the defaults so the new formulas produce **pixel-identical** output to the pre-#4391 code: | Terrain | Was (#4391) | Restored | | --- | --- | --- | | sand | `#CC9E9E` | `#CCCB9E` | | plains | `#BECD8A` | `#BEDC8A` | | highland | `#C8B78A` | `#DCCB9E` | | mountain | `#e6e6e6` | `#e6e6e6` (unchanged) | | ocean | `#4785b5` | `#4785b5` (unchanged) | The settings/UI machinery from #4391 stays intact and users can still override colors — only the defaults are corrected. Verified across all magnitude/shoreline combinations that the rendered land colors match the original output exactly. 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-authored-by: Claude Opus 4.8 <noreply@anthropic.com>	2026-06-29 13:16:31 -07:00
Evan	bd9ef9a317	feat: effects cosmetic category (transport-ship trail) + UI (#4418) ... ## What Adds a new **`effects`** cosmetic category alongside `skins`/`flags`. Each effect is discriminated by **`effectType`** (only `transportShipTrail` today), whose visual config lives in **`attributes`** (`solid` / `rainbow` / `pulse` / `gradient`). Schema matches the production cosmetics.json shape exactly (incl. the `url` field). **This PR is UI + taxonomy only — the in-game WebGL trail rendering is intentionally deferred.** ## UI - **Store** gains an **"Effects"** tab. - **Home page** gains an **"Effects"** button opening a picker modal. - Both render effects **grouped by `effectType` with a sub-header per type**, via a shared `<effects-grid>` Lit element (`mode="select"` for the picker, `mode="purchase"` for the store). The picker shows owned effects + a Default tile and persists per-type; the store shows purchasable effects. ## Data flow - Ownership via `effect:*` / `effect:<name>` flares (reuses `cosmeticRelationship`). - Selection is a per-`effectType` map persisted in UserSettings (`settings.effects`). - Server validates in `isEffectAllowed`, wired into `isAllowed`. - `getPlayerCosmeticsRefs` / `getPlayerCosmetics` resolve effects the same way as skins/flags (kept-on-fetch-failure, server is authority). ## Tests - `tsc --noEmit`, ESLint, Prettier clean; full suite green. - New: `CosmeticSchemas` parse tests (incl. parsing the **real** `read_transport_trail` entry), `UserSettings` per-type selection, and `Privilege` effect validation. ## Notes / follow-ups - The effect's display label shows **"Boat Trail"** for the `transportShipTrail` type (friendlier than the id). - Closed-source API gap: `/shop/purchase` (`purchaseWithCurrency`) needs to learn `"effect"` for **currency** purchase of effects; the **dollar/product** purchase path already works. Client types were widened accordingly. - In-game wake rendering can be ported from #4416. 🤖 Generated with [Claude Code](https://claude.com/claude-code) --------- Co-authored-by: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-06-29 13:13:48 -07:00
bijx	06d505ebc9	feat: Expand maps button (#4431) ... ## Description: QoL fix w.r.t. "All" maps category. Maps used to all be shown in a big list, now the category sections need to be expanded one by one. Categories are super clean and useful, but to visually see and pick maps when you're not certain which one you want to play becomes challenging (to click and expand each category manually). This just adds a simple "Expand All" and "Collapse All" button to the all category list on Solo and Private Match screens. https://github.com/user-attachments/assets/e5d7a754-a6b6-461c-b039-7b6a8d3bee46 ## Please complete the following: - [x] I have added screenshots for all UI updates - [x] I process any text displayed to the user through translateText() and I've added it to the en.json file - [x] I have added relevant tests to the test directory ## Please put your Discord username so you can be contacted if a bug or regression is found: bijx	2026-06-28 19:19:22 -07:00
Ryan	966dcf47a5	removes the "subscribe" and "purchase" text (#4436) ... ## Description: removes the "subscribe" and "purchase" text: <img width="988" height="496" alt="image" src="https://github.com/user-attachments/assets/9566b450-0943-4684-8321-8024422bbd96" /> <img width="993" height="505" alt="image" src="https://github.com/user-attachments/assets/f26bfd99-661d-48e3-beb3-e3e5d212e6f1" /> <img width="1002" height="511" alt="image" src="https://github.com/user-attachments/assets/c8f2aadf-15d1-4e29-8142-f684c6e492f0" /> this is what it looks like if you're subbed to something now: <img width="997" height="491" alt="image" src="https://github.com/user-attachments/assets/5f011213-7ced-4a64-860e-45a6b0a7418f" /> ## Please complete the following: - [x] I have added screenshots for all UI updates - [x] I process any text displayed to the user through translateText() and I've added it to the en.json file - [x] I have added relevant tests to the test directory ## Please put your Discord username so you can be contacted if a bug or regression is found: w.o.n	2026-06-28 18:41:32 -07:00
Antonio Lentini	d42b095304	fix: Remove FFA collusion warnings on replay and ranked (#4414) (#4434) ... > **Before opening a PR:** discuss new features on [Discord](https://discord.gg/K9zernJB5z) first, and file bugs or small improvements as [issues](https://github.com/openfrontio/OpenFrontIO/issues/new/choose). You must be assigned to an `approved` issue — unsolicited PRs will be auto-closed. **Add approved & assigned issue number here:** Resolves #4414 ## Description: The 2 lines added check whether it's a replay or a ranked game. If so, don't show the FFA collusion warning ## Please complete the following: - [X] I have added screenshots for all UI updates (couldn't sign in via the dev server) - [X] I process any text displayed to the user through translateText() and I've added it to the en.json file - [X] I have added relevant tests to the test directory ## Please put your Discord username so you can be contacted if a bug or regression is found: lents (not in the development server yet, sent request to join)	2026-06-28 13:34:39 +00:00
Ryan	c622e8581c	collapse skins under one banner (#4432) ... ## Description: merges skins under one item with a circular button below it: <img width="877" height="647" alt="image" src="https://github.com/user-attachments/assets/a405ba34-a970-4e8c-9287-fe0055d6a02e" /> ## Please complete the following: - [x] I have added screenshots for all UI updates - [x] I process any text displayed to the user through translateText() and I've added it to the en.json file - [x] I have added relevant tests to the test directory ## Please put your Discord username so you can be contacted if a bug or regression is found: w.o.n	2026-06-27 19:09:05 -07:00
FloPinguin	95171fd995	Fix lobby status bar scrolling out of view when many players join 🎯 (#4425) ... ## Description: Make the lobby status bar (status label + player count) sticky at the bottom of the player list scroll area in JoinLobbyModal. Previously, when many players joined a lobby the status bar would scroll out of view. The bar is now pinned with `sticky bottom-0` and has a semi-opaque blurred background (`bg-black/60 backdrop-blur-md`) to cleanly occlude content scrolling behind it. **Before:** <img width="951" height="789" alt="image" src="https://github.com/user-attachments/assets/8a2a2f1d-1530-4f13-82be-837eaaa00256" /> **With this PR:** <img width="938" height="688" alt="image" src="https://github.com/user-attachments/assets/6c5259fb-a969-4a5f-b951-a4310f6c68c0" /> ## Please complete the following: - [X] I have added screenshots for all UI updates - [X] I process any text displayed to the user through translateText() and I've added it to the en.json file - [X] I have added relevant tests to the test directory ## Please put your Discord username so you can be contacted if a bug or regression is found: FloPinguin	2026-06-27 10:14:56 -07:00
Vivacious Box	2bd203968f	Add terrain colors settings (#4391) ... ## Description: Add terrain color settings for all terrain types <img width="977" height="485" alt="image" src="https://github.com/user-attachments/assets/ac1cef11-4b1a-45f2-8cf6-94f557ba8f6e" /> ## Please complete the following: - [x] I have added screenshots for all UI updates - [x] I process any text displayed to the user through translateText() and I've added it to the en.json file - [ ] I have added relevant tests to the test directory ## Please put your Discord username so you can be contacted if a bug or regression is found: MR. Box	2026-06-25 18:12:17 -07:00
evanpelle	f025f89b96	feat: speed up spawn-phase ring pulse for better visibility ... Bump spawnOverlay animSpeed 0.005 -> 0.008 so the breathing pulse on spawn-phase highlight rings cycles faster, making own and teammate spawn locations easier to spot. Addresses reports that players had trouble finding their teammates during the spawn phase in team games.	2026-06-25 11:30:52 -07:00
Evan	181368f962	Add live game stats endpoint to the admin bot API (#4399) ... ## Summary The game simulation runs **client-side**, so the server can't directly see what's happening in a running game. This adds a way for the admin bot to observe a live game: clients report a live stats snapshot every ~10s, the server reaches consensus on it (reusing the winner's vote mechanism), and a new admin-bot endpoint serves it. ## How it works 1. **`LiveStatsController`** (client) emits a snapshot every **100 turns** (~10s at 100ms/turn) — only deterministic sim values, with players sorted by clientID, so in-sync clients produce an identical payload. 2. The snapshot is sent as a new **`live_stats`** wire message wrapping a `LiveStats` object (`turn` + per-human-player `tilesOwned`/`troops`/`gold`/`isAlive`/`team`). 3. **`GameServer.handleLiveStats`** tallies a per-turn **IP-weighted majority vote** — the same consensus the winner uses — and keeps the latest agreed snapshot. 4. **`GET /api/adminbot/game/:id/stats`** returns it, enriched with usernames the server already holds. `liveStats` is `null` until the first consensus. The winner's vote tally was extracted into a small reusable **`VoteRound`** (`src/server/VoteTally.ts`) and is now used for both winner and live-stats consensus. Names are deliberately **excluded** from the voted payload (they vary per client under name anonymization, which would break exact-match consensus); the server joins `clientID → username` instead. ## Changes - `src/server/VoteTally.ts` *(new)* — reusable IP-weighted `VoteRound` - `src/core/Schemas.ts` — `PlayerLiveStatsSchema`, `LiveStatsSchema`, `ClientSendLiveStatsSchema` + unions - `src/client/controllers/LiveStatsController.ts` *(new)* — per-100-turn snapshot reporter - `src/client/Transport.ts` — `SendLiveStatsEvent` + sender - `src/client/hud/GameRenderer.ts` — register the controller - `src/server/GameServer.ts` — refactor winner onto `VoteRound`; add live-stats consensus + `liveStats()` accessor - `src/server/AdminBotRoutes.ts` — `GET …/stats` endpoint ## Testing - **Unit:** `tests/server/VoteTally.test.ts` (majority/dedup/ties), `tests/server/LiveStats.test.ts` (consensus, disagreement, per-client dedup, stale-turn rejection, turn advance, out-of-sync exclusion, + endpoint 200/404/400). Full suite green (`npm test`), typecheck + lint clean. - **Manual e2e** against the dev server: created an admin-bot game, joined it in a browser, force-started via `toggle_game_start_timer`, and confirmed `GET …/stats` returned the consensus snapshot with username enrichment and an advancing `turn`. Also verified wrong-worker → 400 and missing-key → 401. 🤖 Generated with [Claude Code](https://claude.com/claude-code) --------- Co-authored-by: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-06-24 15:21:52 -07:00
Ryan	8ffb19d938	Discord (#4367) ... Resolves #(issue number) ## Description: continuation of https://github.com/openfrontio/infra/pull/359 adds ability to put discord URL into a dedicated slot pc: <img width="1917" height="921" alt="image" src="https://github.com/user-attachments/assets/100a25d5-e998-4744-904e-df40b74ccd76" /> mobile: <img width="385" height="826" alt="image" src="https://github.com/user-attachments/assets/de904f83-c88f-41e7-9c98-81c2296ec9a2" /> ## Please complete the following: - [x] I have added screenshots for all UI updates - [x] I process any text displayed to the user through translateText() and I've added it to the en.json file - [x] I have added relevant tests to the test directory ## Please put your Discord username so you can be contacted if a bug or regression is found: w.o.n --------- Co-authored-by: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-06-24 15:15:05 -07:00
Zixer1	8ce5f3439c	feat: kick_player can target a publicId (admin bot) (#4403) ... ## Description: Add an optional `targetPublicId` to KickPlayerIntent; the server resolves it against the connected clients to the live clientID, then kicks as before. Existing clientID targeting (lobby / in-game kick) is unchanged. That way you can kick player with both the clientID and playerID ## Please complete the following: - [x] I have added screenshots for all UI updates - [x] I process any text displayed to the user through translateText() and I've added it to the en.json file - [x] I have added relevant tests to the test directory ## Please put your Discord username so you can be contacted if a bug or regression is found: zixer._	2026-06-24 14:34:17 -07:00
Zixer1	3b84a6f569	Feat/anonymize names (#4318) ... **Add approved & assigned issue number here:** Resolves #4296 ## Description: Adds an "Anonymous players" option to private lobbies (host toggle, off by default). When it is on, the server sends each client anonymized usernames for everyone except themselves. The lobby creator and admins still see real names so they can moderate. Names are hidden on every player-facing surface: the game start message, lobby info, /api/game/:id, and the link preview. It is enforced server-side, so a client extension cannot read real names off the wire. Initially added as part of our overhaul of OpenFront masters, but this feature can very well be useful for content creators, and other tournament hosts. Anonymized names reuse the existing tribe word lists (no emoji), so they pass UsernameSchema, and they are seeded per user, so a player looks different to different users but stays consistent from the lobby into the game. The saved game record keeps real names (anonymization is a per-send transform, gameStartInfo is never mutated), so replays and stats are unaffected. Nothing changes for normal games. New option selection: <img width="990" height="918" alt="image" src="https://github.com/user-attachments/assets/31df0b0b-7757-4b2b-9bff-84310faee8d9" /> The host, when enabling the option, gets a little eye icon next to the players(including himself to enable/disable the anon names for himself, and/or other player) By default(the names everyone will see are random and unique): <img width="979" height="188" alt="image" src="https://github.com/user-attachments/assets/f0caa4a4-9f14-41d3-89c6-9a38e8c2e6f0" /> Toggling the eye ON for yourself (the host, or any given player, will allow them to see the real names of everyone, in the lobby and in game): <img width="969" height="138" alt="image" src="https://github.com/user-attachments/assets/89abf0e0-1433-43ea-9870-49d96ca46d30" /> ## Please complete the following: - [x] I have added screenshots for all UI updates - [x] I process any text displayed to the user through translateText() and I've added it to the en.json file - [x] I have added relevant tests to the test directory ## Please put your Discord username so you can be contacted if a bug or regression is found: zixer._	2026-06-24 07:54:44 -07:00
Demonessica	d01be405c7	Cache maxTroops during leaderboard update (#4379) ... **Add approved & assigned issue number here:** Resolves #4316 ## Description: At the beginning of the leaderboard update cycle, evaluates `maxTroops` once for each `PlayerView` and uses the cached value for the rest of the `maxTroops` lookups in the function. Measured a reduction in `updateLeaderboard` processing time from 6ms/sec down to 2ms/sec (measured over the first minute of a singleplayer game on world map and default settings). ## Please complete the following: - [ ] I have added screenshots for all UI updates - [ ] I process any text displayed to the user through translateText() and I've added it to the en.json file - [ ] I have added relevant tests to the test directory ## Please put your Discord username so you can be contacted if a bug or regression is found: Demonessica	2026-06-23 17:19:40 -07:00
unne27	06cc01668b	Fix non-structures being deleteable (#4385) ... Resolves #4307 ## Description: Adds a check for the "delete" element of the raidial menu, to make sure the unit attemped to be removed is a structure. Previously, non-structure units such as trains could be deleted using the menu. ## Please complete the following: - [ ] I have added screenshots for all UI updates (No UI updates) - [ ] I process any text displayed to the user through translateText() and I've added it to the en.json file (No text added) - [ ] I have added relevant tests to the test directory (Not sure how this works or if it's needed) ## Please put your Discord username so you can be contacted if a bug or regression is found: unne27 --------- Co-authored-by: unne27 <uno.gunnar.johansson@gmail.com>	2026-06-23 17:17:57 -07:00
Evan	c55ea6bb5a	Mint game ids on the server, randomly route create-game across workers (#4393) ... ## What Game creation no longer requires the caller to pick the `gameID` or compute its owning worker. The client POSTs to a prefix-less `/api/create_game`; **nginx (prod) and the vite dev proxy randomly route it to a worker**, which **mints an id that hashes back to itself** and returns it along with its `workerIndex`. ## Why it stays correct The minted id still hashes to the creating worker (via the existing `generateGameIdForWorker`), so everything downstream that derives the worker from the gameID — websocket connect, share URL, join flow — keeps working unchanged. The only thing that moved is *who picks the id and worker*. ## Changes - **`src/server/Worker.ts`** — factor create into a shared `createGameForId`; add `POST /api/create_game` (no id) that mints a self-owned id and returns `gameInfo` + `workerIndex`/`workerPath`. The existing `POST /api/create_game/:id` stays. - **`nginx.conf`** — `location = /api/create_game` proxies to a `random` worker upstream. - **`generate-nginx-upstream.sh` + `Dockerfile`** — the entrypoint generates that upstream from `NUM_WORKERS` at container **start** time. `NUM_WORKERS` isn't known at image build time (the image is built once and deployed with different env), so it can't be baked into `nginx.conf` — hence runtime generation of exactly the live worker ports (no dead-server padding). - **`vite.config.ts`** — dev-only middleware forwards `POST /api/create_game` to a random worker. Vite's `http-proxy` can't pick a per-request random target, so this is a small middleware plugin (same pattern as the existing `serveProprietaryDir`), registered before the `/api` proxy. - **`src/client/HostLobbyModal.ts`** — stop generating the id client-side; use the server's. ## Behavior change to note The host's share link used to be copied **instantly** from a client-generated id. Now the id comes from the server, so the copy waits one create round-trip — I moved the URL build/copy into the create `.then` (and kept the failure path that clears the clipboard). Brief empty-link state in the modal until create resolves. ## Verification - tsc + eslint clean; full suite green (1543 tests). - nginx additions validated with `nginx -t` in isolation (the full file references container-only paths like `/etc/nginx/mime.types`); upstream + `proxy_pass` resolve. - `generate-nginx-upstream.sh` tested with `NUM_WORKERS` set and unset (defaults to 1). Not yet exercised live end-to-end (needs a dev-server restart — `vite.config.ts` + `Worker.ts` changes aren't hot-reloaded). 🤖 Generated with [Claude Code](https://claude.com/claude-code) --------- Co-authored-by: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-06-23 17:15:09 -07:00
evanpelle	5a097317cb	fix(render): make train tracks visible from farther out ... Lower railroad railMinZoom from 4 to 3 so train tracks start rendering at a more zoomed-out level.	2026-06-22 13:07:13 -07:00
Evan	97b689f2d1	Add structure dots toggle to graphics settings (#4356) ... ## What Adds an on/off **Structure dots** toggle to the graphics settings modal (Structure Icons section), controlling whether structures collapse into small dots when zoomed out. ## How The renderer already gates the dots LOD on `structure.dotsZoomThreshold` (structures become dots when `zoom <= threshold`). The debug GUI exposes that threshold as a slider; this surfaces a simple player-facing toggle: - `GraphicsOverrides.ts` — adds `structure.showDots` (boolean) to the override schema. - `RenderOverrides.ts` — when `showDots === false`, `applyGraphicsOverrides` sets `dotsZoomThreshold = 0`. Since zoom is always > 0, the dots LOD never triggers, so structures keep their full icon at every zoom. When enabled (default), the threshold is left untouched. - `GraphicsSettingsModal.ts` — toggle button mirroring the existing Classic icons / Classic level numbers toggles; defaults to On. - `en.json` — `structure_dots_label` / `structure_dots_desc`. The change applies live: a `settings.graphics` change re-runs `applyGraphicsOverrides` onto the live settings object the passes read each frame, and `dotsZoomThreshold` is a per-frame uniform. ## Testing - `tsc --noEmit` clean. - Verified in a headless solo game: the toggle renders (default On), flipping it persists `structure.showDots = false`, and `applyGraphicsOverrides` yields `dotsZoomThreshold` 1.2 when on / 0 when off. 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-authored-by: Claude Opus 4.8 <noreply@anthropic.com>	2026-06-22 12:58:30 -07:00
evanpelle	8536f1bc10	fix(events): make donation received events blue instead of green ... Donation events were split into DONATION_SENT/DONATION_RECEIVED, and DONATION_RECEIVED was grouped with the green "success" colors. In v31 all player donations (sent and received) were blue. Move DONATION_RECEIVED back to the blue group so both directions render blue again. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-06-22 12:52:36 -07:00
evanpelle	cbf1e5c513	Make host lobby start button yellow during countdown ... Add a `warning` variant to o-button that reuses the existing `--color-cyber-yellow` brand token, and apply it to the host lobby's start button while the "Starting in Xs" countdown is active. The button stays primary blue in the Waiting/Start states.	2026-06-22 12:46:18 -07:00
Evan	17ee294d5b	Surface alliance renewal & rejection events in important-events panel (#4354) ... ## Problem The important-events notification panel splits events into a prominent **tier-1** list and a dim, auto-expiring **tier-2** list (capped at the 4 newest entries). Two alliance notifications were landing in tier-2, making them easy to miss: - **"X wants to renew your alliance"** (`RENEW_ALLIANCE`) — the core simulation still sends this when another player requests a renewal, but it was buried in tier-2, so you couldn't reliably tell whether someone had asked to renew. - **"X rejected your alliance"** (`ALLIANCE_REJECTED`) — also tier-2, so the outcome of a sent request was inconsistent (accepted was prominent, rejected was not). ## Fix Add `MessageType.RENEW_ALLIANCE` and `MessageType.ALLIANCE_REJECTED` to `TIER_1_TYPES` in `EventsDisplay.ts`, so they show prominently alongside the already-tier-1 `ALLIANCE_ACCEPTED` event. No core/simulation changes — the messages were already being emitted; only the client presentation needed fixing. Display styling for both message types already exists in `Utils.ts`. 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-authored-by: Claude Opus 4.8 <noreply@anthropic.com>	2026-06-22 12:40:54 -07:00