mirror of
https://github.com/openfrontio/OpenFrontIO.git
synced 2026-07-22 19:10:17 +00:00
8de73deac88f17f9d3109e450e6b8fa181e7c070
4242
Commits
| Author | SHA1 | Message | Date | |
|---|---|---|---|---|
 Zixer1andGitHub
|
8de73deac8 |
Feat/featured stream (#4335)
**Add approved & assigned issue number here:** Resolves #4333 ## Description: Adds a small homepage panel that embeds a live Twitch stream, shown only while a configured channel is actually live. When nothing configured is live, it renders nothing. Config-gated and off by default. The client reads a served config like news.json: an on/off toggle plus the Twitch channel(s), with a bundled fallback so it stays off until the backend serves config. So OF admins control whether it is on and which channel is linked, no redeploy. First live channel in the list wins. You can drag the panel between the corners or minimise it, both persisted across refresh. Clicking it opens the channel on Twitch. It shows the live broadcast title, fetched from a third party with a clean fallback to the channel name if that is unavailable. Mainly designed OFM tournament streams, but OF can point it at its own channel for major releases. Notes: - Off by default, no impact until OF turns it on. Activation needs the matching backend config endpoint (`featured-stream.json`), which I will follow up on the infra side. - Twitch requires the embed to stay visible while playing, so "minimised" stays a small visible thumbnail and the panel pauses during a game instead of hiding (The stream can still be muted, but will keep being played, although it can be paused. This is so that the viewership still is present on twitch, and players in OF can see what is happening). Showcase of how it would look like: https://github.com/user-attachments/assets/4874bcd6-e7e8-49d8-94ab-20512ab1f71c ## 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._ |
||
|
|
1360b27bbd |
feat(client): graphics presets — simplify settings behind an Advanced section (#4663)
## Summary
The graphics settings modal had grown too complex for average players
(~25 sliders/toggles/color pickers in one flat list). This reworks
graphics configuration around **presets**:
- **Shared `<graphics-preset-selector>` component**
(`src/client/components/`): a self-contained dropdown of built-in +
saved presets that applies a preset wholesale, shows a disabled "Custom"
entry while the current overrides match no preset, and offers delete for
saved presets. It reads/writes `UserSettings` directly and re-renders on
the settings-changed events, so both hosts stay in sync automatically.
- **In-game graphics modal**: preset dropdown up top, everything else
collapsed under an **Advanced settings** expander. Advanced also holds
the custom-preset tools: save-as-preset, copy settings JSON to
clipboard, and paste-JSON import (Zod-validated, inline error).
- **Main-menu settings modal**: a new "Graphics Preset" row using the
same component — replacing the colorblind toggle.
- **Built-in presets**: Default, Night, and Colorblind — defined as data
in `graphics-presets.json` (schema-parsed at load).
### Design notes
- **Theme palettes are an enum, not a boolean.**
`accessibility.colorblind` is replaced by `palette: "default" |
"colorblind"` — `PALETTE_NAMES` in `GraphicsOverrides.ts` is the single
source of truth (`ThemeName` derives from it; `ThemeProvider` builds one
theme per palette), so adding a future palette is one enum entry + one
theme JSON. Legacy stored booleans are translated to the enum at read
time.
- **The colorblind look is data.** The previously hardcoded Okabe-Ito
friend-foe colors are now generic override fields
(`affiliation.self/ally/enemyColor`,
`mapOverlay.friendly/embargoTintColor` + ratios) carried by the
Colorblind preset JSON; the palette selects only the theme. Selecting
Colorblind anywhere (menu or in-game) applies the full look. Side
benefit: any preset can customize friend/foe border colors.
- **Existing players are protected**: a one-time migration snapshots
pre-existing custom overrides into a "My settings" preset on first init,
so switching presets can never lose a hand-tuned config. Flag-only
colorblind users are upgraded to the full Colorblind preset so they keep
the blue/orange borders. Writing the presets key (even as `{}`) stamps
the migration done.
- Applying a preset reuses the existing `setGraphicsOverrides` →
change-event → live-regenerate path, so presets and imports take effect
immediately (including terrain-texture rebuilds for color changes).
## Test plan
- [x] Full suite: 176 files / 2100 tests pass; `tsc`, ESLint, Prettier
clean
- [x] `GraphicsPresets.test.ts` locks preset JSON to the renderer values
the old hardcoded colorblind block produced, schema-validates every
built-in preset, and covers legacy boolean → palette-enum translation
- [x] Driven headless in a real singleplayer game (WebGL): dropdown
present in both the main-menu settings and the in-game modal; selection
in one reflects in the other; presets apply + persist; "Custom" appears
after a manual slider tweak; save-as-preset selects the new entry;
delete via ✕ + confirm; copy JSON → clipboard; invalid-JSON inline
error; valid import applies live (ocean recolor visible in render)
- [x] Migration: seeded legacy overrides survive init untouched and
appear as an active "My settings" preset; legacy colorblind boolean
upgrades to the full preset; fresh profiles get no phantom preset;
migration is idempotent
🤖 Generated with [Claude Code](https://claude.com/claude-code)
---------
Co-authored-by: Claude Fable 5 <noreply@anthropic.com>
|
||
|
|
6734f76488 |
mls (v5.8) (#4656)
## Description: Version identifier within MLS: v5.8 [Changed languages] - bg - cs - da - fa - fr - hu - ja - ru - uk [Change volume] - Changed languages: 9 - Changed files: 9 - Changed lines: 23690 - metadata.json: unchanged Final reviewer: meow This PR was generated by the PR sender tool, then checked and submitted by the final reviewer. ## 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 - [x] I confirm I have thoroughly tested these changes and take full responsibility for any bugs introduced ## Please put your Discord username so you can be contacted if a bug or regression is found: aotumuri --------- Co-authored-by: coderabbitai[bot] <136622811+coderabbitai[bot]@users.noreply.github.com> |
||
|
Raka HouriantoandGitHub
|
6dd9eb8323 |
Reuse cached TradeShip paths for motion plans (#4654)
**Approved and assigned issue:** #4643 Resolves #4643 ## Description `TradeShipExecution` currently calls `WaterPathFinder.next()` and then performs a second one-shot `findPath()` for the same destination when it records a motion plan. `next()` has already calculated and cached the traversal route, so the second call repeats the expensive water-path calculation solely to recreate the route for the client. This change lets `PathFinderStepper` return a copy of the active path after `next()` advances it. Numeric paths remain `Uint32Array`s, matching the compact representation already used by the stepper and supported by motion-plan packing. `WaterPathFinder.pathForTraversal()` retains the existing second water-graph freshness check. If the graph refresh replaces the stepper between `next()` and motion-plan recording, it falls back to the original one-shot query. Otherwise it returns the cached remainder. The method also normalizes the result to begin at the tile returned by `next()`, so `TradeShipExecution` does not need to mutate the path. `findPath()` remains a stateless one-shot query. The change is limited to TradeShip and the minimal pathfinder support; it includes no TransportShip changes. ## Performance Current upstream `main` (`da2e0918`) was compared with the same commit plus only this change. Each variant was run once per replay on macOS arm64 with CPU profiling disabled. The replay intents were identical between variants, and the current-client final hash and hash tick matched for every pair. | Game ID | Workload | Whole replay | TradeShip execution | Throughput | | --- | --- | ---: | ---: | ---: | | `DWmULj4H` | Antarctica, TradeShip-heavy | 68.960 s → 60.271 s (**-12.60%**) | 18.981 s → 11.844 s (**-37.60%**) | 446 → 510 ticks/s | | `efA7EZv9` | Australia | 14.660 s → 14.346 s (**-2.14%**) | 1.216 s → 0.920 s (**-24.34%**) | 441 → 450 ticks/s | | `waxvMCue` | Svalmel | 16.666 s → 16.537 s (**-0.77%**) | 1.169 s → 0.931 s (**-20.36%**) | 551 → 555 ticks/s | Matched current-client final hashes: - `DWmULj4H`: `49212092378184090` at tick 31,060 - `efA7EZv9`: `82334231069422620` at tick 6,760 - `waxvMCue`: `34697926985435590` at tick 9,480 ## Validation - `npm run build-prod` - Full Node 24 coverage suite: 174 test files and 2,091 tests passed - Full ESLint check - Full Prettier check - Current-main baseline/patched replay hashes matched for all three benchmark games ## Checklist - [x] No UI updates; screenshots are not applicable. - [x] No user-facing text was added or changed. - [x] Relevant tests were added. ## LLM disclosure This change, PR description, and benchmark analysis were authored by **GPT-5.6 Sol**, an LLM, under human direction. |
||
|
RyanandGitHub
|
5ae2040d65 |
add game history to a profile (#4662)
## Description: adds game tab to player profile: <img width="1235" height="928" alt="image" src="https://github.com/user-attachments/assets/660fba48-18d0-4538-a9d5-f33abc0e693d" /> also make ui a bit more uniform, both account + profile modal match, and changed the filtering options to be the same as the games tab <img width="972" height="581" alt="image" src="https://github.com/user-attachments/assets/6f10f78e-e32b-42a6-8df4-7aa6f0cf5146" /> <img width="1006" height="623" alt="image" src="https://github.com/user-attachments/assets/caffb742-1d64-4d21-aa13-d3a7191088ca" /> ## 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 |
||
|
RyanandGitHub
|
3c5c96c141 |
profilelink (#4661)
## Description: <img width="930" height="755" alt="image" src="https://github.com/user-attachments/assets/f606bdce-fbeb-4fc3-98fb-ba6622634350" /> <img width="875" height="368" alt="image" src="https://github.com/user-attachments/assets/81c8243d-5dc0-4687-bed4-cadb6bafb808" /> ## 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 |
||
|
|
49c358d304 |
feat: cancel ranked 2v2 matches that don't fill or fully spawn (#4655)
## Problem A ranked 2v2 that starts with a missing player, or where a matched player idles through the spawn phase, plays out as a lopsided 2v1 — and records a ranked result (ELO) for a match that was never fair. ## Solution Void the match from inside the sim: `WinCheckExecution` runs a one-time check on the first check tick after the spawn phase ends. For `rankedType === "2v2"`, if fewer than `maxPlayers` humans have spawned, the game ends immediately with **no winner**. A player who never joined isn't in the game start info at all, so the single spawn-count check covers both the missing-at-start and never-spawned cases. - `setWinner` now accepts `null` and emits a `WinUpdate` with `winner: undefined` — the wire schema (`WinnerSchema`) already allowed an absent winner. - `WinModal`'s previously-empty `winner === undefined` branch shows "Match cancelled — not all players spawned" and still votes the winnerless result to the server, so the winner-vote consensus is reached and the record archives promptly. - The archived record simply has no `winner`; the API voids winnerless ranked records (same shape any ranked game already produces when the winner vote never reaches consensus). - Only server change: winner votes are keyed with `JSON.stringify(winner ?? null)`, since `JSON.stringify(undefined)` is not a string and would break the `VoteRound` key contract. The check counts via `allPlayers()` rather than `players()`, since the latter filters out tile-less players — which is exactly what a never-spawned player is. Ranked 1v1 is deliberately untouched (the existing last-human-connected walkover still applies). ## Tests `tests/Ranked2v2Cancel.test.ts`: - 3 of 4 players spawn → game ends with a winnerless `WinUpdate` - a 4th player never joined (absent from start info) → same - all 4 spawn → no cancellation - unranked team game short a player → no cancellation Full suite (2094 tests), tsc, ESLint, and Prettier all pass. 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-authored-by: Claude Fable 5 <noreply@anthropic.com> |
||
|
|
fabd1bd2d1 |
fix(core): reject spawn intents after the spawn phase (anti-teleport) (#4657)
## Problem
Patches sending the `spawn` intent over the game WebSocket while a match
is underway:
```js
ws.send(JSON.stringify({ type: "intent", intent: { type: "spawn", tile: tileRef } }));
```
The server relays it like any intent, and `SpawnExecution.tick()` then
**relinquishes the player's entire territory and re-conquers it at the
target tile** — instant teleport anywhere on the map.
The root cause is that `SpawnExecution.tick()` had no spawn-phase gate
(only a random-spawn re-roll guard), and the engine ticks the execution
**both during and after** the spawn phase (`activeDuringSpawnPhase()` is
`true`, and after the phase `!inSpawnPhase()` is also `true`).
## Fix
Ignore a spawn intent when the game is no longer in the spawn phase
**and** the player has already spawned:
```js
if (!this.mg.inSpawnPhase() && player.hasSpawned()) {
return;
}
```
Because `inSpawnPhase()` / `hasSpawned()` are deterministic game state,
the intent becomes a no-op identically on every client — no desync.
Unaffected:
- First-time spawns (`hasSpawned()` is false)
- In-phase spawn picks and re-picks (`inSpawnPhase()` is true)
- Existing random-spawn re-roll protection (kept as-is)
## Tests
- Added `Spawn intent after the spawn phase cannot relocate territory
(anti-teleport)` — establishes a player, then asserts a later `spawn`
intent leaves `spawnTile()` and `numTilesOwned()` unchanged.
- Simplified `Spawn on specific tile` to a single first spawn (the
previous version relied on an out-of-phase re-pick, which this fix now
correctly forbids).
- Full `tests/core` suite green (259 tests).
🤖 Generated with [Claude Code](https://claude.com/claude-code)
Co-authored-by: Claude Opus 4.8 <noreply@anthropic.com>
|
||
|
|
da2e0918a4 |
feat/highlight the owner of hovered naval units (#4610)
Resolves #4445 ## Description: Changes HoverHighlightController.ts to check for naval units if the mouse is not currently hovering over land. It then highlights the owner of the closest naval unit within 50px of the mouse. The activation radius feels a little to large right now, but it is consistent with the PlayerInfoOverlay functionality. Some input would be appreciated It is also currently disabled by default, not sure if this should be the case. ## 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: unne27 https://github.com/user-attachments/assets/7b8262e5-a097-44c8-b2ae-1ac336466623 <img width="534" height="901" alt="image" src="https://github.com/user-attachments/assets/50e9e126-08a6-4a24-9c26-cd4099a2603e" /> --------- Co-authored-by: unne27 <> |
||
|
RickD004andGitHub
|
43545196b1 |
Adds Baltics map (#4614)
## Description: Adds Baltics map. Basic map for v33 just to have something simple since most maps have special shapes due to impassable terrain. One mainland with detached "islands" to have multiple island players for interesting gameplay. Regional European maps are also always popular. 36 nations with additional nations for a total of over +60 <img width="547" height="526" alt="image" src="https://github.com/user-attachments/assets/3a911a17-8fbe-446d-ab0b-77bd9c34885a" /> ## 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 |
||
|
|
826d8b1bcf |
feat(client): account usernames + verified badge on player-facing lists (#4653)
## Summary Client side of openfrontio/infra#436 — every player-facing GET now returns the player's **account username** next to their `publicId`, and this PR renders it everywhere, with a blue verified check for premium/indefinite bare-name holders. ### Schemas (all additive, `.nullable().optional()` — no deploy-order constraint) - `FriendEntry`, `PlayerProfile`: `username` - `ClanMember`, `ClanJoinRequest`: `username`; `ClanBan`: `username` + `bannedByUsername` - `RankedLeaderboardEntry`: `accountUsername` (the existing session `username` field is untouched) ### `<player-name>` element One component owns player-identity rendering on account surfaces: - displays `username ?? publicId` - click-to-copy copies the **username when set**, the publicId otherwise; `copyText` overrides (profile modal copies the share URL) - `onNameClick` replaces copying with an action (clan member rows + leaderboard rows open the player's profile); `nameClass` overrides the chip styling so leaderboard names keep their original bold look - appends the verified check (same mark as the username-row toggle) when `isVerifiedUsername(username)` Used by: friends list + requests, all clan member/request/ban rows (bans badge both the banned player and the issuing officer), ranked leaderboard rows + sticky self row (showing `accountUsername ?? public_id` — the session name is deliberately dropped ahead of its API removal), profile modal header. ### Verified inference No API flag needed: account-username bases can never contain dots, so a dotless display name **is** the bare-name claim (premium/indefinite). `TEMPORARY####` server renames are excluded, matching the play-toggle eligibility rule. The leaderboard derives the badge from `accountUsername` only — session names are free-form and would false-positive. Also: clan member/request/ban search filters now match usernames, not just publicIds, and sending a friend request refetches the request lists instead of inserting the raw input (which may be a username, not a publicId). ## Test plan - [x] `npm test` — full suite green (2087 + 176 server) - [x] New schema tests: each field's set / null / absent states; `accountUsername` coexists with session `username` - [x] `isVerifiedUsername` unit tests (bare / suffixed / null / TEMPORARY) - [x] tsc, ESLint, Prettier clean 🤖 Generated with [Claude Code](https://claude.com/claude-code) --------- Co-authored-by: Claude Fable 5 <noreply@anthropic.com> |
||
|
|
ad8d7e995a |
feat(client): verified-name toggle (play under your account name) (#4648)
## Summary The client half of the verified-name plan: subscribers with a claimed bare name can opt in to play under it, and the game renders a **server-validated** blue verified check next to their name. ### Verified toggle (username row) - Blue check-circle badge + "Verified" label act as a toggle button in the play username row, shown to all users (hidden on CrazyGames via `no-crazygames`); both turn blue when active and the input locks to the bare account name — `getUsername()` feeds every join path. - Non-subscribers (logged out, `unclaimed`, lapsed `claimed`) get a subscribe-first dialog whose **View store** routes to `#modal=store&tab=subscriptions`. Entitled players without a usable name (never set, or `TEMPORARY####`) are routed to the account modal instead. - The opt-in persists in localStorage but never auto-enables while ineligible; unchecking restores the saved free-form name. Anonymity stays a first-class option. - After a successful username save the page reloads so every consumer restarts from a fresh `/users/@me`. ### In-game badge (GL name pass) - New `verified` boolean on `PlayerCosmeticRefsSchema` (client claim) and `PlayerCosmeticsSchema` (resolved). `getPlayerCosmeticsRefs()` sets it from the toggle state, covering both the multiplayer join and locally-resolved singleplayer paths. - **Server-validated at join, today**: the Worker already fetches `/users/@me` with the client's token on every authenticated join (flares/friends/clans), and that response carries the account username since #4644 — so `verifiedBadgeAllowed` keeps the claim only when the bare-name status is `premium`/`indefinite` AND the join name exactly matches the account's resolved display name. Zero extra requests, no token-claim staleness. Mismatches strip the badge rather than rejecting the join; a pre-start rejoin identity change also drops it (that path skips join-time validation). Anonymous persistent-ID joins exist only in Dev and keep the claim for local testing. - Rendering: 10th instanced slot in the name pass's `StatusIconProgram`, anchored just right of the name text (`nameHalfWidth` was already in the player data texture), slightly below the name line's center. The badge art is a new cell (index 11) in `status-atlas.png`; the flag rides the free `pd8.y` column. Anonymized viewers never see it (cosmetics are already stripped for hidden players). ## Test plan - Full suite passes (2,047 + 173), including new tests: cosmetics schema `verified` (optional/boolean-only), `Privilege.isAllowed` pass-through, and `verifiedBadgeAllowed` (exact match, case rejection, unentitled statuses, missing name). - Headless real-app verification of every toggle state (dialogs, persistence, silent drops, store-tab routing, save→reload) with stubbed API routes. - Drove a real singleplayer game headless (WebGL via ANGLE Metal): the blue check renders to the right of "Bob", scaled and tucked to the name; bot/nation names show no badge. Screenshot-verified. 🤖 Generated with [Claude Code](https://claude.com/claude-code) --------- Co-authored-by: Claude Fable 5 <noreply@anthropic.com> |
||
|
FloPinguinandGitHub
|
d9976babbd |
Add tribe name themes system with custom tribes support 🏰 (#4647)
## Description: Adds a theme system for bot tribe names that maps can customize via their info.json. Instead of all bots using the same global name pool, maps can now specify one or more themed name sets and define custom tribe names with higher priority. Key changes: - New `src/core/execution/utils/tribeNameThemes.json` containing 17 themed name sets (default, north_america, south_america, europe, africa, asia, oceania, space, fantasy, war, western, under_ocean, tournament, funny, scary, weird, vs). The default theme preserves the original `TribeNames.ts` values. **Mappers are encouraged to change that json file, the new themes just serve as an example and are currently not used by any map.** - Maps can specify `"themes": ["europe", "war"]` in info.json to merge prefixes/suffixes from multiple themes into one name pool. - Maps can specify `"custom_tribes": ["Holy Roman Empire", "Kalmar Union"]` for exact tribe names that take priority over theme-generated names. Custom tribes are used first (random selection, no duplicates until exhausted), then theme-based prefix+suffix combos. - `TribeNameResolver` resolves themes per-map at runtime, with fallback to the default theme and a console warning for unknown theme names. - Go codegen (`codegen.go`) updated to propagate `themes` and `custom_tribes` from info.json to Maps.gen.ts. - Germany map now has 404 custom tribes (all German Landkreise and kreisfreie Städte) to showcase the new feature. - Fixed a bug where tribe bots could inherit nation flags if their random name coincidentally matched a nation name (name-based cosmetics lookup now only applies to actual Nations, not Bots). ## 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 |
||
|
|
9c14ab04e0 |
feat(client): account-level custom usernames (base.suffix + premium bare names) (#4644)
## Summary Client integration for account-level usernames (backend: openfrontio/infra#434). Players get one canonical account name stored as a base plus a server-assigned 4-digit suffix (`bob.4821`); subscribers display the bare base (`bob`) with an exclusive case-insensitive claim on it. - **Schemas** (`src/core/ApiSchemas.ts`): new `player` username fields on `GET /users/@me`, `UsernameStatusSchema`, `PutUsernameResponseSchema`, and an `isTemporaryUsername()` helper. The display name is rendered exactly as the server resolves it — the client never assembles `base.suffix`. Discriminators stay strings (leading zeros). - **API** (`src/client/Api.ts`): `updateUsername()` for `PUT /users/@me/username`, returning a discriminated result covering every documented failure: `invalid` (400), `profane` (400 + `USERNAME_PROFANE`), `taken` (both 409 bodies), `cooldown` (429 + `Retry-After`), `failed`. - **UI** (`src/client/components/UsernamePanel.ts`, in the Account tab): set/change form prefilled with the base, live 3–20 / `[a-zA-Z0-9_-]` validation (`validateAccountUsername`), form locked with the date while the 30-day cooldown runs, grace-period warning for lapsed claim holders, and a free-rename notice after a server-side `TEMPORARY####` rename. The confirm dialog composes warnings by state: 30-day lock always, case-only-change notice, and abandon-reservation warning for `claimed` players. Suffixes are never mentioned in user-facing copy — subscribers should feel like they own the bare name outright. - **Load prompt** (`src/client/Main.ts`): on a clean homepage load, a subscriber renamed to `TEMPORARY####` is prompted to pick a new name (free); takes priority over the rewards popup (the account modal shows rewards anyway). ## Deploy notes **No deploy-order constraint.** All new `/users/@me` fields are optional in the schema: against the current API the response still parses and the panel simply doesn't render (`usernameStatus === undefined`). The client can ship before or after infra#434. ## Test plan - New schema tests (old-API absence, leading-zero discriminators, unknown statuses, PUT payload) and validation tests (dots, spaces, unicode, trim) — full suite passes (2,031 + 171). - Drove the real app headless with synthetic `/users/@me` payloads: verified all panel states (unclaimed, never-set, claimed+grace, TEMPORARY, cooldown-locked, old API hidden), the confirm-dialog warnings, and the inline error path on a failed PUT. 🤖 Generated with [Claude Code](https://claude.com/claude-code) --------- Co-authored-by: Claude Fable 5 <noreply@anthropic.com> |
||
|
AotumuriandGitHub
|
d6b4b0e00c |
Remove Discord URL placeholder from translations (#4645)
## Description: This value was a sample URL used as an input placeholder, and it was removed because translating it would be meaningless and could potentially alter the URL format incorrectly. ## 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: aotumuri |
||
|
|
c1dfa9641b |
Add map More than luck (#4584)
Resolves #4563 ## Description: - 1344x1348 and ~916000 land tiles - 35 default (5x7), 400 total - 5 sided map. Hard to nuke neighboring leafs due to angle. Organic design. https://youtu.be/z4xlCXfOW7k https://discord.com/channels/1284581928254701718/1519889161220522054 ## 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: PlaysBadly --------- Co-authored-by: Aaron Tidwell <Aaron.Tidwell@gmail.com> |
||
|
|
a5480ec7f7 |
feat(client): shareable player profile modal (#modal=profile&publicID=x) (#4639)
## Description: Add player profile (stats only for now): <img width="952" height="241" alt="image" src="https://github.com/user-attachments/assets/2cc0c1ed-baf6-4cb5-837c-1f82d2850005" /> and clans modal: <img width="927" height="778" alt="image" src="https://github.com/user-attachments/assets/87e7ae53-6531-41cd-8795-4ea1d8fb67af" /> with dedicated url: <img width="1273" height="916" alt="image" src="https://github.com/user-attachments/assets/dd1ccff7-5d3c-4c70-a7d2-0c7399a88a08" /> ## 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 Fable 5 <noreply@anthropic.com> |
||
|
Patrick Plays BadlyandGitHub
|
ea464d44bc |
Update map dyslexdria (#4642)
Resolves #4621 ## Description - Change from 3083x1344 > 3308x1442 (actually smaller, but there's a black frame for the tilt) - Tilt map by using impassable. - Increase map size by ~11% due to performance gains. - Adjust map colors/land tiles to show more detail. - Please do not report updates; per the theme of the map. https://discord.com/channels/1359946986937258015/1450487807242932336/1527108909343572040 https://youtu.be/wJYVfCoDYmY --- ## 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: PatrickPlaysBadly |
||
|
|
7e073dda0b |
fix(server): keep matchmaking games out of lobby reports; salvage invalid entries (#4641)
## Problem Prod masters log `Invalid IPC message from worker` for every ranked 1v1/2v2 match created: 1. The matchmaking poll loop creates the match game with the 1v1/2v2 playlist config (`gameType: Public`) but no `publicGameType` — correctly, since ranked games are invite-only and should never be advertised. 2. While that game sits in its ~7s lobby window, `GameManager.publicLobbies()` includes it (it only checks phase + `isPublic()`), and `WorkerLobbyService.sendMyLobbiesToMaster()` reports it with `publicGameType: gi.publicGameType!` — the non-null assertion hides the `undefined`, and IPC serialization drops the key. 3. The master's `WorkerMessageSchema` parse fails on the missing required field and **discards the worker's entire lobby report**. So for the lobby window of every ranked match, the master's view of that worker freezes: stale player counts and countdowns broadcast to all clients, `maybeScheduleLobby` repeatedly resetting the next lobby's countdown, and occasional duplicate scheduled lobbies (with no cleanup path for scheduled types). With matchmaking running continuously, some worker is blocked at any given moment on a busy server. ## Fix - **Worker** (`WorkerLobbyService`): filter games without a `publicGameType` out of the report. Matchmaking games are never advertised — which also guarantees they can't leak into the public lobby browser. - **Master** (`MasterLobbyService` + `IPCBridgeSchema`): validate lobby entries individually instead of failing the whole message. Malformed entries are logged and dropped; valid lobbies survive. A future bug of this class now degrades to one missing entry instead of a frozen worker view. The send side keeps compile-time safety via the existing per-entry `satisfies` annotations. ## Testing - New test: a matchmaking-style game (Public, `allowedPublicIds`, no `publicGameType`) is excluded from the worker's `lobbyList` report while a normal FFA lobby still goes through. - New test: a report containing a malformed entry keeps its valid lobbies in the next broadcast instead of being rejected wholesale. - Full `tests/server` suite passes (173 tests); `tsc --noEmit` and eslint clean. 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-authored-by: Claude Fable 5 <noreply@anthropic.com> |
||
|
evanpelleandClaude Fable 5
|
eee7d793f8 |
chore(glow): raise default small-player glow strength to 35%
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> |
||
|
|
4544e18ce6 |
refactor(glow): move small-player glow strength into graphics overrides (#4634)
## Summary Moves the small-player glow strength from a standalone UserSettings key (`settings.highlightGlowStrength`) into the graphics overrides blob (`smallPlayerGlow.strength`), and moves its slider from the basic settings modal into the **Effects** section of the graphics settings modal. The pass now reads strength from its live `RenderSettings` slice like every other graphics knob, flowing through `applyGraphicsOverrides`. This removes the dedicated push chain (ClientGameRunner listener → MapRenderer → Renderer → pass setter) and MapRenderer's context-restore reapply — strength survives WebGL context restores automatically now, participates in the graphics modal's "Reset to defaults", and shows up in the render debug GUI. ## Bug fix The old slider had no visible effect below ~115%: strength only drove the blur-iteration count (`round(strength ** 2.74)`, floored at 1 pass), and the composite intensity (`alpha * pulse * sqrt(passes)`) never factored strength directly — so 10% rendered identical to 100%. Strength is now a linear opacity fade on a fixed-width aura: - 100% = the aura's full brightness, 10% = barely visible, 0% = off - Slider capped at 100% (the >100% aura-widening mechanism became unreachable and is removed: `passesFor`, `lastPasses`, and the blur-iteration loop) - Default is 25% - The pass clamps persisted values above 1 so stale settings from the old 500% range can't over-brighten ## Notes - Reuses the existing `user_setting.highlight_glow_strength_label` / `highlight_small_players_desc` translation keys — no en.json change - The legacy `settings.highlightGlowStrength` localStorage key is not migrated (the slider only shipped in #4588 a few days ago); users reset to the 25% default ## Test plan - [x] `tests/GraphicsOverrides.test.ts` — schema validation + apply coverage for the new override group - [x] Full suite (171 tests), tsc, eslint all pass 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-authored-by: Claude Fable 5 <noreply@anthropic.com> |
||
|
|
1f97f2b252 |
fix(render): standardize gradient colorSize to game tiles (#4633)
## Summary Effect cosmetic attributes are meant to be standardized on **game tiles** for spatial values and **per-second** for rates. An audit of every effect attribute against its renderer consumer found one violation: the gradient trail's `colorSize`. - The trail shader computed the palette cycle as `colorSize * 4.0 * count`, so `colorSize: 1` produced ~4-tile bands — while `CosmeticSchemas.ts` already documented `colorSize` as "band width in tiles". - This PR removes the hidden ×4 in `trail.frag.glsl` and the mirrored factor in the structures gradient pace in `structure.frag.glsl`, so `colorSize` is now exactly the band width in tiles, and updates the pace-formula doc comment in `CosmeticSchemas.ts`. All other attributes were verified already standard: gradient `movementSpeed` (tiles/s), transition `frequency` (colors/s), spiral `radius` (tiles) / `rotationSpeed` (rad/s), explosion `size`/`thickness` (tiles), `speed` (tiles/s), `transitionSpeed` (colors/s). Every animated path runs off a `uTime` uniform that is genuinely in seconds. ## Catalog impact - Production `cosmetics.json` ships **zero** effects today, so there is no live migration. - Dev catalog gradient entries need `colorSize` ×4 to preserve their current look (`rainbow_trail` 0.2→0.8, `red_black_trail` 1→4, `tiel_red_gradient_nuke_trail` 0.5→2, `rwb_structure_gradient` 5→20). ## Test plan - `npx vitest tests/CosmeticSchemas.test.ts --run` — 51 passed (schema shape unchanged; this is a shader-semantics fix). 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-authored-by: Claude Fable 5 <noreply@anthropic.com> |
||
|
evanpelle
|
cd75d54c5f |
ci: remove PR description validation check
Drop the validate-description job from the PR workflow; the has-milestone check remains. |
||
|
|
828d7b1d96 |
feat(client): spiral nuke trail cosmetic effect (#4630)
## Summary Adds a **spiral** `nukeTrail` effect type — a 3D vortex of glowing helix strands projected onto the map, trailing behind nukes whose owner has the cosmetic equipped. Catalog attributes (`spiral_tail` shape): | attribute | meaning | | --- | --- | | `colors` | palette, wrapped once around the vortex circumference | | `radius` | helix amplitude in tiles | | `strands` | helix strand count (renderer clamps to 8) | | `rotationSpeed` | vortex spin, radians/sec | ## How it works The per-tile trail texture holds persistent state; the vortex is a transient animation that follows a path — so it renders as **ribbon geometry**, not tile stamps. **Path recording** (`SpiralTrails`): each live spiral-owner nuke gets an append-only centerline polyline — ~2 samples per tile of travel carrying position, a smoothed perpendicular (blended across tick segments so curved paths don't kink), and cumulative distance. Params are pushed once per player by `WebGLFrameBuilder` when the cosmetics catalog resolves; a ribbon is dropped the moment its unit disappears, matching stamped-trail cleanup. **Rendering** (`SpiralRibbonPass`): one triangle-strip VBO per nuke (2 verts per sample, streamed append-only via `bufferSubData`, grown by doubling); the vertex shader swings each sample sideways by the helix offset and evaluates the head-cone convergence as a function of `uHeadDist − d`, so uploaded vertices are immutable — the cone feeding the strands into the missile needs no rewriting as the nuke flies. One draw per strand reuses the same strip with a different phase offset (`uPhase0`). The glow look is a bloom-style split: - **halo** — wide quadratic falloff, rendered premultiplied into a quarter-resolution buffer (`mapOverlay.spiralResolutionScale = 0.25`, ~16× cheaper fragments) and composited **additively** over the scene, so it reads as emitted light and the bilinear upsample keeps it soft; - **core** — sharp full-resolution ribbons on top, with a white-hot center on segments facing the viewer (neon-tube look). Shading spins the helix angle with time: a `cos` depth cue brightens facing segments and darkens receding ones, and the palette cross-fades around the circumference. The spiral nuke still stamps its plain centerline through the unchanged `TrailManager` — `trail.frag` styleId 2 draws it flat in the first color as the missile's spine, so alt view, death cleanup, and trail overlap behave identically to non-cosmetic nukes. Ribbons draw above the plain trails, below the missiles, and are skipped in alt view. **Perf**: both ribbon stages are skipped entirely (CPU-side, before any GL work) while no spiral nuke is in flight — games without the cosmetic, and frames without a spiral nuke, pay nothing new. Vertex uploads stream only newly appended samples; the halo's fragment cost is capped by the quarter-res buffer. MIRV warheads are explicitly excluded from ribbons (one MIRV splits into 350 of them). **Store preview**: `TrailSwatch` mirrors the bloom split in SVG — a screen-blended blurred halo, a crisp colored core, and a white-hot center line — with a phase-offset per-strand fade matching the in-game depth-shaded spin. Note: requires the `spiral_tail` catalog entry on the API side to be purchasable/selectable; without it nothing changes visually and the schema tolerates its absence. ## Testing - New `tests/SpiralTrails.test.ts`: ribbon gating by owner/unit type, sample spacing + monotonic distances, strand clamp + pitch-derived twist, death cleanup mutating the live array, params staying fixed for in-flight ribbons - New `tests/TrailManager.test.ts`: baseline stamping behavior (plain boat trails, nuke-bit stamping up to lastPos, death cleanup with overlap repaint) - `tests/CosmeticSchemas.test.ts`: spiral attribute parsing incl. the exact catalog shape, required-field/positivity rejections - Full suite green; `tsc` and lint clean - Verified visually: a standalone WebGL harness drove the real ribbon shaders (glow split, palette colors, spin, cone convergence), and a real solo game boots with zero GL errors 🤖 Generated with [Claude Code](https://claude.com/claude-code) --------- Co-authored-by: Claude Fable 5 <noreply@anthropic.com> |
||
|
RyanandGitHub
|
774d98ddad |
bugfix: trim archived map names (#4632)
## Description: fixed a bug where "Deglaciated Antarctica" had a trailing space in an earlier version of the game and caused visual issues: <img width="1045" height="323" alt="image" src="https://github.com/user-attachments/assets/11628e19-523e-43f9-b3dc-15a5ee1bcd8a" /> and prevented stats from loading: <img width="1070" height="529" alt="image" src="https://github.com/user-attachments/assets/590a7c2b-7dc5-4d8d-816f-469731d42fd4" /> now works: <img width="969" height="387" alt="image" src="https://github.com/user-attachments/assets/35d4ac89-5f97-4534-adbc-d0ce824ea4d8" /> <img width="1013" height="787" alt="image" src="https://github.com/user-attachments/assets/44d6c20a-caf6-417a-b7fe-08f0765e1b16" /> ## 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 |
||
|
RyanandGitHub
|
c269354c74 |
stats modal: change to the UI (#4629)
## Description: update to the stats modal to make it look better... now: ## 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 |
||
|
RyanandGitHub
|
c4447cd434 |
stats button on clan games history (#4628)
## Description: adds stats button to clan games tab <img width="1011" height="660" alt="image" src="https://github.com/user-attachments/assets/fe39f000-6da9-4f1b-9a20-62e8177e6fdb" /> ## 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 |
||
|
RyanandGitHub
|
f070d4843d |
make it a dedicated stats modal, not under account (#4627)
## Description: seperates the stats modal into a dedicated path, with gameID support e.g. : #modal=stats&gameID=VvyXpL9x ## 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 |
||
|
RyanandGitHub
|
0fc80e931e |
convert stats modal to embed instead of popup (#4626)
## Description: convert stats modal to embed instead of popup before: <img width="1193" height="939" alt="image" src="https://github.com/user-attachments/assets/4f96843a-3b96-4874-8292-e670181bd87c" /> after: <img width="1226" height="863" alt="image" src="https://github.com/user-attachments/assets/801273cc-77cd-41b6-bc77-4fdc65afef71" /> also has context to remember where we were in the scrolled list, so pressing "back" keeps the position ## 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 |
||
|
Zixer1andGitHub
|
95840a2074 |
Doomsday Clock: judge teams against the same bar as solo sides (#4624)
**Add approved & assigned issue number here:** Resolves #(to be filed — happy to open the matching issue; flagging directly since this is live in prod team lobbies) ## Description: **Bug.** In Team mode the Doomsday Clock threshold is scaled by the team's *alive* headcount (`base × members.length`, capped at the whole map). In real team lobbies this breaks the mechanic: - With ~16 players per team, wave 1 already demands `4 % × 16 = 64 %+` of the map per team while all humans combined hold ~35 % (bots own the rest). Every non-leading team is skulled ~1 minute into wave 1 and drained to the 5 % floor ~90 s later — even on **slow**, whose squeeze is designed to run to 45:00. The game is decided by whoever leads at grace-end. - The bar/forecast **drops when a teammate dies** (players see "will rise to 68 %" → "44 %" mid-game), and disconnected-but-alive teammates silently inflate it. - Past the 100 % cap, the per-capita scaling stops meaning anything anyway. **Evidence.** Prod game `JEUieLzK` (`Team, playerTeams: 4, 69 players, doomsdayClock slow, bots: 400, no timer`): ended **16:47** via the 95 % team-domination check. From the archived record: 25 deaths before 10:00, only 8 after — the drain cripples rather than kills, so the collapse is invisible in death stats but decisive in outcome. Reconstruction with the real schedule + drain constants: every non-leading team skulled ~11:00–11:30 and pinned at the floor by ~12:30; the crown-exempt leader rolled to 95 % by 16:47. **Why flat is correct.** The wave levels encode a viable-**side** count — `floor(100 / wave%)` sides fit above the bar (25 → 11 → 6 → 3 → 2 → 1). Elimination and victory happen at side granularity (a team is out when the whole team is out; the winner is a team), so the slots must be counted in sides. A team now faces exactly the bar a solo player faces, judged on its combined territory — and each speed preset means the same thing in teams as it does in FFA. **Changes:** - `DoomsdayClock.ts`: remove `doomsdayClockSideRequiredTiles`; the sim and the HUD both use `doomsdayClockRequiredTiles` (hoisted out of the per-side loop — it no longer varies per side). - `DoomsdayClockExecution.ts`: flat per-side bar; comments updated. - `DoomsdayClockPanel.ts`: drop `scalePct`/headcount from the readout — the zone forecast becomes one universal, monotonic number for every player (fixes the 68 % → 44 % whipsaw). `sideStats` → `sideTiles`. - Tests: headcount-scaling expectations replaced with flat-bar + death-invariance regression tests. (History note: an earlier commit restricted team lobbies to normal/fast presets; it was reverted in-branch — with the flat bar the presets carry the same meaning as in FFA, so the full rotation stays. Squash-merge leaves the fix only.) FFA behaviour is unchanged throughout (sides of size 1: flat ≡ current). Deterministic integer math untouched (strictly fewer ops). `npm test` fully green. Rule comparison on `JEUieLzK`'s shape (real death ticks + constants; modeled share trajectories): | rule | trailing teams skulled | all non-leaders at 5 % floor | |---|---|---| | current (× alive) | 11:01–11:27 | **12:34** ← matches the real 16:47 blowout | | flat per-side bar | 26:01–30:42 | 31:49 (late-game backstop, as designed) | ## Please complete the following: - [ ] I have added screenshots for all UI updates — _no layout/element changes; the existing readout shows unscaled values (numbers only)_ - [x] I process any text displayed to the user through translateText() and I've added it to the en.json file — _no new strings; existing `doomsday_clock.*` keys reused with the same params_ - [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 |
||
|
RyanandGitHub
|
943740de32 |
Game Stats - backward compatibility (#4623)
## Description: fixes a bug where old games under the old schema don't open correctly main.openfront.dev: <img width="1043" height="405" alt="image" src="https://github.com/user-attachments/assets/d94811b9-ecfe-4243-9afb-5b25df4366f8" /> this branch: <img width="1034" height="942" alt="image" src="https://github.com/user-attachments/assets/8dcf07e6-2934-4a85-85a7-3f51a493c504" /> ## 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 |
||
|
|
d59b5cdfd7 |
feat(client): gate in-game ads by adblock detection + Admiral recovery (#4534)
## What Two related pieces, wired into the existing `window.adsEnabled` / `userMeResponse` ad flow: 1. **`AdGatekeeper`** — decides whether the *intrusive* in-game ad may show. Once a blocker is **ever** detected, the ad is suppressed **permanently** (terminal state, persisted to `localStorage["adblock-detected"]`). Ad-block users are highly ad-sensitive, so disabling the blocker does **not** unlock the ad — in this or any future session. Detection = a DOM bait probe, refined by Admiral's `measure.detected` signal (`adblocking && !whitelisted`) when it fires. Clean users are never latched. 2. **`Admiral.ts`** — injects the ad-recovery tag (command-queue stub + payload + GAM targeting shim) for **ad-eligible users only**. Paid/`adfree` users have `window.adsEnabled === false`, so Admiral never loads and its adblock popup can't fire for them. Only the in-game ad (`InGamePromo`) is gated — it now loads via `adGatekeeper.whenClear(...)`. Passive homepage/gutter ads are unchanged. ## Why - Paid users (any shop purchase → `adfree` for life) must never see ads *or* load Admiral. - Free adblock users get Admiral's recovery popup, but should never be hit with an intrusive in-game ad even if they disable their blocker. ## How it behaves | Visitor | Admiral | In-game ad | |---|---|---| | Paid (`adfree`) | never loaded | never shown | | Free, no adblock | loaded | shown | | Free, adblock on (or ever was) | loaded (recovery popup) | suppressed forever | | Free, adblock blocks Admiral too | callback never fires | bait fallback suppresses | ## Testing - **Unit:** `tests/AdGatekeeper.test.ts` (9 cases) — terminal latch, "disabling blocker doesn't unlock", cross-session persistence, seed path, no-false-positive. `tsc` clean, `eslint` clean. - **Manual (headless Chromium, real bootstrap):** free user → `adsEnabled: true`, Admiral tag injected + payload initialized, `persisted: null` (no false positive); simulated blocker → flag latches to `"1"`; reload with no blocker → still `"1"` (forever); reset clean afterward. ## Notes / follow-ups - The GAM targeting shim (block 3 of the provider's tag) is ported verbatim but is likely a no-op here since serving is via Playwire RAMP, not Google Ad Manager. Kept for fidelity; can drop if unused. - `ADMIRAL_PAYLOAD_SRC` is a disguised, rotating domain — re-sync from the provider when they reissue the tag. - Admiral's own popup is dashboard-configured and typically domain-locked; best verified on the production domain with a real blocker. - `res.subscribed` (Admiral's own ad-free pass) is intentionally ignored — OpenFront's ad-free is the server `adfree` flag. 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-authored-by: Claude Opus 4.8 (1M context) <noreply@anthropic.com> |
||
|
|
b379502516 |
fix(store): specific rate-limit message on tier change + use shared dialogs for subscription flows (#4622)
## Summary - The change-tier API allows one tier change per minute per player (`playerRateLimit` on `/subscriptions/@me/change-tier`). The client previously lumped the 429 in with every other failure and showed "Couldn't update your subscription. Please try again." — retrying immediately just fails again. A 429 now gets its own message: *"You just changed tiers. Please wait a minute before changing again."* - Replaced all native `alert()` / `window.confirm()` calls in the subscription flows with the shared `showInGameAlert` / `showInGameConfirm` helpers (styled `<confirm-dialog>`, consistent with the rest of the store, and safe on CrazyGames): - Tier change: already-subscribed notice, upgrade/downgrade confirmation (warning variant with "Change Tier" heading), rate-limited/failure/success notices - Dollar checkout failures (first-time subscribe path) - Subscription panel: cancel confirmation (danger variant), cancel failure/success, portal-open failure The currency-purchase alerts in Cosmetics.ts (`login_required`, `purchase_failed`, `purchase_success`) are untouched — subscriptions can't reach that path. ## Test plan - [x] Typecheck, ESLint, Prettier - [ ] Manual: change tier twice within a minute against the real API and confirm the rate-limit dialog appears 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-authored-by: Claude Fable 5 <noreply@anthropic.com> |
||
|
blonandGitHub
|
46162c0e27 |
fix(client): fallback to full border recompute on massive tile changes (#4576)
### **Add approved & assigned issue number here:** Resolves #3604 (related) ## Description: Fixes severe client-side lag spikes (framerate dropping to single digits) when multiple nuclear bombs detonate close to each other with `"isWaterNukes": true` enabled. * Water nukes convert land to water on detonation. For an Atom Bomb (radius 30), this changes up to 2,800 tiles. * The client splits these changes across 16 frames (`dripBuckets`), processing ~150 tile changes per frame. * For each tile change, `BorderComputePass.patchTile` computes updates. If the victim's territory is highlighted, the pass expands the repaint area of each tile change to a `highlightThicken` Chebyshev box of radius 4 (meaning `9x9 = 81` points). * This forces the CPU to calculate and push up to `150 * 81 = 12,150` points *per frame* to the border scatter buffer, uploading it, and rendering it as thousands of overlapping GPU `POINTS` using the complex border shader. * Under consecutive detonations, this completely freezes the client rendering thread, leading to disconnections. * Optimizes `BorderComputePass.ts` to fallback to a full-screen quad border recompute if the scatter point count exceeds a threshold of `2,048` points. * Bypasses the expensive CPU coordinate expansions and array resizing for subsequent tile updates in the same frame. * The GPU renders a simple fullscreen quad to rebuild all borders, which is extremely parallelized and executes in **`<0.1ms`**, keeping gameplay smooth. ## Please complete the following: - [x] I have added screenshots for all UI updates (N/A) - [x] I process any text displayed to the user through translateText() and I've added it to the en.json file (N/A) - [x] I have added relevant tests to the test directory (N/A) ## Please put your Discord username so you can be contacted if a bug or regression is found: blontd6 |
||
|
Zixer1andGitHub
|
4621084500 |
feat(lobby): surface Doomsday Clock preset + anonymous names as lobby settings (#4616)
## Description: Public rotation lobbies can run the **Doomsday Clock** at one of four presets (slow/normal/fast/veryfast), and lobbies can **anonymize player names**, but the lobby UI surfaced neither: the Doomsday Clock badge was generic and there were no settings cards for either. Players couldn't tell what a lobby was actually set to. This surfaces both as regular lobby settings, matching how the other modifiers already display: - **Settings cards** (join/waiting view): adds a "Doomsday Clock" card showing the active preset name, and an "Anonymous Players" card, alongside the existing modifier cards. - **Lobby badge** (home lobby list): the Doomsday Clock badge now reads "Doomsday Clock: Fast" instead of the generic label. Falls back to the plain label when no speed is present (older payloads / non-rotation lobbies). Client-only. Both `doomsdayClock.speed` and `anonymizeNames` already ship in the public `GameConfig`, so no server or schema changes are needed. ## 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 ## Please put your Discord username so you can be contacted if a bug or regression is found: zixer._ |
||
|
Zixer1andGitHub
|
f6e1b8fbae |
feat(livestats): per-player killedBy + deathPosition + winner for live standings (#4593)
## Description: Enriches the admin-bot live-stats snapshot (`/api/adminbot/game/:id/stats`) with the per-player fields a semi-live standings board needs, so it can score kills + placement live instead of waiting for the post-game record. Per player in `liveStats.players[]`: - **`killedBy`** — the eliminator's clientID (null while alive / non-client killer). Invert → live kill points. - **`deathPosition`** — finishing place at elimination = non-bot players still standing + 1 (frozen at "last of the then-standing"). Null while alive → live placement. The **full roster** is reported (dead players are retained in the client view), plus top-level **`winner`** (the decided winner's clientID, else null). Deterministic / consensus-safe: `killedBy` (stamped at `recordKill`) and `deathPosition` (stamped in `PlayerExecution`) are pure sim values, so in-sync clients agree on the majority vote; `winner` is added server-side in `GameServer.liveStats()` from the winner vote (like the existing publicID/username/connected enrichment). ## 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 |
||
|
|
a639a6aa6b |
Gate public lobby listing on the canCreatePublicLobbies entitlement (#4620)
## What The API now returns an explicit `canCreatePublicLobbies` boolean on `/users/@me` (player) and on each subscription tier in `cosmetics.json`. This PR gates public lobby listing on that entitlement instead of inferring it from subscription status (`active`/`trialing`), and advertises the perk on the store's subscription tiles. ## Changes **Entitlement check** - `UserMeResponseSchema` gains a required `canCreatePublicLobbies` boolean (same pattern as `unlimitedRanked`) - The worker's listing endpoint and `HostLobbyModal`'s Public toggle both check the boolean directly; the Dev bypass is unchanged - `hasActiveSubscription()` is removed — these were its only call sites - The server error stays `subscription_required` (subscribing is still how you get the entitlement; renaming would ripple through i18n for no behavior change) **Store** - `SubscriptionSchema` (cosmetics catalog) gains a required `canCreatePublicLobbies` boolean - Subscription tiles show a "Create public lobbies" badge below "Unlimited ranked" when the tier grants it (`cosmetics.public_lobbies` added to en.json) **Tests** - Schema tests for both new fields (accepts true, rejects missing, rejects non-boolean); `UserMeResponse` fixtures updated ## Deploy ordering Both new schema fields are required, so this client must deploy after the API serves them (same constraint as `unlimitedRanked` / infra#427). The API already returns both fields. ## Verified Typecheck, ESLint, and the affected test files pass (165 tests). Confirmed the live payloads against a local API: `/users/@me` returns `player.canCreatePublicLobbies` and both subscription tiers in `cosmetics.json` carry the field. 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-authored-by: Claude Fable 5 <noreply@anthropic.com> |
||
|
|
766fda991a |
Render custom crown cosmetics above player names (#4619)
## What Renders each player's crown cosmetic in-game (follow-up to #4618). The crown **skins the first-place crown**: when the tile leader owns a crown cosmetic, their image replaces the default crown icon above their name — on the map name plate and in the hover overlay. Players without the cosmetic keep the default crown. The image pipeline follows custom flags: the server-resolved crown URL rides `PlayerStatic` into the GPU name pass and loads on demand into a runtime `TEXTURE_2D_ARRAY` (layers deduped by URL, square 128×128 cells). ## Changes **GL name pass** - `FlagAtlasArray` cell size is now a constructor parameter; a second instance holds crown images (square cells, no letterbox margins) - Per-player data texture widens 8 → 9 columns (`PLAYER_DATA_COLS`); column 8 carries the crown atlas layer - `status-icon.vert/frag.glsl`: status slot 0 (first-place crown) samples the crown atlas instead of the status atlas when the player has a crown cosmetic — same size and position as the default crown - `WebGLFrameBuilder.syncPlayers` resolves `cosmetics.crown.url` → `PlayerStatic.crown` **DOM** - `getPlayerIcons` swaps the first-place crown icon src for the cosmetic image (hover overlay) **Dev hook**: `localStorage.setItem("dev-crown", "<image url>")` forces a crown in singleplayer (mirrors `dev-pattern`) ## Verified Drove a headless solo game (real-GPU WebGL via ANGLE Metal) with the dev-crown hook, expanded until first place — the cosmetic replaces the default crown above the name on the map and in the hover overlay (default `CrownIcon.svg` absent, cosmetic present). 🤖 Generated with [Claude Code](https://claude.com/claude-code) --------- Co-authored-by: Claude Fable 5 <noreply@anthropic.com> |
||
|
|
8f1bbdd20e |
let admins see clan tags in FFA (#4459)
Resolves #4446 ## Description: left is an admin, right is a normal player: <img width="3834" height="669" alt="image" src="https://github.com/user-attachments/assets/c280485c-ae62-4287-bc66-53a2bb68cb2b" /> admin can see their own tag, and the UON tag, the non-admin can only see their own tag. ## 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: iamlewis <lewismmmm@gmail.com> |
||
|
|
e05dce3437 |
Add crown cosmetic type (#4618)
## What Adds **crowns** as a new cosmetic category, wired end-to-end like flags/skins, plus a Crowns tab in the lobby cosmetics modal (#4617). Catalog shape in cosmetics.json: ```json "crowns": { "gold_crown": { "name": "gold_crown", "url": "...", "affiliateCode": null, "product": null, "priceHard": 5, "artist": "...", "rarity": "common" } } ``` ## Changes - **Core**: `CrownSchema` + optional `crowns` record in `CosmeticsSchema`; `crownName` in `PlayerCosmeticRefs`; resolved `crown: { name, url }` in `PlayerCosmetics` - **Server**: `isCrownAllowed` in the privilege checker — requires a `crown:*` or `crown:<name>` flare, resolves the ref to the catalog URL - **Client**: crown selection persisted under the `crown` localStorage key (stale/unowned selections self-clear), `crownRelationship` + resolve/refs wiring, `"crown"` purchase type, Crowns tab in the store, and a Crowns tab in the cosmetics modal (owned crowns + Default tile; selecting persists and keeps the modal open) - **i18n**: `store.crowns`, `store.no_crowns` - Tests for schema parsing, privilege checks, and cosmetic resolution ## Not in this PR - In-game rendering of `player.cosmetics.crown` (name pass / leaderboards / player panel) - API-side support (`/shop/purchase` accepting `cosmeticType: "crown"`, granting `crown:<name>` flares, serving `crowns` in cosmetics.json) 🤖 Generated with [Claude Code](https://claude.com/claude-code) --------- Co-authored-by: Claude Fable 5 <noreply@anthropic.com> |
||
|
|
7636f4770c |
Merge skin/effects pickers into one lobby Cosmetics modal (#4617)
## What Replaces the three lobby cosmetic buttons (skin, flag, effects) with two: **Flag** and **Cosmetics**. The new Cosmetics button opens a single tabbed modal (`#modal=cosmetics`) with: - **Skins** — the combined patterns + image-skins grid (from TerritoryPatternsModal) - **Effects** — all effect types via the tabbed effects-grid, same layout as the Store ## Changes - New `CosmeticsModal` and `CosmeticsInput` (lobby button previews the selected skin/pattern, shows a "Cosmetics" label on defaults, hidden on CrazyGames via `no-crazygames`) - Removed `TerritoryPatternsModal`, `EffectsModal`, `PatternInput`, `EffectsInput` and their wiring in Main.ts / index.html / LangSelector - Selecting a skin or pattern no longer closes the modal — the tile highlight moves to the new selection (matches the Effects tab behavior) - i18n: added `cosmetics.title/button_title/search`; removed the keys orphaned by the deleted components ## Notes - Deep links to the old `#modal=territory-patterns` and `#modal=effects` no longer resolve - A follow-up PR (crowns cosmetic) stacks on this branch 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-authored-by: Claude Fable 5 <noreply@anthropic.com> |
||
|
FloPinguinandGitHub
|
ef6e8be2be |
Allow mobile players to take part in the aftergame 🙂 (#4615)
## Description: In team games, after the game is over, players should be able to nuke their teammates (the core simulation already allows this via `nukeSpawn()`). On desktop this works because players can use keyboard shortcuts to select nukes directly. However, on mobile, the radial menu unconditionally replaces the attack submenu with "donate gold" when targeting a friendly player, making it impossible to access nukes targeting teammates in the aftergame. The fix checks whether any buildable attack units (AtomBomb, HydrogenBomb, MIRV) are actually available for the target tile. Since `nukeSpawn()` only returns a valid silo for teammate tiles after game over, this naturally detects the aftergame state and shows the attack submenu. During normal gameplay, `nukeSpawn()` blocks teammate nukes so `hasBuildableAttacks` stays false and donate gold is shown as before. ## 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 |
||
|
Navaneeth PrabhaandGitHub
|
1a34321ac8 |
Fix transport ships targeting unreachable inland-lake shores (#4577)
Resolves #4555 ## Description: Fixes the bug where transport boats could not be sent to certain targets (e.g. between the arrows on the Four Islands map) when the attacker's territory was far enough away that it approached the target from its inland-lake side. **Root cause:** The transport landing tile was selected purely by distance. `targetTransportTile()` called `SpatialQuery.closestShore()`, which returns the nearest shore owned by the target using a Manhattan-distance BFS and only checks `isShore && isLand && owned` — it never considers whether that shore is reachable by water. Water bodies are tracked as connected components (an inland lake is a separate component from the surrounding ocean), and the *source* selection (`closestShoreByWater()`) correctly requires the attacker to have a shore in the same water component as the destination. So when the nearest owned shore happened to face a disconnected inland lake, the source search found no shore in the lake's component and the transport silently failed — even though the same target had an ocean-facing shore that the attacker's boats could actually reach. **Fix:** Make destination selection reachability-aware so a lake-facing shore is never chosen when a reachable one exists. - Added `SpatialQuery.closestReachableShore(targetOwner, attacker, tile)`: it first collects the set of water components adjacent to the attacker's own shoreline, then returns the nearest target-owned shore whose water component is in that reachable set. Shores that only border a disconnected water body (an inland lake) are skipped. It returns `null` only when the target has no reachable shore at all. - `targetTransportTile()` now takes the attacker and delegates to `closestReachableShore()` instead of `closestShore()`. Its two callers — `canBuildTransportShip()` and `TransportShipExecution.init()` — already have the attacker in hand and pass it through, so both the build-time check and the actual execution agree on the same reachable destination. - `closestShore()` is left unchanged; this adds a reachability-aware variant rather than altering existing behavior. **Testing performed:** Reproduced the bug first on a generated map with an inland lake enclosed by a thick land moat (confirmed the lake resolves to a separate water component and that `closestShoreByWater()` returns `null` for the lake-facing destination while a reachable ocean shore exists). Added unit tests for `closestReachableShore()` (picks the reachable ocean shore; returns `null` when every target shore is in an unreachable water body) and a `canBuildTransportShip()` regression test for the lake scenario. Full suite: 1878 tests pass; `tsc --noEmit`, ESLint, and Prettier are all clean. ## 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 user-facing text added in this PR - [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: Navaneeth Prabha#0825 |
||
|
Zixer1andGitHub
|
2422a1a7a0 |
feat(anon): memorable, collision-proof animal anonymous names (#4611)
## Description: Makes OpenFront's anonymised names **memorable and collision-proof**. Anonymised lobbies (e.g. OFM tournaments) previously showed opaque names — the `Anon420` fallback and hash-derived civ-tribe names in the overlay — that were hard to remember and could repeat within a viewer's view, so players couldn't reliably track opponents across a match. **What changed** - **`src/core/AnonAnimals.ts`** (new): an 80-word animal bank + `anonAnimalName(slot, offset)`. Consecutive slots map to **distinct** handles — the 80 animals fill first (`round 0` → a bare `AnonWolf`), then a single round digit counts up (`AnonWolf1`, …). At a fixed offset, two slots can never collide. - **`GameServer.anonName`**: assigns each player its **join-order slot** in `allClients` (stable — late-joiners append so existing names never shift; reconnects reuse their slot) plus a **per-viewer offset**. So within any one viewer's view no two players can share a name, while different viewers still see different names for the same player (**anti-team preserved**). Replaces the old per-pair hash and removes the now-dead `anonymousUsername` helper. - **Client fallback** (`genAnonUsername`): draws a random slot through the same helper (no roster client-side → best-effort); the overlay is what guarantees uniqueness in-game. - `createRandomName` (nation/other display names) is untouched. **Desync safety — audited against #4426** #4426 fixed a desync where `PlayerExecution` seeded `removeClusters()` from `player.name()`, a value anonymize-names makes per-client. This change preserves that invariant: | Check | Result | |---|---| | Deterministic state hash reads `name()`? | **No** — `PlayerImpl.hash = simpleHash(id)·(troops+numTilesOwned) + Σ unit.hash`; `UnitImpl.hash = tile + simpleHash(type)·id` | | `removeClusters` seed | `simpleHash(player.id())` — id-based (#4426 fix), untouched | | Where `anonName` is called | only `startInfoFor` / `gameInfo` — per-viewer wire payloads, never the sim | | Archived record | uses `wireGameStartInfo` (real names) — untouched → replay/scoring unaffected | | Net new sim inputs | none — only the display string + server-side roster order | The name is display-only and the simulation is name-blind, so this cannot desync. **Testing** - New `tests/AnonAnimals.test.ts`: the no-collision guarantee (250 distinct slots → 250 distinct names), round roll-over, per-viewer variation, wire-validity/length. - Existing `tests/server/AnonymizeNames.test.ts` overlay suite still passes. - Full suite green locally (`npm test` + `npm run test:coverage`), plus `build-prod`, `eslint`, and `prettier --check .` clean. ## Please complete the following: - [x] I have added screenshots for all UI updates — _N/A, no UI changes (in-game name string only)_ - [x] I process any text displayed to the user through translateText() and I've added it to the en.json file — _N/A, generated handles are not translatable identifiers_ - [x] I have added relevant tests to the test directory — `tests/AnonAnimals.test.ts` ## Please put your Discord username so you can be contacted if a bug or regression is found: <!-- TODO: fill in Discord username --> |
||
|
crunchybbbandGitHub
|
99e6b8ac50 |
Adds impassable terrain to Korea Map (#4604)
> **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 #4603 (issue number) ## Description: Korea was supposed to be a two teams country map, but it released for v32 before impassable terrain existed. Currently the Chinese portion of the map covers far too much area, making it cannot be used for two teams and making it not a true Korea map. The PR will convert the china and russia portions to impassable terrain. - Japan is still on the map to serve as a "island base" or something - One missing south korean province equivalent was added - The map was totally redone (because i deleted the original qgis file for korea) so the terrain and map size is slightly different but it should not be too easy to notice - Adds "Countries" category <img width="1089" height="2189" alt="image" src="https://github.com/user-attachments/assets/82c8729f-cc10-4451-890e-27f02cfde919" /> <img width="367" height="579" alt="Screenshot 2026-07-13 174100" src="https://github.com/user-attachments/assets/e24ad971-c2c5-4791-b092-74e0ff90cefc" /> ## 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: DISCORD_USERNAME crunchybbbbb |
||
|
RickD004andGitHub
|
0cbb0a0b19 |
Standarize the SVG of flags in flags folder, and other flag fixes (#4605)
## Description: ALL OF THESE FLAG FILES ARE ALREADY IN GAME. NO NEW FLAGS WERE ADDED. Standarizes the SVGs of multiple flags. Multiple flags had issues like not having black borders, or having borders that were too thick: armenian SSR, azerbaijan ssr, byelorussian SSR, emirate of asir, emirate of granada, estonian ssr, far Eastern republic, gwent, karelo-finnish ssr, kirguiz ssr, lithuanian ssr, lower silesia, macedonia, ma clique, moldavian ssr, Nepal, polish lithuanian Commonwealth, seville, taiping heavenly, tannu tuva, upper silesia renamed some flags in the menu to more common and accurate names: holy see -> vatican habsburg Austria -> austrian empire circassia -> Adygea macedonia -> macedonian empire alkebulan, kingdom of Portugal and aztec empire used fictional or flags that were not public domain, so they are replaced with public domain and historical accurate ones. Countries.json also gets some missing flags, these flags are fairly generic so they were probably accidentally left out. This change is so that flags have consistent designs for stuff like using them for nations in maps ## 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 |
||
|
RyanandGitHub
|
7dc739b89a |
bugfix for not being in a clan on mobile (#4613)
## Description: fixes a bug that didn't show the join clan popup on mobile before: <img width="464" height="534" alt="image" src="https://github.com/user-attachments/assets/9b7c0e2d-b8e8-4901-ab0e-37768e658722" /> after: <img width="414" height="359" alt="image" src="https://github.com/user-attachments/assets/9a655f24-7ec1-49c9-938b-8a677cf65ab3" /> ## 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 |
||
|
|
4def3ee2cc |
fix(home): remove background wrap-around seam when nav is hidden (#4607)
## Problem The home-screen background layer was lowered with `background-position: center calc(50% + 2cm)` on a `bg-cover` layer sized exactly to the viewport. The shift exposes a 2cm strip at the top with no image content, and since `background-repeat` defaults to `repeat`, CSS fills it by wrapping the image's bottom edge around to the top — a visible seam. The nav bar normally covers that strip, but when a game starts loading, the `in-game` body class hides the nav while the background layer stays visible, exposing the seam. ## Fix A pure translate can't be gap-free (there is no image content above the image's top edge), so the downward shift now comes from oversizing instead: - Layer stays pinned to the viewport top (`top-0`) and extends 4cm below it (`-bottom-[4cm]`) - Image is anchored `center top` The artwork sits ~2cm lower at mid-screen (matching the previous look there) and the image's top edge stays pinned to the viewport top, so no edge is exposed at any viewport size or UI state. ## Verification Drove the real app headless (Playwright): - Home page renders normally with the artwork sitting lower - Reproduced the loading state (`in-game` on body, nav hidden): background renders clean to the top edge, no seam - Control: re-applied the old styles in-browser, which reproduced the exact wrap-around band at the top 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-authored-by: Claude Fable 5 <noreply@anthropic.com> |
||
|
|
62abdcd64e |
fix(nav): show loading spinner on account button until auth resolves (#4606)
## Problem While `/users/@me` is still resolving, the desktop nav account button says "Sign in", then flips to the avatar once the response lands. For logged-in users this briefly (and wrongly) claims they're signed out. ## Fix Start the account pill in a neutral loading state and only commit to a real state once auth resolves: - **DesktopNavBar.ts** — added a small inline spinner (same `border-2 … rounded-full animate-spin` pattern used across the client, e.g. TokenLoginModal, UsernameInput) inside the pill, visible by default; the person icon and "Sign in" text now start `hidden`. - **Main.ts** — `updateAccountNavButton` hides the spinner as soon as it runs; each of its paths (avatar / email badge / sign-in) already un-hides the correct elements. - **CrazyGamesAccountButton.ts** — same spinner hide in `updateCrazyGamesNavButton`, which updates the same pill on CrazyGames instead. The mobile hamburger account item says "Account" rather than "Sign in", so it's unaffected. ## Testing Verified end-to-end with headless Chromium against the dev server: - On load the pill shows only the spinner (sign-in text and person icon hidden). - Once auth resolves it swaps to the person icon + "Sign in" (avatar path exercised by existing `updateAccountNavButton` logic, unchanged). - Stalled `/auth/refresh` via request interception to screenshot the loading state — spinner renders centered in the pill, no layout shift with neighboring nav items. | Loading | Resolved | | --- | --- | | small spinner in pill | person icon + "Sign in" | 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-authored-by: Claude Fable 5 <noreply@anthropic.com> |
||
|
|
376061793a |
Handle ranked play limits in the client (#4602)
## Summary
Client-side handling for the new server-enforced ranked play limits
(infra#427): free players get a lifetime allowance of ranked matches,
then a small daily allowance; subscribers on tiers with the
`unlimitedRanked` entitlement are never limited.
- **Queue rejection**: the matchmaking socket closing with code 1008 and
reason `ranked_limit_reached` now renders a limit-reached view in the
matchmaking modal (message + "Get unlimited ranked" button that opens
the store on the subscriptions tab) and does **not** auto-reconnect.
Auth-failure 1008 (`Invalid session`) is disambiguated by the reason
string and keeps the existing reconnect-with-refreshed-token path; code
1000 ("replaced by another tab") is unchanged. Both 1v1 and 2v2 go
through the same modal, so both queues get identical handling.
- **`/users/@me`**: added required `player.unlimitedRanked: boolean` to
`UserMeResponseSchema`.
- **cosmetics.json**: added required `unlimitedRanked: boolean` to
`SubscriptionSchema`; store subscription tiles now show an "Unlimited
ranked" perk line for tiers that include it.
Display copy avoids hardcoding the limit numbers since the server
constants may be tuned.
## ⚠️ Deploy ordering
Both new schema fields are **required**, so this must ship **after** the
API starts serving them (infra#427). Against the current API,
`/users/@me` parsing fails (players appear logged out) and a catalog
without the subscription field fails the whole cosmetics parse.
## Testing
- Schema tests for both new fields (present / rejected-when-missing) in
`tests/ApiSchemas.test.ts` and `tests/CosmeticSchemas.test.ts`; full
suite, tsc, ESLint, Prettier all pass.
- Verified in the running app (headless Chromium): forced the modal into
the limit-reached state, confirmed the rendered view, and confirmed the
upsell click closes matchmaking and opens the store on the subscriptions
tab.
- Not verifiable locally (needs deployed infra#427): the real close
frame, the midnight-UTC reset, and the perk line against a real catalog
— covered by the handoff QA checklist.
🤖 Generated with [Claude Code](https://claude.com/claude-code)
Co-authored-by: Claude Fable 5 <noreply@anthropic.com>
|