Error wiki

What it means: The client asked the local Steam client for an authentication ticket (SteamUser.GetAuthSessionTicket) and didn't get one back.

Cause: This is client-side — Steam must be running, signed in, and online (not in Offline Mode) so it can validate the ticket. The Steam ID is available offline, but the ticket itself needs a live Steam connection. If the server console shows no request when this appears, it's Steam, not Bismuth.

In Bismuth: Make sure Steam is online and signed in. For a fully offline setup the ticket dependency can be patched out of the client the same way the EAC check was.

What it means: The login or matchmaking call returned an HTTP error status. The client maps it: 409 → code 5 ("already logged in elsewhere"); any other ≥ 400 → generic login failure.

Cause: An endpoint in the login chain returned a 4xx/5xx. The usual culprit is a catch-all that 404s an unmapped endpoint — to this client, every unmapped endpoint becomes a login-breaker.

In Bismuth: Critical login-flow endpoints return real 200 responses, and unmapped ones are kept from hard-failing the boot. The server console names the endpoint that returned the bad status.

What it means: After the menu loads, the client silently refreshes its session token (POST /auth/connect/token, grant_type=refresh_token). If that returns 400, the client logs you out and reboots to the title.

Cause: The refresh token was rejected — commonly because tokens are held in memory and the server restarted, or because the session was bound to the wrong account (e.g. a cached account id pointing at a seeded NPC like Coach).

In Bismuth: The refresh grant re-binds by platform id and re-issues a session instead of 400-ing, and platform logins resolve by platform identity so a stale cached account id can't hijack the wrong account.

What it means: The login helper attaches an anti-cheat challenge response to the token request. When EAC is inactive, EACManager.GenerateChallengeResponse returns null and the request throws before it's even sent.

Cause: The original game shipped with Easy Anti-Cheat; a private server has no EAC backend, so the challenge can't be generated normally.

In Bismuth: The client binary is patched so the challenge method echoes its input, and the server accepts whatever eac_response arrives. No EAC backend required.

What it means: One of the "core" systems the client initializes after login failed to get valid data, so startup aborts. The on-screen text doesn't say which one.

Cause: Usually a required config response was empty or the wrong shape. Known triggers: config/v2 served without real LevelProgressionMaps / AutoMicMutingConfig; a settings write that didn't return 200; or room entry returning an empty body, which sends the client into an endless token-refresh loop.

In Bismuth: config/v2 serves real captured data, settings writes are acknowledged, and room entry returns a proper game-session payload.

What it means: The client tried to deserialize a response into a specific type and the JSON shape didn't match.

Cause: An endpoint the client expects to be an object was returned as an empty array [] (or vice-versa). Some throw a cast exception that crashes the game — settings/v2 is a list, and returning {} for it hard-crashes.

In Bismuth: Each response's exact shape was recovered from the client's deserializer, so object endpoints return objects and list endpoints return lists.

What it means: The objectives system failed to fetch your daily/weekly progress.

Cause: GET api/objectives/v1/myprogress wasn't served (404). Its response is an object with Objectives and ObjectiveGroups arrays, so an empty-array fallback fails too.

In Bismuth: The endpoint returns { "Objectives": [], "ObjectiveGroups": [] } — no objectives yet, but a valid shape.

What it means: The client tried to enter a room (during boot it loads the Dorm via BootSequence.LoadDormRoom) and couldn't establish the realtime session.

Cause: The room-entry response (goto/room/{name}) was missing the fields the client connects to Photon with. It must be { "errorCode": 0, "roomInstance": {…} } with camelCase keys including photonRegionId, photonRoomId, and a valid location; wrong casing leaves every field null.

In Bismuth: Room entry returns the exact roomInstance shape so the client gets its region + Photon room and proceeds to the realtime layer.

What it means: The room-entry response gave a location value the client can't map to a Unity scene.

Cause: location is an enum (Dorm = 0, Rec Center = 1, …). An out-of-range value (or a missing one defaulting to INVALID / -1) trips this.

In Bismuth: Room entry always sends a valid location — the Dorm resolves to 0, and known rooms map to their scene ids.

What it means: The host tried to flip a room into/out of "game in progress" and the call didn't take.

Cause: A room/session state endpoint wasn't served or rejected the update.

In Bismuth: Non-critical for entering a room; it's acknowledged so it doesn't block play. Full matchmaking-state sync is part of the Photon realtime layer still being built.

What it means: The avatar system couldn't fetch your saved outfit slots.

Cause: GET api/avatar/v3/saved returned 404. The client parses a list of slot objects.

In Bismuth: The endpoint returns an empty list (no saved outfits yet) instead of 404. Saving (v3/saved/set) is acknowledged too.

What it means: The inventory system couldn't fetch the items/equipment you own.

Cause: GET api/equipment/v2/getUnlocked (and the consumables equivalent) returned 404. The client parses a list and treats the HTTP error as a hard failure.

In Bismuth: Both api/equipment/v2/getUnlocked and api/consumables/v2/getUnlocked return empty lists — a fresh account owns nothing yet.

What it means: The client couldn't parse your avatar's outfit string, so it falls back to a random default look.

Cause: An empty or malformed OutfitSelections on the avatar response. Harmless — it just means no saved look.

In Bismuth: The avatar response returns valid (empty) outfit fields; you get the default look until you customize and save.

What it means: The realtime notifications channel (friend requests, messages, invites) couldn't connect.

Cause: The SignalR hub negotiate (POST /hub/v1/negotiate) or its WebSocket upgrade/handshake failed.

In Bismuth: A SignalR hub is served at /hub/v1 with a protocol-v0 negotiate and JSON handshake, so notifications connect.

What it means: A boot-time fetch the client treats as mandatory failed.

Cause: An early endpoint like gameconfigs or the version check returned nothing usable, or the server was unreachable.

In Bismuth: Boot endpoints serve real captured data, so the required-data step completes.

What it means: The client couldn't fetch your moderation/ban status at login.

Cause: PlayerReporting/v1/moderationBlockDetails returned the wrong shape — it expects a single object, and a catch-all [] reads as malformed.

In Bismuth: The moderation endpoint returns a clean "no active moderation" object so login proceeds.

What it means: The server is advertising downtime; the client shows its maintenance screen.

Cause: This is intentional — driven by config/v2's ServerMaintenance.StartsInMinutes (0 = down now, a positive value = an advance-warning countdown).

In Bismuth: Toggle it with the MAINTENANCE setting. It is the correct way to show downtime — returning a raw 503 instead breaks boot with "failed to obtain required data".

What it means: You meant to show maintenance, but the client shows a generic data-failure error instead.

Cause: Downtime was signalled with an HTTP 503 gate. The client doesn't read that as "maintenance" — it reads it as a failed required fetch.

In Bismuth: Maintenance is signalled in-band via config/v2, never with a 503, so the proper "under maintenance" screen shows.

Message: "Failed to connect to Bismuth Servers (error code: summer)" / "Bismuth Servers name server query failed (error code: summer)".

What it means: The very first step failed — the client queried the name server (the /2/ service-discovery endpoint that lists every service URL) and didn't get a usable answer. It's tied to the client's network-connectivity check, so it fires when the server is unreachable or the response was malformed.

In Bismuth: Make sure the server is running and the client points at the right host (the build is baked to http://localhost:3000/2/). If /2/ doesn't return the service map (or returns an error), you get summer.

Message: "Failed to connect to Bismuth Servers (error code: locker)".

What it means: The client's network-connectivity test failed — before talking to the game servers it pings a known URL (Google's generate_204) to confirm it has internet. If that ping fails it assumes you're offline.

In Bismuth: Usually a local network / firewall issue, not the server. Check the machine actually has internet and nothing is blocking the client's outbound requests.

Message: "Failed to connect to Bismuth Servers (error code: notebook / pencil / student)".

What it means: The name server resolved, but a connection to one of the actual backend services failed afterward — different codes mark different failure points (an endpoint unreachable, a timeout, or a bad HTTP response) during the connect handshake.

In Bismuth: Confirm the service URLs returned by /2/ all point at a running server, and that those endpoints respond (not a 5xx / connection-refused). These typically mean a service the client expected was down mid-connect.

Message: "Error code FROSTBITE."

What it means: A generic catch-all error the client shows when something went wrong that doesn't map to a more specific code.

In Bismuth: Check the server console for the request that failed right before it — FROSTBITE itself doesn't name the cause, so the surrounding logs are where the real reason lives.