PokéSurvivor Updates · 2026-11-02: Browser saves and the creator’s live/video data

Game update November 2, 2026 · Article updated November 3, 2026

The original’s 2 November follow-up moves live, latest-video and video-notice data to a separate repository. Save recovery and administrator guidance remain available; reviewed 3 November.

Changes at a glance

The original now reads the live branch of JPTER78/pokesurvivor-live: live.json supplies the live badge, video.json the latest normal-video banner and aviso.json a separately chosen video notice. The former producer workflow was removed from the game repository and exists in the separate feed repository. This explains why an old cached client or the separately embedded game can show different channel information. This Wiki keeps its own existing YouTube and Discord destinations; this maintenance does not run, move or change either site’s workflows or the embedded game.
The original clients request these feeds with no-cache about every five minutes while visible, with a 295-second minimum request gap; returning to a visible page can trigger a check. The live badge needs live=true, an 11-character video ID and current time minus at below 90 minutes. A failed request leaves the last client state in place; it does not prove a stream ended. The banner accepts a valid ID and truncates its title to 120 characters. The notice separately checks its desde-inclusive, hasta-exclusive window when fetching, then checks menu/overlay/input conditions every two seconds and remembers its ID in that browser’s storage. Thus the latest-video banner and notice can intentionally point to different videos; the polling gap and failed reads can delay what the client shows.
The separate public producer is scheduled every five minutes, with possible GitHub delays. Live detection reads the first five cards of the channel’s Streams tab, retries a missing list up to three times with five-second waits and preserves existing data for an unrecognized page or missing badge format. It writes when live/id changes, or refreshes a continuing live stream after 30 minutes. An unchanged live=false state can therefore retain an old at date. Latest normal video is selected from the first seven Videos cards, excluding upcoming/live cards; it writes only when ID or title changes and limits the title to 120 characters. An old unchanged video timestamp is not proof the updater stopped. aviso.json is maintained separately by hand. Manual test mode does not publish live/video changes. These are the author’s source rules, not a promise of current on-air status.
The follow-up adds save-signature compatibility entries while retaining prior entries and the same write signature. The preserved-copy recovery and administrator-removal rules explained here remain in effect for the original; clearing storage or editing a signature is not a recovery step. The internal administrator-list change does not grant Wiki users account access. Executed source comparison keeps 966 Pokémon, 103 moves, 97 evolutions, all levels, legal learning/default-start rules and all 13 tools unchanged. Combat catalog d567c6da, execution/upload 5c97df2e and seasonal/calendar models retain their own versions; existing tool share links and JSON imports keep their formats.
The original changelog describes an older cached client or old tab failing to recognize the newer browser copy and falling back to an older cloud save. Source 23c0d653 now keeps an unreadable copy with a signed-save suffix in a separate stash for that account, instead of simply losing it when the working cache is replaced. A newer saved updated timestamp takes priority over an older incoming stash. Another tab presenting an unrecognized signed copy also preserves it and rotates the local device identifier. Unsigned JSON is not accepted as a valid cloud cache by this mechanism.
After updating, a stash that the current client can validate is merged with the readable browser and cloud saves. Its presence disables the two-minute fast-reload shortcut so the client attempts a cloud read; if the server is unavailable, a readable preserved copy can still load with offline sync pending. The stash is removed only after the merged browser cache is written successfully. A still-unreadable stash expires only when its saved updated time is more than 40 days old; this is not a guaranteed 40-day backup from the moment of preservation. A readable stash is recoverable even when older. Existing extension-import markers suppress stash restoration; the earlier 20 November UTC legacy-migration deadline remains separate. Preserve/export any accessible current save first, close old game tabs, reopen the updated original online in the same browser profile and account, then check the collection, balance and sync status. Avoid clearing site storage or removing the installed app before preserving the copy. This cannot recreate progress that was already overwritten or deleted, or undo an administrator withdrawal.
In the updated original service worker, a successful non-redirected network visit to the game root or index.html also replaces the canonical offline index.html copy, including visits with query parameters and installations under a subpath. Offline game navigation prefers that copy; other cached document navigation may ignore query parameters. A failed or redirected response does not replace the good offline copy, and missing scripts/images are not served the game HTML. An online visit to the updated original is needed before the new page can become the offline fallback. “Last successfully cached page” does not mean a fresh cloud save or live online services while offline.
The original administrator Accounts panel now has a separate Remove action alongside Give, with a confirmation. It can subtract coins, single tickets and ×10 tickets from an existing cloud save. Inputs and current balances are floored and normalized to 0–1,000,000,000; the debit is limited to that normalized balance. For example, removing 120 coins from 100 leaves 0. A transaction records the administrator debit, increments the save revision and updates the server timestamp. This is not a player shop purchase, public redemption code or a new fee.
Removing a normal Pokémon removes both its normal and shiny ownership; the shiny-only option keeps the normal Pokémon. The save records a separate revocation timestamp for each form. Loading and merging remove ownership whose acquisition time is at or before that marker, and merging keeps the later marker from either save. A removed partner falls back to an owned starter, otherwise the first owned species; an unavailable shiny partner appearance is cleared. A genuinely later acquisition can survive when the other save has no stale ownership entry; the merge caveat below matters.
The original panel says a Pokémon earned again can be kept. Source execution confirms a narrower condition: DB.merge first chooses the earlier ownership acquisition record, then applies revocation. If another device or backup still contains the old record, merging can remove even a legitimate later capture. Do not repeatedly import that stale backup to restore a removed Pokémon. Keep a backup of the current state, finish cloud synchronization, then check the live account; if the new capture disappears again, report that sequence to the original game's support. This Wiki has documented the reproduced source behavior; it has not changed the original backend or your save.
After an administrator adjustment, enter the balance actually shown after synchronization in the gacha or upgrade planner. Update the collection tracker manually for removed normal or shiny ownership. These Wiki tools do not read or alter your game account. Their saved configurations, sharing, JSON import/export and calculations retain the existing format; restoring a Wiki configuration does not reverse a game-account removal. Prices, pull odds, battle statistics and move upgrade formulas did not change in this update.

Where the original gets its channel notices

The original now reads the live branch of JPTER78/pokesurvivor-live: live.json supplies the live badge, video.json the latest normal-video banner and aviso.json a separately chosen video notice. The former producer workflow was removed from the game repository and exists in the separate feed repository. This explains why an old cached client or the separately embedded game can show different channel information. This Wiki keeps its own existing YouTube and Discord destinations; this maintenance does not run, move or change either site’s workflows or the embedded game.

Why the live badge or video notice may differ

The original clients request these feeds with no-cache about every five minutes while visible, with a 295-second minimum request gap; returning to a visible page can trigger a check. The live badge needs live=true, an 11-character video ID and current time minus at below 90 minutes. A failed request leaves the last client state in place; it does not prove a stream ended. The banner accepts a valid ID and truncates its title to 120 characters. The notice separately checks its desde-inclusive, hasta-exclusive window when fetching, then checks menu/overlay/input conditions every two seconds and remembers its ID in that browser’s storage. Thus the latest-video banner and notice can intentionally point to different videos; the polling gap and failed reads can delay what the client shows.

How the feed is refreshed, and what old timestamps mean

The separate public producer is scheduled every five minutes, with possible GitHub delays. Live detection reads the first five cards of the channel’s Streams tab, retries a missing list up to three times with five-second waits and preserves existing data for an unrecognized page or missing badge format. It writes when live/id changes, or refreshes a continuing live stream after 30 minutes. An unchanged live=false state can therefore retain an old at date. Latest normal video is selected from the first seven Videos cards, excluding upcoming/live cards; it writes only when ID or title changes and limits the title to 120 characters. An old unchanged video timestamp is not proof the updater stopped. aviso.json is maintained separately by hand. Manual test mode does not publish live/video changes. These are the author’s source rules, not a promise of current on-air status.

Save compatibility and the tool versions stay separate

The follow-up adds save-signature compatibility entries while retaining prior entries and the same write signature. The preserved-copy recovery and administrator-removal rules explained here remain in effect for the original; clearing storage or editing a signature is not a recovery step. The internal administrator-list change does not grant Wiki users account access. Executed source comparison keeps 966 Pokémon, 103 moves, 97 evolutions, all levels, legal learning/default-start rules and all 13 tools unchanged. Combat catalog d567c6da, execution/upload 5c97df2e and seasonal/calendar models retain their own versions; existing tool share links and JSON imports keep their formats.

Why an update could appear to roll back progress

The original changelog describes an older cached client or old tab failing to recognize the newer browser copy and falling back to an older cloud save. Source 23c0d653 now keeps an unreadable copy with a signed-save suffix in a separate stash for that account, instead of simply losing it when the working cache is replaced. A newer saved updated timestamp takes priority over an older incoming stash. Another tab presenting an unrecognized signed copy also preserves it and rotates the local device identifier. Unsigned JSON is not accepted as a valid cloud cache by this mechanism.

What is recovered, and what to do first

After updating, a stash that the current client can validate is merged with the readable browser and cloud saves. Its presence disables the two-minute fast-reload shortcut so the client attempts a cloud read; if the server is unavailable, a readable preserved copy can still load with offline sync pending. The stash is removed only after the merged browser cache is written successfully. A still-unreadable stash expires only when its saved updated time is more than 40 days old; this is not a guaranteed 40-day backup from the moment of preservation. A readable stash is recoverable even when older. Existing extension-import markers suppress stash restoration; the earlier 20 November UTC legacy-migration deadline remains separate. Preserve/export any accessible current save first, close old game tabs, reopen the updated original online in the same browser profile and account, then check the collection, balance and sync status. Avoid clearing site storage or removing the installed app before preserving the copy. This cannot recreate progress that was already overwritten or deleted, or undo an administrator withdrawal.

The earlier fast-reload rules below apply only when no readable preserved copy is being restored. Before an automatic version reload, the original first waits for pending sync for up to 6 seconds and records a same-tab reload marker only if the save status is already OK. On the next startup, a valid cloud cache with a positive stored revision may be reused without an initial server read only while that marker is less than 2 minutes old and no extension-recovery marker is present. The marker is consumed once. Otherwise the normal server/cache merge runs. This reduces redundant reads; it does not prove that another device’s latest progress has been fetched. Keep the original browser/profile, check the actual save status and reconnect with the same original account when troubleshooting. Do not clear or hand-edit storage to force recovery.

Installed app: the offline page follows the last successful visit

In the updated original service worker, a successful non-redirected network visit to the game root or index.html also replaces the canonical offline index.html copy, including visits with query parameters and installations under a subpath. Offline game navigation prefers that copy; other cached document navigation may ignore query parameters. A failed or redirected response does not replace the good offline copy, and missing scripts/images are not served the game HTML. An online visit to the updated original is needed before the new page can become the offline fallback. “Last successfully cached page” does not mean a fresh cloud save or live online services while offline.

Save-preservation storage and account deletion

The original keeps the preservation copy in that browser profile, separated by account. Its account-deletion code now also removes that account’s local stash. This is source behavior, not a request to delete anything. The Wiki does not access this stash, submit account operations or change player data; the embedded game remains a separate version.

Administrator removals: balances stay nonnegative

The original administrator Accounts panel now has a separate Remove action alongside Give, with a confirmation. It can subtract coins, single tickets and ×10 tickets from an existing cloud save. Inputs and current balances are floored and normalized to 0–1,000,000,000; the debit is limited to that normalized balance. For example, removing 120 coins from 100 leaves 0. A transaction records the administrator debit, increments the save revision and updates the server timestamp. This is not a player shop purchase, public redemption code or a new fee.

Removed Pokémon, shiny forms and partner fallback

Removing a normal Pokémon removes both its normal and shiny ownership; the shiny-only option keeps the normal Pokémon. The save records a separate revocation timestamp for each form. Loading and merging remove ownership whose acquisition time is at or before that marker, and merging keeps the later marker from either save. A removed partner falls back to an owned starter, otherwise the first owned species; an unavailable shiny partner appearance is cleared. A genuinely later acquisition can survive when the other save has no stale ownership entry; the merge caveat below matters.

Old-backup merge limitation in source 90cdd941

The original panel says a Pokémon earned again can be kept. Source execution confirms a narrower condition: DB.merge first chooses the earlier ownership acquisition record, then applies revocation. If another device or backup still contains the old record, merging can remove even a legitimate later capture. Do not repeatedly import that stale backup to restore a removed Pokémon. Keep a backup of the current state, finish cloud synchronization, then check the live account; if the new capture disappears again, report that sequence to the original game's support. This Wiki has documented the reproduced source behavior; it has not changed the original backend or your save.

Use the current balance and ownership in Wiki tools

After an administrator adjustment, enter the balance actually shown after synchronization in the gacha or upgrade planner. Update the collection tracker manually for removed normal or shiny ownership. These Wiki tools do not read or alter your game account. Their saved configurations, sharing, JSON import/export and calculations retain the existing format; restoring a Wiki configuration does not reverse a game-account removal. Prices, pull odds, battle statistics and move upgrade formulas did not change in this update.

Original source c121040f and the embedded-game boundary

Reviewed 3 November: original public 064519c8ee corresponds to c121040f, including all seven commits after d2bf542d. The combat catalog retains 966 Pokémon, 103 moves, 97 evolutions, all levels, legal learning pools and default-start exceptions. Catalog d567c6da; seasonal combat/rewards f7fbcfc4; calendar d667c216; execution and upload calculations 5c97df2e. New room/cache/gift handling is versioned separately from those formulas. All 13 tools and their historical share/import models remain available. The observed embedded game remains 3667bcad81 with selective f7 integration, and Community calculations remain 395a0e47/559ca0a7c8; these original-client changes are not attributed to them.

Previous and next updates

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 →