PokéSurvivor Updates · 2026-11-04: 4 November: online account pulls and service changes

Game update November 4, 2026 · Article updated November 5, 2026

Account pulls now require the original server. Check failed pulls, save conflicts, friends, rooms and rankings; guest play and shop rules remain available.

Changes at a glance

From the original 4 November update, a signed-in cloud account sends its pull to the original account service. If you are offline or that request fails, the client reports an error and does not silently perform a local pull. Guest pulls still use the local algorithm. The official notice says ordinary gameplay and the shop are unchanged; this connection requirement concerns account pulls, not every offline action.
The current original client retains Firebase sign-in but reads and writes cloud saves through the original account service instead of loading direct Firestore/Realtime Database clients. This describes the public client transport, not undisclosed backend storage. A missing-save response means no save was found for that request; a failed request is not an empty account or a successful sync. Local saves, signed-copy preservation and cross-tab protection remain relevant.
In this original snapshot, room signalling always uses WebSocket; the old local RTDB room switch is no longer a supported fallback. WebRTC/TURN and the existing host queue are separate and retain their combat behaviour. Friends and invitations now refresh through the original service rather than direct database subscriptions. Typical polling is about 9.6–14.4 seconds in menus and 36–54 seconds while playing, with network delays possible; hidden pages skip periodic requests and refresh when visible again.
The original client now consistently uses its ranking service; earlier advice that Firestore is the default and the service is optional describes older snapshots. Valid signed-run credentials still govern the heartbeat, called every 60 seconds of game time. Seal acquisition retains up to eight attempts, three-second pauses, 15-second request timeouts and an 80-second overall budget; authentication rejection stops retries. This does not prove the private service's internal implementation or uptime.
Original administrator gifts and removals now read/write through the original service, retrying revision conflicts up to three times. The existing non-negative economy, collection revocations and partner fallback rules remain; this Wiki does not grant administrator access or change balances. The original restricted moderation UI adds a server-provided suspect list (coin-based results can be limited to 500; reports may add entries), reasons/reports and economy figures, with dismiss and explicitly confirmed ban actions. A flag is not proof of cheating and does not itself demonstrate an automatic ban.
The public client also adds a startup maintenance check with a four-second request timeout. Mode “servidor”, an unavailable response or no valid mode permits normal startup; another returned string shows the original server-migration maintenance notice. This is a conditional screen, not evidence that maintenance is active now. The notice asks players to return later; preserve your browser's save rather than clearing it because this screen appears.
Checked on 5 November: the configured JPTER78/pokesurvivor repository, its HEAD and previously readable commit URLs return 404. This does not establish whether it is private, moved or removed, and is not evidence of no update. The original legal/settings UI also removes its GitHub source buttons. Historical source citations remain attributed to their dates; this review instead uses the official 4 November news plus a SHA-256-frozen public eae98df1a1 client/version snapshot. It is a public release identifier, not a fabricated Git commit. The complete Git range since d2bf542d remains unavailable; the last checked Git tip stays c121040f.

Account pulls require a connection

From the original 4 November update, a signed-in cloud account sends its pull to the original account service. If you are offline or that request fails, the client reports an error and does not silently perform a local pull. Guest pulls still use the local algorithm. The official notice says ordinary gameplay and the shop are unchanged; this connection requirement concerns account pulls, not every offline action.

Check the active banner and enough tickets first. The client locks the pull button while processing, waits for an outstanding save and reuses one operation ID during retries. A revision conflict merges the returned save and retries with a new revision, up to four loop attempts; a transport failure only gets an initial retry, not four guaranteed network retries. Closed banner, insufficient tickets, offline and general failure are separate outcomes. A successful response supplies canonical coins, both ticket balances, ledger, collection, shinies, banner pity and total pulls before the result animation.

After a timeout, reconnect and let the same account sync; inspect its actual tickets, collection and pity before trying again. A missing response does not prove the server never processed the pull or guarantee a refund. Do not clear storage or edit signed copies to repair it. The published local probability, pity, ten/100-pull costs, duplicate refunds and shiny formulas are unchanged in this client snapshot. Wiki calculators remain planning tools: enter the latest confirmed account values; they cannot execute, restore or certify a real server pull.

Cloud save conflicts and confirmed balances

The current original client retains Firebase sign-in but reads and writes cloud saves through the original account service instead of loading direct Firestore/Realtime Database clients. This describes the public client transport, not undisclosed backend storage. A missing-save response means no save was found for that request; a failed request is not an empty account or a successful sync. Local saves, signed-copy preservation and cross-tab protection remain relevant.

A successful save can return authoritative economy corrections, including coins, both tickets, ledger, removals, permanent upgrades, bag and TMs. On revision conflict the client merges the returned copy and retries a newer revision. A rate-limit response with a gap keeps the save pending and waits the returned seconds (20 by default), plus half a second. A rejected save can explicitly leave the newest changes only in this browser. Keep that browser's data and wait for an actual accepted sync before changing device or clearing storage.

Requests require a current signed-in user. The wrapper refreshes the authentication token once after a 401 response; repeated authentication failure is not successful saving. Its usual timeout is 12 seconds (15 for pulls), and network failures, server errors and unreadable responses are treated as unavailable. Reconnect and confirm the account's sync state; the Wiki cannot repair credentials or infer accepted balances from a spinner.

Rooms, friends and delayed status

In this original snapshot, room signalling always uses WebSocket; the old local RTDB room switch is no longer a supported fallback. WebRTC/TURN and the existing host queue are separate and retain their combat behaviour. Friends and invitations now refresh through the original service rather than direct database subscriptions. Typical polling is about 9.6–14.4 seconds in menus and 36–54 seconds while playing, with network delays possible; hidden pages skip periodic requests and refresh when visible again.

The received friend entries initially have offline/not-playing status and an empty room. That badge is not reliable proof that a friend cannot join in this snapshot: try an invitation or a known room and allow a refresh. Invitations expire after three minutes; repeating the same invitation within 20 seconds is suppressed. Actions can also refresh the list. Nickname/profile updates retain a six-hour interval and 800 ms debounce, with a ten-minute profile cache; a profile rate-limit gap waits the returned seconds (five by default) plus 0.2 seconds. These are client timing rules, not delivery guarantees.

Rankings now use the original service

The original client now consistently uses its ranking service; earlier advice that Firestore is the default and the service is optional describes older snapshots. Valid signed-run credentials still govern the heartbeat, called every 60 seconds of game time. Seal acquisition retains up to eight attempts, three-second pauses, 15-second request timeouts and an 80-second overall budget; authentication rejection stops retries. This does not prove the private service's internal implementation or uptime.

The 120-second overall and 600-second Pokémon upload gates, all-time damage preservation, friend top-50 scope, 8/6/2-hour caches and the 5c97df2e cumulative damage cap are unchanged. The run timeline therefore keeps its actual scoring calculations and old-share restoration. Transport changes do not increase combat damage or alter event dates; refresh the correct ranking and check upload eligibility before treating a delayed list as lost progress.

Gifts, moderation and account deletion

Original administrator gifts and removals now read/write through the original service, retrying revision conflicts up to three times. The existing non-negative economy, collection revocations and partner fallback rules remain; this Wiki does not grant administrator access or change balances. The original restricted moderation UI adds a server-provided suspect list (coin-based results can be limited to 500; reports may add entries), reasons/reports and economy figures, with dismiss and explicitly confirmed ban actions. A flag is not proof of cheating and does not itself demonstrate an automatic ban.

Original account deletion still requires reauthentication, then requests the original account service before social/ranking cleanup and Firebase user deletion. This client permits continuation after a 403 as well as a 200 response; that is not proof every backend record was erased. Use the original account controls and verify their actual result with that service. Wiki tool JSON, local planning data and the independently embedded game are separate; none of these buttons or explanations transfers deletion authority to this Wiki.

Original maintenance screen and retry behaviour

The public client also adds a startup maintenance check with a four-second request timeout. Mode “servidor”, an unavailable response or no valid mode permits normal startup; another returned string shows the original server-migration maintenance notice. This is a conditional screen, not evidence that maintenance is active now. The notice asks players to return later; preserve your browser's save rather than clearing it because this screen appears.

On that maintenance screen, “Try again” reloads the page. An automatic check is scheduled every 60–75 seconds: it reloads if the maintenance mode permits startup (including a failed mode read) or if a newly readable version differs from the initially readable version. Otherwise it schedules another check. The service worker itself is unchanged in this comparison; a recent offline shell does not make signed-in pulls or cloud sync available offline. This Wiki's embedded independent release has not received this startup change.

Public client evidence and unavailable Git history

Checked on 5 November: the configured JPTER78/pokesurvivor repository, its HEAD and previously readable commit URLs return 404. This does not establish whether it is private, moved or removed, and is not evidence of no update. The original legal/settings UI also removes its GitHub source buttons. Historical source citations remain attributed to their dates; this review instead uses the official 4 November news plus a SHA-256-frozen public eae98df1a1 client/version snapshot. It is a public release identifier, not a fabricated Git commit. The complete Git range since d2bf542d remains unavailable; the last checked Git tip stays c121040f.

Current original snapshot and tool model

Original public client eae98df1a1 (version timestamp 4 November 23:19:53 UTC), reviewed 5 November. Comparing complete normalized client modules found 101 unchanged and 13 changed/new modules. Executed catalog comparisons retain 966 Pokémon, 103 moves, 97 evolutions, 4,830 stat checks and 412 move-level transitions; gacha, combat, shop and progression formulas remain unchanged. All thirteen Wiki tools retain calculations, sharing and JSON recovery; use confirmed account balances for planning. Catalog source d567c6da, execution/upload model 5c97df2e, seasonal rules f7fbcfc4 and calendar d667c216 remain separately versioned.

The game embedded here remains the independent survivorpoke.com/play/ release 3667bcad81 with selected f7 seasonal changes; Community calculations retain their own fixed model. The new original account service and online-pull behaviour have not been deployed into that embedded game by this Wiki update. These versions must not be treated as identical.

Previous and next updates

2026-11-02 · Browser saves and the creator’s live/video data

Game data & sources

The linked game files show where these stats, costs and rules come from. Updates to the game may change them.

Data version: d567c6da

Data version →