mirror of
https://github.com/openfrontio/OpenFrontIO.git
synced 2026-06-27 06:14:36 +00:00
5a8895ff4e3011f9b22c26fec2b4544a46e32036
4086 Commits
| Author | SHA1 | Message | Date | |
|---|---|---|---|---|
 Zixer1
|
5a8895ff4e |
Ofm tournament - Log Final standings and Per-Kill eliminations (#4350)
**Add approved & assigned issue number here:** Resolves #4349 ## Description: The infra related PR is linked to this one and would need to be pushed first (376) Two changes for organized/tournament matches: 1. **Final standings.** `setWinner` snapshots each player's tiles owned at game end into `PlayerStats` (`finalTiles`). It's a deterministic integer captured in the sim, so it's replay-safe and rides into the existing game record. This lets standings be derived directly (winner, then surviving players by territory, then eliminated players by when they died) without re-simulating, which matters because a domination win ends with many players still alive. 2. **Per-kill log**. Records, per player, which humans they eliminated and at what tick (kills on PlayerStats). This lets standings attribute each kill to the victim's final placement, and gives a deterministic kill graph for integrity review. Hooked once in conquerPlayer (the single elimination funnel), humans only. Additive optional field that rides the existing game record, no archive or wire changes. These are off by default with no effect on normal play. ## Please complete the following: - [x] I have added screenshots for all UI updates (no UI changes in this PR) - [x] I process any text displayed to the user through translateText() and I've added it to the en.json file (no new user-facing text) - [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._ |
||
|
evanpelle
|
b22f422728 |
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. |
||
|
Zixer1
|
ce1ec0b59b |
fix: kick_player can target a disconnected account by publicId (#4409)
## Description: kick_player resolved a targetPublicID only against activeClients, but a client is dropped from activeClients on socket close (so players technically can disconnect right before getting kicked, then reconnect at a later point and continue playing), aka a disconnected account cannot not be kicked. Fall back to allClients (which persists) so the kick lands and bans the persistentID, blocking rejoin and reconnect. ## 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._ |
||
|
TKTK123456
|
10cd4fc63f |
Fixed rail network path length limit and readded tests for it (#4406)
> **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 #4396 ## Description: Makes the max rail length 1.4142 * the max station radius to be minimum amount outside of the factory effect radius. Bug: <img width="1921" height="1078" alt="image" src="https://github.com/user-attachments/assets/91b3b3fa-037a-4d9a-b06b-afe2fe2c8ea8" /> Fixed: <img width="1922" height="1079" alt="image" src="https://github.com/user-attachments/assets/3719cf73-bc41-494f-9d86-548f308f5896" /> ## 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 |
||
|
Zixer1
|
21cf870613 |
feat: include publicID in admin-bot live stats players (#4404)
## Description: The live stats endpoint enriches each player with username/connected but not publicId, so an account-keyed caller (e.g. an admin bot, which knows players by account, not per-session clientID) can't map a stats row back to a player directly. Add publicId from the same activeClients source — mirrors the kick_player targetPublicID path. ## 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._ |
||
|
Evan
|
8049ebcc7a |
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> |
||
|
Zixer1
|
3f0592f84e |
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._ |
||
|
Zixer1
|
119c523cf8 |
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._ |
||
|
Evan
|
7ad49df4e7 |
Add admin bot HTTP API for managing private games (#4388)
## What A trusted, server-side HTTP API so a bot authenticated with a shared secret can **create private games, change their settings, start them, kick players, and pause/resume** — without opening a WebSocket or joining as a player. Two endpoints under `/api/adminbot/`, reaching the owning worker via the existing `/wN/` nginx routing. They reuse the existing Zod schemas and `GameServer` methods, mirroring the WebSocket intent flow rather than inventing a new wire protocol. | Endpoint | Purpose | | --- | --- | | `POST /api/adminbot/create_game` | Create a private game; the worker mints a self-owned id and returns it (body: `GameConfigSchema.partial()`) | | `POST /api/adminbot/game/:id/intent` | Send a lobby-management intent (body: base `IntentSchema`) | ## How it works - **Auth:** `ADMIN_BOT_API_KEY` env var via the `x-admin-bot-key` header (timing-safe compare). The whole API is **disabled — 404 — when the var is unset**, so non-configured environments expose nothing. It's distinct from the per-instance `ADMIN_TOKEN`, which an external bot can't know. - **`GameServer.handleIntent`** is the unified intent dispatch for both the WebSocket `case "intent"` path and the admin-bot HTTP API. An `IntentActor` carries identity + authority (per-connection lobby-creator/role checks for the WS path; admin authority for the bot). It honors `update_game_config`, `toggle_game_start_timer`, `kick_player`, and `toggle_pause` — **on private games only** (`isPublic()` → 403). Gameplay intents and `mark_disconnected` are rejected (400). - **Private games only.** `create_game` rejects any `gameType` other than `Private` (Public *and* Singleplayer → 400); an omitted `gameType` defaults to `Private`. - **The bot is never a player.** It sends no `clientID`; the server stamps a placeholder `ADMIN_BOT_CLIENT_ID = "ADMINBOT"` (collision-proof — contains `I`/`O`, which `generateID()` never emits). A gameplay intent stamped with it would resolve to no player, so puppeteering is structurally impossible on top of the explicit 400. - **Determinism unchanged:** the only intent that reaches the sim is `toggle_pause`, via the same `addIntent` → turn queue → `ServerTurnMessage` path the WS uses. ## Notable details for review - **`hostCheats` is assigned unconditionally — on purpose.** `updateGameConfig` sets `this.gameConfig.hostCheats = gameConfig.hostCheats` unconditionally, unlike its sibling fields (which are guarded on `!== undefined`). The WS host clears cheats by re-sending the *full* config with `hostCheats: undefined`, so here `undefined` must mean "clear", not "leave unchanged". **Caveat for the admin bot**, which is a *partial*-update client: a partial `update_game_config` that omits `hostCheats` will clear it — the bot should send `hostCheats` explicitly (or a full config) when it wants to keep a previously-set value. - **Deploy wiring:** `ADMIN_BOT_API_KEY` is piped through the deploy steps' `env:` in `deploy.yml`/`release.yml` → `deploy.sh` heredoc → container via `update.sh`'s `--env-file`. The remaining manual step is creating the GitHub secret itself. ## Tests 19 new tests: - `GameServer.handleIntent` admin-bot behavior (per-intent, private-only, post-start guards, placeholder clientID, rejected gameplay/`mark_disconnected` intents). - `create_game` gameType guard (Public and Singleplayer both rejected). - `requireAdminBotKey` middleware (404 disabled / 401 missing / 401 wrong / pass). tsc + eslint clean. 🤖 Generated with [Claude Code](https://claude.com/claude-code) --------- Co-authored-by: Claude Opus 4.8 (1M context) <noreply@anthropic.com> |
||
|
Evan
|
86709be4f9 |
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> |
||
|
evanpelle
|
bb2f2f01ee |
Revert "Take off the v32 maps from the "New" category to make room for v33 maps (#4378)"
This reverts commit
v0.32.3
|
||
|
evanpelle
|
4e1f574993 |
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. |
||
|
Evan
|
6afa3e48f5 |
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> |
||
|
evanpelle
|
55916b807b |
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. |
||
|
Evan
|
68da097791 |
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> |
||
|
Berk
|
f193ca7376 |
fix(render): update coastline color dynamically when ocean color changes (#4377)
fix(render): update coastline color dynamically when ocean color changes Resolves #4329 ## Description: Previously, the shoreline water color (`isShoreline && !isLand`) was hardcoded to a static bright blue (`rgb(100, 143, 255)`) in `encodeTerrainTile`. When a user customized the ocean/water color in Settings, the deep ocean changed colors but the shoreline water remained bright blue, causing a jarred, visually mismatched appearance. This PR updates `encodeTerrainTile` in `ColorUtils.ts` to dynamically calculate the shoreline water color by scaling the configured `oceanColor` channels: - Red and Blue channels scale by `1.4` (clamped to `255`). - Green channel scales by `1.08` (clamped to `255`). This scales the coastline water color harmoniously alongside any custom water color settings (e.g. green, red, or dark ocean tones). ## Please complete the following: - [x] I have added screenshots for all UI/rendering updates (Attached `coastline_screenshot.png` showing dynamic color integration) - [ ] I process any text displayed to the user through translateText() and I've added it to the en.json file (N/A — No user-facing text additions) - [ ] I have added relevant tests to the test directory (N/A — WebGL rendering code has no automated test harness) ## Please put your Discord username so you can be contacted if a bug or regression is found: barfires |
||
|
RickD004
|
5b2a1b1134 |
Take off the v32 maps from the "New" category to make room for v33 maps (#4378)
Resolves #4375 ## Description: Remove V32 maps from "new" to make way for v33 maps. This will allow map makers to add their new maps for v33 into "new", with the v32 maps only remaining in the continental and other categories like the rest of the maps. This is a process we will make every update ## 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: tri.star1011 |
||
|
AmanorsElliot
|
11f18b93e2 |
Fix transport ship's troop count to update when a hydro hits the player. (#4381)
**Add approved & assigned issue number here:** Resolves #4308 ## Description: When nuclear damage reduces a player's troop count, it also affects any transports ships in the water. This works well and is useful to avoid exploiting tranports to avoid hydro damages. `UnitImpl.setTroops()` changes the transports troop count without queuing a unit update. the core value changes, but the client never receives a fresh UnitUpdate unless something else touches the ship. - UnitImpl.ts now emits a UnitUpdate when a unit troop count actually changes. - NukeExecution.ts batches transport ship nuke losses, then applies one final troop update per ship. - Attack.test.ts now asserts the nuke tick includes a transport UnitUpdate with the reduced troop count. ## Please complete the following: - [N/A] I have added screenshots for all UI updates - [N/A] 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: elliotlepley |
||
|
Vivacious Box
|
dcdfd7bad7 |
If player is localplayer, set structure border to territory color (#4366)
Resolves #4365 ## Description: Currently the border of icons are using borderColor which is grey for local player <img width="227" height="281" alt="image" src="https://github.com/user-attachments/assets/9e334e19-c5b2-49ca-a85d-4576a5bbc1a9" /> This set it to territory color <img width="187" height="102" alt="image" src="https://github.com/user-attachments/assets/9b9f27f9-69e2-4ae7-9f35-a789b56b45de" /> ## 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 |
||
|
Zixer1
|
18ef15d3ae |
Add allowlist for private lobbies (OFM) (#4351)
**Add approved & assigned issue number here:** Resolves #4349 ## Description: 1. **Private-lobby allowlist.** `create_game` accepts an optional `allowedPublicIds`. It's set by whoever creates the lobby (admin-token gated, no client UI), the game server pulls it out of the config so it's never broadcast to clients or written to the game record, and it rejects any joiner whose OF publicId isn't on the list before they take a slot (stickily, so they can't retry on reconnect). Lobbies created without it behave exactly as before. It is off by default Previews: <img width="241" height="140" alt="image" src="https://github.com/user-attachments/assets/30c4e47b-399d-4720-b25b-a04c63668577" /> <img width="982" height="456" alt="image" src="https://github.com/user-attachments/assets/1b5c68b7-9b99-4ccc-b987-e70c8ec25dce" /> <img width="547" height="369" alt="image" src="https://github.com/user-attachments/assets/1623090b-ea2b-4657-9cd8-903fbabca51b" /> I am not able to manually test all of it since it needs to also run the auth API (infra) and actually be connected to disc and whatnot (but still tested the refused flow).. Also, we would need to place some guards and visual error feedback, but since this only would affect casual of players and is more of a improvement to the feature, I will consider it out of scope for now. ## Please complete the following: - [x] I have added screenshots for all UI updates (no UI changes in this PR) - [x] I process any text displayed to the user through translateText() and I've added it to the en.json file (no new user-facing text) - [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._ |
||
|
Vivacious Box
|
88aad8501e |
Change css to preview the graphics settings live (#4372)
<img width="1152" height="866" alt="settings" src="https://github.com/user-attachments/assets/dff00f2e-775d-4b7e-8590-855813dcff7d" /> ## Description: Small qol change to be able to preview graphics settings changes ## 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: Mr. Box |
||
|
Evan
|
4ee68b4ea7 |
Add nuke fallout color graphics option (#4355)
## What Adds a **Nuke fallout color** option to the in-game graphics settings modal (Effects section), letting players recolor the fallout tint left on territory after a nuke.  ## How Mirrors the existing **Ocean color** override pattern: - `GraphicsOverrides.ts` — adds `staleNukeColor` (hex string) to the `mapOverlay` override schema. - `RenderOverrides.ts` — `applyGraphicsOverrides` parses the hex and writes the renderer's `staleNukeR/G/B` 0–1 float channels (`hexToRgb` yields 0–255, so it divides by 255). - `GraphicsSettingsModal.ts` — new hex-text + native color-picker row, default computed from `render-settings.json`. - `en.json` — `nuke_color_label` / `nuke_color_desc`. The value persists via `UserSettings.graphicsOverrides()` and is cleared by the modal's existing "Reset to defaults". The render debug GUI already exposes the same setting as **Stale Nuke Color** (Map Overlay), so no change was needed there. ## Testing - `tsc --noEmit` clean. - Verified in a headless solo game: the row renders with the green default (`#0d8c12`), changing it persists `mapOverlay.staleNukeColor`, and `applyGraphicsOverrides("#ff0000")` produces `staleNukeR=1, G=0, B=0`. 🤖 Generated with [Claude Code](https://claude.com/claude-code) --------- Co-authored-by: Claude Opus 4.8 <noreply@anthropic.com> |
||
|
Evan
|
cb0d79ed6d |
Add black outline to alliance icon for terrain contrast (#4353)
## Problem The green alliance icon above player names blends into similarly-colored terrain — most notably irradiated land, which is the same green — making it hard to spot allied players. ## Fix Add a configurable dark outline to the alliance status icon, rendered in the status-icon shader (the icons come from a pre-baked atlas with no regeneration script, so this is done in-shader rather than by editing the PNG). - **Outline**: an alpha dilation gated to the alliance icon (slot 3). 8-direction sampling of the icon's alpha builds a black halo around its silhouette; interior pixels and all other status icons are untouched. - **No clipping**: the alliance icon's quad is grown outward into the atlas cell's existing transparent padding so the halo isn't clipped at the quad edge. The icon's on-screen size and position are unchanged; 8px of the cell's 16px mipmap-safety padding is preserved. - **Drain stays aligned**: the alliance-expiry drain effect's cut line and faded-icon UVs are remapped into the expanded quad space so the animation still lines up. - **Tunable**: width is driven by `name.statusOutlineWidth` in `render-settings.json` (default 6 texels; 0 disables), with a matching "Status Outline Width" slider in the debug GUI. ## Testing `tsc` and `eslint` pass. Verified in-game: the handshake now reads clearly against irradiated terrain, with the outline rendering fully (no edge clipping) and the drain animation still aligned. 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-authored-by: Claude Opus 4.8 <noreply@anthropic.com> |
||
|
Evan
|
ad9380a35d |
Make the important events panel scrollable (#4346)
## What Cap the height of the **Tier 1 (important) events panel** and make it scroll when many events stack up, instead of letting it grow unbounded up the screen. ## Why The less-important (Tier 2) events panel was already height-capped and scrollable, but the important panel had no limit — a burst of important events (chat, nukes inbound, alliance changes, etc.) could push the panel arbitrarily tall. ## Changes (`src/client/hud/layers/EventsDisplay.ts`) - Added `max-h-[30vh] lg:max-h-[40vh] overflow-y-auto` to the important-events container. - Mirrored the existing Tier 2 auto-scroll-to-bottom behavior for the important panel (new `.important-events-container` query + scroll tracking), so the newest important events stay in view rather than being hidden below the fold. If the player scrolls up, auto-scroll pauses (same as Tier 2). ## Testing Verified in the live game by injecting 15 important events: - Panel is height-capped and scrollable (`scrollHeight 540 > clientHeight 400`). - Auto-scrolls to the newest (`scrollTop` pinned to bottom); events 5–15 visible, older ones reachable by scrolling up. lint clean. 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-authored-by: Claude Opus 4.8 <noreply@anthropic.com> |
||
|
TKTK123456
|
7d723a9e8b |
Fixed factory ghost radius (#4337)
> **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 #4323 ## Description: Made stations use euclidean distance for radius for checking if other stations are close enough, removed redundant if check and unneeded config <img width="1920" height="1080" alt="Screenshot from 2026-06-18 14-19-48" src="https://github.com/user-attachments/assets/a84f29f8-0cc1-46ea-9b96-3d70d6b0b20a" /> ## 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 |
||
|
Evan
|
d7b781f155 |
Add trade ship captured event with toggle setting (#4344)
## What Notify a player when one of their trade ships is captured. The alert appears in the **less-important (top) events tier** and is gated behind a new in-game setting (on by default). ## Why Previously there was no notification to the player who *lost* a trade ship — only the capturer got a transient +gold pip on the ship's arrival. This surfaces the loss to the victim, while letting players opt out if they find it noisy. ## Changes - **`src/core/execution/TradeShipExecution.ts`** — On capture detection, emit a display message (`events_display.trade_ship_captured`, type `UNIT_DESTROYED`) to the original owner. Fires once, guarded by the existing `wasCaptured` flag. `UNIT_DESTROYED` is not a Tier-1 type, so it lands in the top/less-important tier. - **`src/client/hud/layers/EventsDisplay.ts`** — Suppress the message when the setting is off, following the existing key-based filter pattern. - **`src/core/game/UserSettings.ts`** — New `tradeShipCapturedEvents()` getter (default `true`) + `toggleTradeShipCapturedEvents()`. - **`src/client/hud/layers/SettingsModal.ts`** — New toggle in the in-game settings modal. - **`resources/lang/en.json`** — New `events_display.trade_ship_captured` and `user_setting.trade_ship_captured_label`/`_desc` keys. - **`tests/core/executions/TradeShipExecution.test.ts`** — Tests that the notification is sent to the original owner with the right args and only once across ticks. ## Notes - The setting is gated client-side (in `EventsDisplay`), keeping `src/core` free of client-local localStorage settings — consistent with how display events are already filtered there. - Reused `MessageType.UNIT_DESTROYED` (red/"loss" styling) rather than adding a new message type, to keep the change minimal. Happy to add a dedicated type/color if preferred. ## Testing - `npx vitest tests/core/executions/TradeShipExecution.test.ts --run` — 7 passed - lint clean, no type errors 🤖 Generated with [Claude Code](https://claude.com/claude-code) --------- Co-authored-by: Claude Opus 4.8 <noreply@anthropic.com>v0.32.2 |
||
|
Evan
|
6159f1f186 |
Fix anonymous-names setting not hiding names on the map (#4345)
## Problem Enabling the **hidden names** (anonymous names) setting hid names in the leaderboard/HUD but **not on the map**. The GL name renderer (`NamePass`) drew `slot.static.displayName` — always the real name — and never consulted `userSettings.anonymousNames()`. The HUD works because it calls `PlayerView.displayName()` (which honors the setting) on each render, but the names baked into the GPU texture bypassed that path entirely. ## Fix Push the *resolved* name into the renderer instead of the raw static name: - **`WebGLFrameBuilder.syncPlayers`** registers each player with `displayName: p.displayName()` (honors the setting) instead of `static.displayName`. Covers enabling the setting before a game and players who join after a toggle. - **`WebGLFrameBuilder.refreshNames` → `MapRenderer` → `Renderer` → `NamePass.refreshNames`** is a new path that re-resolves cached names and forces a re-upload (resets `slot.nameLen = 0`, which also recomputes the name half-width so it stays centered). - **`ClientGameRunner`** listens for the `settings.anonymousNames` change event and calls `refreshNames`, mirroring the existing territory-patterns live toggle. ## Behavior - Enabled before a game → players register with anonymous names. - Toggled mid-game → map names flip to/from anonymous on the next sim tick (~100ms), matching the leaderboard. - Your own name is unaffected (unchanged — `PlayerView` maps the local player's anonymous name to their real name). ## Testing `tsc --noEmit` passes for all edited files. This is a WebGL rendering change with no straightforward unit test; verified by tracing the data flow (resolved name → cached `slot.static.displayName` → re-upload on dirty). 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-authored-by: Claude Opus 4.8 (1M context) <noreply@anthropic.com> |
||
|
Evan
|
707057f09f |
Fix ocean color change reverting nuke-created water to land (#4343)
## Problem Changing the ocean/water color in **Graphics settings** repaints the terrain — and any water tiles created by water nukes (land → water) snap back to their original land appearance. ## Root cause `TerrainPass` captures the `terrainBytes` buffer at construction and reuses it in two places: - `setOceanColor()` does a **full** terrain texture re-upload from `terrainBytes` when the ocean color changes. - `applyTerrainDelta()` applies live land→water nuke conversions, but only wrote to the **GPU texture** — never back into `terrainBytes`. So the CPU buffer stayed frozen at the map's original terrain. Changing the ocean color rebuilt the whole texture from that stale buffer, reverting every nuke crater to land. ## Fix Write each delta byte back into `terrainBytes` inside `applyTerrainDelta()`, so the buffer stays the live source of truth and full re-uploads reflect conversions. ```ts this.terrainBytes[ref] = bytes[i]; ``` The indexing already lines up — `terrainBytes` is indexed by linear ref (`y * mapW + x`), the same `ref` the delta loop iterates. The buffer is only otherwise read once at construction by `RailroadPass`/`TerrainPass` to seed GPU textures (which copy), so mutating it has no side effects elsewhere. ## Testing The WebGL passes have no unit-test harness (they need a live GL context), so this isn't covered by an automated test. Verified by reasoning through the data flow; can confirm in-game by nuking land into water and then changing the ocean color. 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-authored-by: Claude Opus 4.8 (1M context) <noreply@anthropic.com> |
||
|
Evan
|
6f8c2a5e91 |
Fix nuke preview showing teammate SAMs as threats (#4342)
## Problem In the nuke trajectory preview, the SAM-intercept **"X"** marker was drawn over **teammates'** SAMs — implying their SAM would shoot down your missile. It shouldn't: like allies, a teammate's SAM never engages your nuke. The bug only affected teammates; allies already worked. ## Cause The preview built its threat set from `myPlayer.allies()` only — formal alliances — and never considered teammates. That diverged from the sim ([`SAMLauncherExecution.ts`](src/core/execution/SAMLauncherExecution.ts#L118-L134)), which skips any nuke whose owner it's `isFriendly()` with (**same team OR allied**). ## Fix `samThreatensNukePreview` now takes a teammate set and excludes teammates **unconditionally**. The subtlety: allies keep the existing *betrayal* exception — a strike close enough to break the alliance makes that ally's SAM engage at launch (`listNukeBreakAlliance`, the same function the sim uses). Teammates get **no** such exception, because a strike can break an alliance but never a team relationship. So even a player who is both a teammate *and* a betrayed ally is correctly left off the threat set. ## Notes - The sim has an "aftergame fun" exception where teammate SAMs *do* target teammate nukes once there's a winner. The preview only appears while aiming a buildable mid-game (no winner yet), so that case doesn't apply here. ## Tests Updated `samThreatensNukePreview` unit tests for the new signature and added coverage for: teammate excluded, and teammate stays excluded even when listed as betrayed. All 11 tests pass. 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-authored-by: Claude Opus 4.8 (1M context) <noreply@anthropic.com> |
||
|
Evan
|
86599fe15b |
Hide clan tag input on CrazyGames (#4341)
## Summary Clans aren't supported on CrazyGames, so don't let players set a clan tag there. - Tag the clan tag input wrapper with the existing `no-crazygames` class so Main.ts's hiding logic removes it on CrazyGames, matching how other CrazyGames-hidden elements work. - Guard loading the stored clan tag (`loadStoredUsername`) so a tag saved on the main site isn't silently submitted in the handshake while on CrazyGames — CSS hiding alone wouldn't prevent that. - Guard storing the tag (`validateAndStore`) so a returning user's saved tag isn't clobbered with an empty value during a CrazyGames session. ## Testing - `npx tsc --noEmit` — clean (no UsernameInput errors) 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-authored-by: Claude Opus 4.8 <noreply@anthropic.com> |
||
|
Evan
|
c7fdc4ec2d |
Cap renderer device-pixel-ratio at 2 (#4339)
## What
Routes every renderer call site that read `window.devicePixelRatio`
through a single `renderDpr()` helper that caps the value at **2**.
```ts
export function renderDpr(): number {
return Math.min(window.devicePixelRatio || 2, 2);
}
```
## Why
On very high-DPI displays (DPR 3, common on phones) the WebGL backing
store was sized at 3× CSS pixels — ~9× the fragment work of 1× — for a
marginal visual gain over 2×. Capping at 2 keeps retina (DPR 2)
pixel-perfect while clamping the 3× case.
## How it stays correct
DPR isn't just the canvas size — it's one coordinate system shared by:
- the canvas backing-store size (`Renderer.resize`)
- the camera's screen↔world math (`Camera.resize` / `screenToWorld` /
`worldToScreen`)
- the camera zoom scale (`ClientGameRunner.syncCamera`)
- the constant-CSS-pixel-size world text (`WorldTextPass`)
These must all use the same DPR value or pointer hit-testing and text
sizing drift. Routing them through one helper guarantees that. The
diagnostics reporter (`Diagnostic.ts`) is intentionally left reading the
real hardware DPR, since its job is to report the actual device.
## Test
- `tsc --noEmit` clean for all touched files (one pre-existing unrelated
`marked` types error remains on `main`).
🤖 Generated with [Claude Code](https://claude.com/claude-code)
Co-authored-by: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
|
||
|
Evan
|
c9fe710700 |
Render spawn overlay with instancing to support large lobbies (#4322)
## Problem The spawn-phase overlay stored every human's spawn center in GLSL **uniform arrays** (capped at `MAX_SPAWNS = 32`) and looped over all of them **per screen pixel** in a fullscreen pass. In lobbies with more than 32 humans, centers past the cap were silently dropped in join order — so a few seconds into the spawn phase the **local player's own ring could disappear while the phase was still active**. Team modes make this worse: `playerTeams` can be a raw team count, so a single team can have far more than 32 members, all of which need rings. The two walls that blocked simply raising the constant: - **Uniform arrays cap out ~96** against WebGL2's 224-vec4 fragment floor — 1024 would never link. - The **fullscreen per-pixel loop** over every spawn is `O(pixels × spawns)` — raising the cap makes it a GPU hazard during the spawn phase. ## Fix Rewrite `SpawnOverlayPass` to draw **one instanced quad per spawn center**, sized to that center's influence radius (mirroring `SAMRadiusPass`). This removes the uniform-array limit and the per-pixel loop, so cost scales with the number of spawns rather than screen area, and the overlay supports the renderer's full ~1024-player ceiling. Instances are ordered **enemies → teammates → self** so the local player's ring composites on top under normal alpha blending. Self/teammate render as breathing rings; enemies render as tile-fill highlights on unowned tiles — identical visuals and render-settings to before. ## Changes - `gl/passes/SpawnOverlayPass.ts` — instanced rendering via `DynamicInstanceBuffer` + `drawArraysInstanced`; no `MAX_SPAWNS` cap. - `shaders/spawn-overlay/spawn-overlay.frag.glsl` — per-instance (kind-dispatched) instead of a uniform-array loop; self white→color pulse moved into the shader. - `shaders/spawn-overlay/spawn-overlay.vert.glsl` — new instanced vertex shader. ## Testing - `tsc` (full project) + `eslint` clean. - Headless WebGL run: shaders **compile and link** (game starts normally with 123 players), and the genuine `updateSpawnOverlay → update() → drawArraysInstanced()` path renders self/teammate rings and enemy tile highlights with **no GL errors**. - ⚠️ Not yet verified end-to-end in a real 30+ human FFA lobby (the original repro) — that needs multiple real clients. The instanced draw path and rendering were confirmed in singleplayer with the overlay force-activated. 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-authored-by: Claude Opus 4.8 <noreply@anthropic.com>v0.32.1 |
||
|
Evan
|
661d96ba28 |
Fix structure cost double-counting units under construction (#4320)
## Problem
The ghost/build-menu price of a structure can show the wrong (inflated)
cost. Concretely: a player who owns a **captured** city and then starts
building their **first** city sees the 3rd-city price (**500k**) for
that build instead of the 2nd-city price (**250k**).
## Root cause
Structure cost scales as `2^(units built) × base` (city: 125k / 250k /
500k …), counted via:
```ts
Math.min(player.unitsOwned(type), player.unitsConstructed(type))
```
The `Math.min` is deliberate — it caps the count at how many you've
actually **built**, so **captured** units (owned but not built) don't
inflate the price.
`unitsConstructed()` defeated that by double-counting in-progress
builds:
```ts
const built = this.numUnitsConstructed[type] ?? 0; // already includes the building unit
let constructing = 0;
for (const unit of this._units) {
if (unit.type() !== type) continue;
if (!unit.isUnderConstruction()) continue;
constructing++; // counts the SAME unit again
}
return constructing + built; // doubled
```
`recordUnitConstructed()` is called in `buildUnit()` the moment the unit
is created — while it is still under construction — so
`numUnitsConstructed` already accounts for in-progress builds. The extra
loop counted them a second time.
With one captured city + one city under construction: `unitsOwned = 2`,
double-counted `unitsConstructed = 2`, so `Math.min(2, 2) = 2` → 500k.
Without the double-count it's `Math.min(2, 1) = 1` → 250k. ✅
The redundant loop is a leftover from #2378, which removed the separate
`UnitType.Construction` unit. Back then in-progress builds were a
distinct unit type **not** recorded in `numUnitsConstructed`, so the
loop was needed; afterward it became a pure double-count. This is a
long-standing latent bug — present identically on `v31` — not a recent
regression.
## Fix
`unitsConstructed()` now just returns `numUnitsConstructed[type]`, which
already includes under-construction builds.
## Tests
`tests/economy/ConstructionCost.test.ts` covers both:
- pure case (first city under construction) → still 250k
- captured city + first city under construction → was 500k, now 250k
(fails without the fix with `expected 2 to be 1`)
All related suites (economy, PlayerImpl, nation structure behavior,
upgrades, MIRV pricing, stats) — 144 tests — pass.
🤖 Generated with [Claude Code](https://claude.com/claude-code)
Co-authored-by: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
v0.32.0
|
||
|
Evan
|
305534cc65 |
Dispose WebGL renderer when a game stops 🧹 (#4295)
## Problem `ClientGameRunner.stop()` tore down the worker, network, and sound, but left the `MapRenderer` (and its WebGL context), the WebGL canvas, the input overlay, and the self-driving RAF loop in place. When you exit a game via the **Exit button** or browser **back**, the page navigates to `/`, so the browser reclaims everything — that path is fine. But you can start a new game **without** a reload: matchmaking and joining another lobby go through `handleJoinLobby`, which calls `lobbyHandle.stop(true)` then `joinLobby()` on the same document. The old WebGL context stayed alive (the never-cancelled RAF kept it referenced, so it wasn't even GC'd), and each new game stacked another context. After a few games, mobile browsers hit their WebGL context limit — matching the repro in #4267. ## Fix `stop()` now disposes the renderer: - cancels the self-driving RAF loop and disconnects the frame-loop resize observer - disposes the `MapRenderer` (frees all GPU resources) - removes the WebGL canvas and the input overlay from the DOM `GPURenderer.dispose()` additionally calls `WEBGL_lose_context.loseContext()` so the context is released promptly instead of waiting on unreliable GC. The territory-patterns settings listener is wired to the existing graphics `AbortController` so it no longer outlives the disposed view. The cleanup runs unconditionally in `stop()` (a superseded join can stop before the game becomes active) and is idempotent against repeated `stop()` calls. Fixes #4267 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-authored-by: Claude Opus 4.8 <noreply@anthropic.com>v0.32.0-beta6 |
||
|
Evan
|
64409cae4d |
Animate HUD troop/population bars with transform instead of width (#4319)
## Problem The troop and population ratio bars in `ControlPanel` and `PlayerInfoOverlay` update their inline `width` on every game tick, with a `transition-[width] duration-200` to smooth the change. But `width` is a layout property — animating it forces the browser to **recalculate layout for the surrounding HUD components every animation frame**. Since the width changes every tick, this kept the whole HUD in a near-constant relayout loop and showed up as jank. ## Fix Keep the smooth animation, but drive it with `transform` (GPU-composited, no layout) instead of `width`: - Replace the two flex `width: %` segments with absolutely-positioned, full-width bars. - Segment 1: `transform: scaleX(green/100)` anchored to the left edge (`origin-left`). - Segment 2: `transform: translateX(green%) scaleX(orange/100)` so it stays flush against the first segment. - Animate with `transition-transform duration-200 ease-out`. Because `transform` is composited rather than laid out, the bars animate smoothly **without** triggering the per-frame HUD relayout. The segments are now always mounted (`scaleX(0)` when empty) instead of conditionally rendered, which also prevents the transition from resetting as values cross zero. Files: - `src/client/hud/layers/ControlPanel.ts` (mobile + desktop troop bars: malibu-blue / aquarius) - `src/client/hud/layers/PlayerInfoOverlay.ts` (sky-700 / malibu-blue) A grep confirmed these were the only `transition-[width]` usages in the client. ## Testing - `eslint --fix` / prettier ran clean via the pre-commit hook. - CSS-only change; no sim/behavioral logic touched. 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-authored-by: Claude Opus 4.8 (1M context) <noreply@anthropic.com> |
||
|
Evan
|
83cd864018 |
Show rail ghost for initial factory 🚂 (#4294)
## Problem Fixes #4284. When you build a factory in an area with **no pre-existing factory** (e.g. just a city nearby), no rail ghost preview appeared — even though building the factory *would* lay rail lines connecting it to that city. ## Root cause `computeGhostRailPaths` in `RailNetworkImpl.ts` had two factory-hostile assumptions: 1. It bailed out early unless a `Factory` was already in range (`hasUnitNearby(..., UnitType.Factory)`). 2. It only matched neighbors that were *already* train stations (`findStation(...)` → skipped if null). But a **Factory** always becomes a station itself and *promotes* nearby City/Port/Factory into the rail network (see `FactoryExecution`). So it needs no pre-existing factory, and its neighbors won't be stations yet on first build. A **City/Port** only joins the network when a factory already exists (`CityExecution`/`PortExecution`) — so their behavior is correctly left unchanged. ## Fix - Skip the "factory must be nearby" gate when the placed unit is itself a `Factory`. - For a factory build, pathfind to nearby City/Port/Factory even if they aren't stations yet. City/Port keep connecting only to existing stations. ## Tests Added two cases to `RailNetwork.test.ts` (factory connects with no pre-existing factory; city still doesn't without one). All 25 tests pass. ## Note on scope As @Katokoda noted on the issue, a fully build-exact preview (neighboring structures also connecting to *each other*, merging existing networks, etc.) is larger and order-dependent. This PR resolves the reported bug — the initial factory now shows its rail ghost — and leaves the exact-match cascade as a separate follow-up. 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-authored-by: Claude Opus 4.8 <noreply@anthropic.com> |
||
|
Evan
|
678112492c |
Fix per-frame layout jank when focusing a toggle-input-card field (#4314)
## Problem
Focusing the number field of a `toggle-input-card` (Game Timer / Gold
Multiplier / Starting Gold, in both the single-player and host-lobby
modals) cost several ms of layout/paint **every tick** for as long as
the field stayed focused.
## Root cause
The input was rendered **conditionally** — `${this.checked ?
html`…<input>…` : nothing}`. Enabling a toggle therefore **freshly
inserts** the `<input>` into the DOM, and **focusing a just-inserted
input** is what forced the per-frame layout/paint. An input that was
already present in the DOM doesn't do this.
## Fix
Keep the input **permanently mounted** and toggle a `hidden` class when
unchecked, instead of conditionally rendering it. Focusing it is then
always focusing an element that was already there. Because both modals
share `<toggle-input-card>`, this single change fixes both.
Also restores the **autofocus + select** of the field on enable (it had
been removed earlier while chasing this bug) — safe now that the input
isn't freshly inserted.
No other UX change: the toggle behavior, checkmark, styling, and all
three cards behave identically.
## Testing
Hard-reload, then in both the Solo and Host-lobby modals, enable each of
Game Timer / Gold Multiplier / Starting Gold, type a value, and keep the
field focused — smooth, no per-frame jank, and the field autofocuses on
enable.
🤖 Generated with [Claude Code](https://claude.com/claude-code)
Co-authored-by: Claude Opus 4.8 <noreply@anthropic.com>
|
||
|
Evan
|
bb464538d0 |
Add Fallout effects toggle to graphics settings ☢️ (#4313)
## Summary Adds a **"Fallout effects"** toggle to the *Effects* section of the graphics settings modal, letting players disable the nuclear fallout visuals (useful for performance). Fallout is rendered by two passes — the broiling green **bloom** on irradiated territory and its additive **light** contribution in day/night mode. The bloom pass was already gated by `passEnabled.falloutBloom`, but the light pass had no gate. This adds a `passEnabled.falloutLight` flag and a single user-facing `passEnabled.fallout` graphics override that drives both together. ## Changes - **`RenderSettings.ts` / `render-settings.json`** — new `passEnabled.falloutLight` flag (default `true`). - **`LightmapPass.ts`** — gate the fallout light pass behind `passEnabled.falloutLight`. - **`GraphicsOverrides.ts`** — add `fallout: z.boolean()` to the `passEnabled` override group. - **`RenderOverrides.ts`** — apply `passEnabled.fallout` to both `falloutBloom` and `falloutLight`. - **`GraphicsSettingsModal.ts`** — `currentFallout()` / `onToggleFallout()` + a toggle button (mirrors the existing Special Effects toggle). - **`en.json`** — `graphics_setting.fallout_label` / `fallout_desc`. ## Testing - `tsc --noEmit` passes; JSON files validated. 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-authored-by: Claude Opus 4.8 <noreply@anthropic.com> |
||
|
Evan
|
e6256e6269 |
Flip structure icon glyph to light on dark territory 🌑 (#4312)
## Problem
In the structure render pass, when **classic icons** are enabled the
inner icon glyph is tinted with a *darkened version of the player's fill
color* (`uIconDarken = 0.3`). When a player's territory color is already
dark, both the structure shape and its glyph render dark, so the icon
blends into the shape and the dark territory behind it — making it
effectively unreadable.
(With non-classic icons the glyph is already the light `uIconColor`, so
only the classic path was affected.)
## Fix
In `structure.frag.glsl`, when classic icons are active, compute the
fill's perceptual luminance and flip the glyph to the light icon color
(`uIconColor`, white by default) when the fill is too dark:
```glsl
vec3 glyphColor = uIconColor;
if (uIconDarken > 0.0) {
float fillLum = dot(fillColor.rgb, vec3(0.299, 0.587, 0.114));
glyphColor = fillLum < 0.25 ? uIconColor : darken(fillColor.rgb, uIconDarken);
}
```
The non-classic path is unchanged. The change is contained to the shader
— no new uniforms or plumbing.
## Notes
- The `0.25` luminance threshold is hardcoded in the shader to keep the
change surgical. It could be promoted to a `render-settings.json` knob
if preferred.
🤖 Generated with [Claude Code](https://claude.com/claude-code)
Co-authored-by: Claude Opus 4.8 <noreply@anthropic.com>
|
||
|
Evan
|
6c84919801 |
Smooth nuke point-light position per frame in ambient mode (#4311)
## Summary Follow-up to #4255. That PR made nuke **sprites** glide per render frame — `UnitPass.drawMissiles` lerps each nuke's `lastPos→pos` by wall-clock progress through the current tick. But in ambient/night mode the glow *behind* a nuke comes from a separate pass, `PointLightPass`, whose instance buffer is packed once per tick in `updateLights()` from the raw `unit.pos`. Its per-frame `draw()` (run every frame via `LightmapPass`) only set uniforms and issued the instanced draw — it never repositioned the lights. So the sprite moved at 60fps while its light jumped once per 100ms tick. ## Fix Mirror `UnitPass`'s smoothing in `PointLightPass`: - `updateLights()` records a `smoothSegs` tuple `(lightIdx, lastX, lastY, x, y)` for each `SMOOTHED_NUKE_TYPES` unit whose `lastPos !== pos`, and stamps `lastUnitsUpdateMs`. - A new `applySmoothing()`, called at the top of `draw()`, lerps those lights by wall-clock tick progress (`(now - lastUnitsUpdateMs) / tickIntervalMs`, clamped to 1) and re-uploads **only** the affected instances. Unlike `UnitPass` (which re-uploads its tiny missile buffer wholesale), the light buffer can hold thousands of static structure lights, so a full per-frame re-upload would be wasteful. - `tickIntervalMs` comes from a new `config` constructor param, wired through in `Renderer.ts` (the same `config` already passed to `UnitPass`). The light now uses the exact same `lastPos→pos` endpoints and alpha as the sprite, so the two track together. ## Test plan - `npx tsc --noEmit`, eslint, and prettier all clean. - `npx vitest tests/client/render --run` — 40 passed. 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-authored-by: Claude Opus 4.8 <noreply@anthropic.com> |
||
|
FloPinguin
|
8a8079b979 |
Fix parallel bot boat attacks of nations 🐛 (#4297)
## Description: When a nation attacked multiple bots via boat attacks in parallel, each boat attack computed its troop allocation independently using `player.troops() / 5` without subtracting `botAttackTroopsSent`. The cumulative troop commitment could exceed the nation's actual troop count, and when the queued `AttackExecution`s ran `init()`, they drained the nation to zero. Planetary Realignment found this bug by accident, here Russia has only 39 troops: <img width="1189" height="654" alt="image" src="https://github.com/user-attachments/assets/07b85e00-6734-4ddd-a16e-fe53309e0ef8" /> The land attack path already handled this correctly. The bug in `sendBoatAttack` was introduced by #3786, which made nations see and attack enemies across rivers via boats, and changed `attackBots()` from `.neighbors()` to `.nearby()`. So the bug was on prod for the entirety of v31. This fix extracts the shared attack troop calculation (reserve, bot-aware allocation, troopSendCap, isAttackTooWeak, emoji) into a new `calculateAttackTroops` method, with a callback for the non-bot troop default (land: `player.troops() - targetTroops`, boat: `player.troops() / 5`). Bot targets in both paths now go through the same reserve-aware calculation. ## 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 |
||
|
evanpelle
|
6833cef7bc |
Tweak render settings to look more like v31
Lower territory saturation, highlight thickness, and border darkening to bring the rendered map closer to the v31 look. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> |
||
|
Evan
|
1ad71b9cfa |
Fix hover-highlight inner border lagging during tile changes (#4303)
## Problem
When you hover over a territory, it highlights with a band that is
`highlightThicken` (default **2**) tiles deep — the edge plus 2 interior
rings, computed via a Chebyshev expansion in `border-compute.frag.glsl`.
Starting a hover triggers a full border recompute, which paints the band
correctly. But while you keep hovering and tiles change owner (territory
growing/shrinking, combat at the front), only the cheap **incremental**
scatter path runs. `BorderScatterPass.pushWithNeighbors` repainted only
the changed tile **+ its 4 cardinal neighbors** (radius 1) — fine for
normal borders, but not for the highlight band. A changed tile affects
the thickening of *every* highlight-owner tile within `highlightThicken`
of it, and those interior tiles were never repainted, so the **inner
edge of the highlight band stayed stale** ("the inside border is not
getting updated"). This was a documented trade-off in the class comment.
## Fix
When a highlight is active, `pushWithNeighbors` now repaints a Chebyshev
**box of radius `highlightThicken`** around each changed tile (the box
subsumes the cardinal cross, so normal borders still update). With no
highlight active it stays on the cheap 5-point cross, preserving the
pass's O(dirty-tiles) scaling. The extra cost (~25 vs 5 points/tile at
default) only applies while actually hovering.
## Testing
Hover over a territory while it grows/shrinks (early-game expansion or a
war front) and confirm the inner edge of the highlight band now tracks
the moving border instead of lagging.
🤖 Generated with [Claude Code](https://claude.com/claude-code)
---------
Co-authored-by: Claude Opus 4.8 <noreply@anthropic.com>
|
||
|
Evan
|
0639cdb29b |
Fix nuclear fallout covering UI overlays (#4302)
## Problem Nuclear fallout was rendering on top of UI overlays (most visibly the SAM launcher range circles), hiding them. ## Cause In `renderOverlays()` (`src/client/render/gl/Renderer.ts`), the fallout bloom pass was drawn near the end of the overlay sequence — after the SAM radius, range circles, structures, bars, etc. — so it painted over all of them. ## Fix Moved `bloomPass.draw(...)` (fallout bloom) to draw right after the ground units and before all UI overlays. Fallout is a ground-contamination effect, so it now sits above the terrain/units but below every UI overlay, which all render on top. 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-authored-by: Claude Opus 4.8 <noreply@anthropic.com> |
||
|
Evan
|
10ca2d1230 |
Restore gray in-game background to match v31 (#4301)
## Summary The in-game map background changed from gray (v31) to near-black after the WebGL renderer rewrite. This restores the gray. The renderer rewrite hardcoded the base-layer clear color to `(0.04, 0.04, 0.06)` in `drawBaseLayer` (`src/client/render/gl/Renderer.ts`). v31 set the background via `PastelTheme.backgroundColor()`, which returned `rgb(60,60,60)`. This change sets the clear color back to that gray. ## Notes - The old theme-based `backgroundColor()` system was removed in the rewrite, so this hardcoded clear color is now the single source for the map background. 🤖 Generated with [Claude Code](https://claude.com/claude-code) |
||
|
Evan
|
0904ad76d1 |
Fix per-frame render jank from toggle-input-card focus (#4300)
## Problem
Enabling **Starting Gold** (or **Game Timer** / **Gold Multiplier**) in
the single-player / host-lobby modal made the page spend several ms of
"Render" time **every frame** — for as long as the toggle stayed
enabled. Disabling the option made it stop.
## Root cause
Each `toggle-input-card`, on enable, auto-focused and selected its
number input so you could type immediately:
```ts
input.focus();
input.select();
```
A focused/selected editable inside the modal keeps the browser doing
layout/paint work every frame for as long as it stays focused. It
reproduces for any of the toggle-input cards because they all auto-focus
on enable, which is why Starting Gold, Game Timer, and Gold Multiplier
all triggered it.
> **Note on the earlier revision of this PR:** the first attempt passed
`{ preventScroll: true }` to `focus()`, on the theory that
scroll-into-view was the cause. It successfully stopped the scroll
(verified: modal scroll container `scrollTop 0 → 0`), but the per-frame
render cost remained. That ruled out scroll-into-view and proved the
focused editable itself — not the scroll — was the trigger.
## Fix
Remove the auto-focus entirely. Enabling a toggle no longer focuses its
number input, and the per-frame render cost is gone.
## Trade-off
You no longer get type-to-replace on enable — click the field before
typing the value. Worth it to eliminate the per-frame render.
🤖 Generated with [Claude Code](https://claude.com/claude-code)
Co-authored-by: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
|
||
|
Evan
|
5be72db060 |
Reapply graphics overrides on debug render GUI reset (#4287)
## Problem The debug render GUI's **"Reset to Defaults"** restored bare `createRenderSettings()` defaults, wiping the user's graphics overrides (colorblind theme, ocean color, lighting, name scaling, etc.) from the live render settings. The per-prop right-click "reset to default" and the modified-indicators had the same flaw — their captured defaults were raw, ignoring overrides. ## Fix Thread the existing `resolveRenderSettings` (`createRenderSettings()` + `applyGraphicsOverrides()`) into the debug GUI as the defaults provider, so reset restores the same settings the renderer was actually built with. - **`debug/index.ts`** — added a `resolveDefaults` param (defaults to `createRenderSettings` to keep the module decoupled). The captured `defaults` now include overrides, fixing the per-prop reset and modified indicators too. - **`debug/Wiring.ts`** — `wireActions` takes `resolveDefaults`; the reset handler `deepAssign`s `resolveDefaults()` instead of `createRenderSettings()`. - **`ClientGameRunner.ts`** — passes `resolveRenderSettings` into `createDebugGui`, and extracts a `refreshDerivedGraphics` helper (terrain rebuild + re-theme/palette) from `onGraphicsChanged`, wired as the GUI's `onSettingsChanged` so the reapplied terrain/colorblind overrides become *visible* after reset (they're baked into GPU textures and aren't picked up per-frame). Side benefit: editing terrain/theme settings in the debug GUI now refreshes those textures live too (that callback was previously never wired). 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-authored-by: Claude Opus 4.8 (1M context) <noreply@anthropic.com>v0.32.0-beta5 |
||
|
FloPinguin
|
094aa766ce |
Improve "Better troop management for nations 🤖" (#4278)
## Description: **Allow Hard/Impossible nations to retaliate and expand freely** Previously, nations on Hard/Impossible difficulty could be stuck unable to fight back if their `troopSendCap` or `isAttackTooWeak` checks blocked them from sending enough troops. **@legan320** on the main discord noticed it. Now: - `troopSendCap` raises the cap to at least the total incoming attack troops, so nations can match the force being used against them - `isAttackTooWeak` bypasses the 20% minimum check entirely when under attack - `troopSendCap` no longer applies when attacking Terra Nullius, so nations can always expand into unowned land with full troops All checks still apply normally for unprovoked attacks against other players. ## 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 |
||
|
evanpelle
|
5161d78d84 |
Fix nuke fallout embers flickering forever ☢️
The ember/particle flicker in the fallout effect was gated only by the fallout bit, which is permanent on tiles that stay unowned. It also ramped to full strength as the per-tile heat decayed to 0 and animated on the global tick, so it kept flickering indefinitely after the blast had cooled — visible both as the bloom dots and (more prominently) as the ambient ember light when dynamic lighting is enabled. Fade both with heat so they vanish along with the glow: - extract.frag.glsl: bloom dots multiplied by the glow's opacity - fallout-light.frag.glsl: ember light multiplied by heat Heat decay timing is unchanged. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> |
||
|
FloPinguin
|
b997099dfe |
Add map search 🔍 (#4283)
## Description: Add a search input field to the map picker section header, allowing users to quickly filter maps by name. - Place transparent search input on the right side of the "Maps" section header - Filter maps by translated name and map ID as the user types - Hide Featured/All/Favourites tab buttons while search is active - Show filtered results with a count heading, or a "no results" empty state - Clear button appears when search input has text <img width="857" height="463" alt="Screenshot 2026-06-15 001415" src="https://github.com/user-attachments/assets/35e1101a-177e-4923-bb1d-34eb683c6f80" /> No search results: <img width="855" height="454" alt="Screenshot 2026-06-15 001433" src="https://github.com/user-attachments/assets/bf27211d-5891-4739-a92f-0fc44b3c9c61" /> ## 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 |