Mise à jour du jeu · Article mis à jour
Principaux changements
- L’original lit désormais la branche live de JPTER78/pokesurvivor-live : live.json fournit le badge de direct, video.json la bannière de dernière vidéo normale et aviso.json une annonce choisie séparément. Le workflow producteur a quitté le dépôt du jeu et existe dans le dépôt de données. Un ancien client en cache ou le jeu intégré distinct peut donc afficher d’autres informations. Cette Wiki conserve ses liens YouTube et Discord ; elle ne déplace ni n’exécute ces workflows et ne modifie pas le jeu intégré.
- Le client demande ces données sans cache environ toutes les cinq minutes lorsque la page est visible, avec au moins 295 secondes entre requêtes ; revenir à la page peut lancer une vérification. Le badge exige live=true, un ID de 11 caractères et heure actuelle moins at inférieure à 90 minutes. Un échec conserve l’état précédent et ne prouve pas la fin d’un direct. La bannière accepte un ID valide et limite le titre à 120 caractères. L’annonce vérifie à la lecture la fenêtre depuis desde inclus jusqu’à hasta exclu, puis examine menu, superpositions et saisie toutes les deux secondes et mémorise l’ID dans ce navigateur. Bannière et annonce peuvent donc viser volontairement deux vidéos ; délais de lecture et échecs peuvent retarder l’affichage.
- Le producteur public séparé est planifié toutes les cinq minutes, avec des retards GitHub possibles. Il lit les cinq premières cartes de Streams, réessaie une liste manquante jusqu’à trois fois avec cinq secondes d’attente et conserve les données si la page ou les badges ne sont pas reconnus. Il écrit si live/ID change, ou après 30 minutes d’un direct continu ; un état false inchangé peut donc garder un ancien at. La vidéo normale est choisie parmi les sept premières cartes de Videos, sans premières à venir ni directs ; seuls les changements d’ID ou de titre entraînent une écriture, avec titre limité à 120 caractères. Une ancienne date inchangée ne prouve pas l’arrêt de l’actualisation. aviso.json est géré manuellement à part. Le mode test ne publie pas de changement live/video. Ce sont les règles source de l’auteur, pas une garantie de direct actuel.
- Le suivi ajoute des entrées de compatibilité de signature en conservant les anciennes et la même signature d’écriture. Les règles de récupération et de retrait administratif expliquées ici restent applicables à l’original ; effacer le stockage ou modifier une signature n’est pas une méthode de récupération. Le changement interne de liste d’administrateurs n’accorde aucun accès aux comptes via la Wiki. La comparaison exécutée conserve 966 Pokémon, 103 capacités, 97 évolutions, niveaux, apprentissage/départs légaux et les 13 outils. Catalogue d567c6da, exécution/envoi 5c97df2e et modèles saison/calendrier restent distincts ; partages et imports JSON gardent leurs formats.
- Le changelog original décrit un ancien client en cache ou un vieil onglet ne reconnaissant pas la copie récente du navigateur, puis reprenant une sauvegarde cloud plus ancienne. La source 23c0d653 met désormais la copie illisible portant une signature à l’écart pour ce compte avant de remplacer le cache de travail. La copie dont le champ updated est le plus récent est prioritaire. Une copie signée non reconnue provenant d’un autre onglet est également conservée et l’identifiant local de l’appareil est renouvelé. Ce mécanisme n’accepte pas un JSON non signé comme cache cloud valide.
- Après la mise à jour, une copie mise à l’écart que le client peut valider est fusionnée avec les sauvegardes lisibles du navigateur et du cloud. Sa présence désactive le raccourci de rechargement de deux minutes : une lecture cloud est tentée. Si le serveur est indisponible, une copie conservée lisible peut s’ouvrir avec synchronisation hors ligne en attente. Elle n’est effacée qu’après l’écriture réussie du cache fusionné. Une copie toujours illisible expire si son updated remonte à plus de 40 jours ; ce n’est pas une sauvegarde garantie 40 jours après sa mise à l’écart. Une copie lisible reste récupérable même plus ancienne. Les marqueurs d’import par extension empêchent cette restauration ; l’échéance de migration du 20 novembre UTC reste distincte. Préservez/exportez d’abord tout save accessible, fermez les anciens onglets, ouvrez l’original actualisé en ligne avec le même profil et compte, puis vérifiez collection, solde et synchronisation. Ne videz pas les données du site et ne supprimez pas l’appli avant de préserver la copie. Cela ne recrée pas des données déjà écrasées ou effacées et n’annule pas un retrait administratif.
- Dans le service worker original actualisé, une visite réseau réussie sans redirection à la racine ou à index.html remplace aussi la copie index.html hors ligne, y compris avec paramètres ou installation dans un sous-chemin. Hors ligne, la navigation du jeu privilégie cette copie ; d’autres documents en cache peuvent ignorer les paramètres. Une réponse échouée ou redirigée ne remplace pas la bonne copie ; scripts et images manquants ne reçoivent pas le HTML du jeu. Une visite en ligne de l’original actualisé est nécessaire avant d’obtenir ce nouveau repli hors ligne. La dernière page mise en cache ne garantit ni un save cloud récent ni des services en ligne hors connexion.
- Le panneau Comptes des administrateurs de l’original ajoute Retirer à côté de Donner, avec confirmation. Il peut soustraire pièces, tickets simples et tickets ×10 d’une sauvegarde cloud existante. Les saisies et soldes actuels sont arrondis à l’entier inférieur et normalisés entre 0 et 1 000 000 000 ; le débit est limité à ce solde. Retirer 120 pièces sur 100 laisse 0. La transaction inscrit le débit administratif, augmente la révision et actualise l’horodatage serveur. Ce n’est ni un achat en boutique, ni un code public, ni un nouveau tarif.
- Retirer un Pokémon normal retire les possessions normale et chromatique ; l’option chromatique seule conserve le normal. La sauvegarde mémorise une date de révocation par forme. Chargement et fusion suppriment les possessions acquises à cette date ou avant ; la fusion garde la date de révocation la plus récente des deux copies. Le partenaire supprimé est remplacé par le Pokémon de départ possédé, sinon la première espèce possédée ; son apparence chromatique indisponible est désactivée. Une acquisition réellement postérieure peut rester si l’autre copie ne contient plus l’ancienne possession ; voir la limite suivante.
- Le panneau original annonce qu’un Pokémon obtenu de nouveau peut rester. L’exécution du code confirme une condition plus étroite : DB.merge choisit d’abord la possession la plus ancienne, puis applique la révocation. Si un appareil ou une copie conserve l’ancien enregistrement, la fusion peut supprimer même une capture ultérieure légitime. N’importez pas cette ancienne copie à répétition pour restaurer le Pokémon retiré. Conservez une copie de l’état actuel, terminez la synchronisation et vérifiez le compte ; si la nouvelle capture disparaît encore, signalez cette séquence au support du jeu original. Le Wiki documente le comportement reproduit dans le code ; il n’a modifié ni serveur ni sauvegarde.
- Après un ajustement administratif, saisissez dans les planificateurs de gacha ou d’améliorations le solde réellement affiché après synchronisation. Mettez manuellement le suivi de collection à jour pour les possessions normales ou chromatiques retirées. Les outils du Wiki ne lisent ni ne modifient votre compte de jeu. Configurations, partage, import/export JSON et calculs conservent leur format ; restaurer une configuration du Wiki n’annule pas un retrait du compte. Prix, probabilités, statistiques de combat et formules d’amélioration des capacités restent identiques.
Origine des informations de chaîne dans l’original
L’original lit désormais la branche live de JPTER78/pokesurvivor-live : live.json fournit le badge de direct, video.json la bannière de dernière vidéo normale et aviso.json une annonce choisie séparément. Le workflow producteur a quitté le dépôt du jeu et existe dans le dépôt de données. Un ancien client en cache ou le jeu intégré distinct peut donc afficher d’autres informations. Cette Wiki conserve ses liens YouTube et Discord ; elle ne déplace ni n’exécute ces workflows et ne modifie pas le jeu intégré.
Pourquoi le badge ou l’annonce peut différer
Le client demande ces données sans cache environ toutes les cinq minutes lorsque la page est visible, avec au moins 295 secondes entre requêtes ; revenir à la page peut lancer une vérification. Le badge exige live=true, un ID de 11 caractères et heure actuelle moins at inférieure à 90 minutes. Un échec conserve l’état précédent et ne prouve pas la fin d’un direct. La bannière accepte un ID valide et limite le titre à 120 caractères. L’annonce vérifie à la lecture la fenêtre depuis desde inclus jusqu’à hasta exclu, puis examine menu, superpositions et saisie toutes les deux secondes et mémorise l’ID dans ce navigateur. Bannière et annonce peuvent donc viser volontairement deux vidéos ; délais de lecture et échecs peuvent retarder l’affichage.
Actualisation des données et sens des anciennes dates
Le producteur public séparé est planifié toutes les cinq minutes, avec des retards GitHub possibles. Il lit les cinq premières cartes de Streams, réessaie une liste manquante jusqu’à trois fois avec cinq secondes d’attente et conserve les données si la page ou les badges ne sont pas reconnus. Il écrit si live/ID change, ou après 30 minutes d’un direct continu ; un état false inchangé peut donc garder un ancien at. La vidéo normale est choisie parmi les sept premières cartes de Videos, sans premières à venir ni directs ; seuls les changements d’ID ou de titre entraînent une écriture, avec titre limité à 120 caractères. Une ancienne date inchangée ne prouve pas l’arrêt de l’actualisation. aviso.json est géré manuellement à part. Le mode test ne publie pas de changement live/video. Ce sont les règles source de l’auteur, pas une garantie de direct actuel.
Compatibilité des sauvegardes et versions des outils
Le suivi ajoute des entrées de compatibilité de signature en conservant les anciennes et la même signature d’écriture. Les règles de récupération et de retrait administratif expliquées ici restent applicables à l’original ; effacer le stockage ou modifier une signature n’est pas une méthode de récupération. Le changement interne de liste d’administrateurs n’accorde aucun accès aux comptes via la Wiki. La comparaison exécutée conserve 966 Pokémon, 103 capacités, 97 évolutions, niveaux, apprentissage/départs légaux et les 13 outils. Catalogue d567c6da, exécution/envoi 5c97df2e et modèles saison/calendrier restent distincts ; partages et imports JSON gardent leurs formats.
Pourquoi une mise à jour pouvait faire reculer la progression
Le changelog original décrit un ancien client en cache ou un vieil onglet ne reconnaissant pas la copie récente du navigateur, puis reprenant une sauvegarde cloud plus ancienne. La source 23c0d653 met désormais la copie illisible portant une signature à l’écart pour ce compte avant de remplacer le cache de travail. La copie dont le champ updated est le plus récent est prioritaire. Une copie signée non reconnue provenant d’un autre onglet est également conservée et l’identifiant local de l’appareil est renouvelé. Ce mécanisme n’accepte pas un JSON non signé comme cache cloud valide.
Ce qui est récupéré et les premières étapes
Après la mise à jour, une copie mise à l’écart que le client peut valider est fusionnée avec les sauvegardes lisibles du navigateur et du cloud. Sa présence désactive le raccourci de rechargement de deux minutes : une lecture cloud est tentée. Si le serveur est indisponible, une copie conservée lisible peut s’ouvrir avec synchronisation hors ligne en attente. Elle n’est effacée qu’après l’écriture réussie du cache fusionné. Une copie toujours illisible expire si son updated remonte à plus de 40 jours ; ce n’est pas une sauvegarde garantie 40 jours après sa mise à l’écart. Une copie lisible reste récupérable même plus ancienne. Les marqueurs d’import par extension empêchent cette restauration ; l’échéance de migration du 20 novembre UTC reste distincte. Préservez/exportez d’abord tout save accessible, fermez les anciens onglets, ouvrez l’original actualisé en ligne avec le même profil et compte, puis vérifiez collection, solde et synchronisation. Ne videz pas les données du site et ne supprimez pas l’appli avant de préserver la copie. Cela ne recrée pas des données déjà écrasées ou effacées et n’annule pas un retrait administratif.
Les règles de rechargement rapide ci-dessous ne s’appliquent que sans restauration d’une copie conservée lisible. Avant un rechargement de version, l’original attend au plus 6 secondes la synchronisation en attente et n’inscrit un marqueur propre à l’onglet que si la sauvegarde est déjà OK. Au démarrage suivant, un cache cloud valide avec révision positive peut éviter la lecture initiale du serveur uniquement si ce marqueur date de moins de 2 minutes et qu’aucun marqueur de récupération d’extension n’est présent. Il est consommé une fois. Sinon, la fusion habituelle serveur/cache reste utilisée. Cela réduit les lectures sans garantir les dernières données d’un autre appareil. Gardez navigateur/profil, vérifiez l’état réel et reconnectez le même compte original en cas de problème. Ne videz ni ne modifiez manuellement le stockage pour forcer une récupération.
Appli installée : la page hors ligne suit la dernière visite réussie
Dans le service worker original actualisé, une visite réseau réussie sans redirection à la racine ou à index.html remplace aussi la copie index.html hors ligne, y compris avec paramètres ou installation dans un sous-chemin. Hors ligne, la navigation du jeu privilégie cette copie ; d’autres documents en cache peuvent ignorer les paramètres. Une réponse échouée ou redirigée ne remplace pas la bonne copie ; scripts et images manquants ne reçoivent pas le HTML du jeu. Une visite en ligne de l’original actualisé est nécessaire avant d’obtenir ce nouveau repli hors ligne. La dernière page mise en cache ne garantit ni un save cloud récent ni des services en ligne hors connexion.
Stockage de récupération et suppression du compte
L’original conserve la copie dans ce profil de navigateur, séparément pour chaque compte. Son code de suppression du compte efface désormais aussi la copie locale correspondante. Il s’agit du comportement source, pas d’une demande d’effacement. La Wiki n’accède pas à cette copie et ne modifie ni compte ni données du joueur ; le jeu intégré reste une version distincte.
Retraits administratifs : soldes jamais négatifs
Le panneau Comptes des administrateurs de l’original ajoute Retirer à côté de Donner, avec confirmation. Il peut soustraire pièces, tickets simples et tickets ×10 d’une sauvegarde cloud existante. Les saisies et soldes actuels sont arrondis à l’entier inférieur et normalisés entre 0 et 1 000 000 000 ; le débit est limité à ce solde. Retirer 120 pièces sur 100 laisse 0. La transaction inscrit le débit administratif, augmente la révision et actualise l’horodatage serveur. Ce n’est ni un achat en boutique, ni un code public, ni un nouveau tarif.
Pokémon retirés, formes chromatiques et partenaire
Retirer un Pokémon normal retire les possessions normale et chromatique ; l’option chromatique seule conserve le normal. La sauvegarde mémorise une date de révocation par forme. Chargement et fusion suppriment les possessions acquises à cette date ou avant ; la fusion garde la date de révocation la plus récente des deux copies. Le partenaire supprimé est remplacé par le Pokémon de départ possédé, sinon la première espèce possédée ; son apparence chromatique indisponible est désactivée. Une acquisition réellement postérieure peut rester si l’autre copie ne contient plus l’ancienne possession ; voir la limite suivante.
Limite des anciennes copies dans la source 90cdd941
Le panneau original annonce qu’un Pokémon obtenu de nouveau peut rester. L’exécution du code confirme une condition plus étroite : DB.merge choisit d’abord la possession la plus ancienne, puis applique la révocation. Si un appareil ou une copie conserve l’ancien enregistrement, la fusion peut supprimer même une capture ultérieure légitime. N’importez pas cette ancienne copie à répétition pour restaurer le Pokémon retiré. Conservez une copie de l’état actuel, terminez la synchronisation et vérifiez le compte ; si la nouvelle capture disparaît encore, signalez cette séquence au support du jeu original. Le Wiki documente le comportement reproduit dans le code ; il n’a modifié ni serveur ni sauvegarde.
Utilisez les soldes et possessions actuels
Après un ajustement administratif, saisissez dans les planificateurs de gacha ou d’améliorations le solde réellement affiché après synchronisation. Mettez manuellement le suivi de collection à jour pour les possessions normales ou chromatiques retirées. Les outils du Wiki ne lisent ni ne modifient votre compte de jeu. Configurations, partage, import/export JSON et calculs conservent leur format ; restaurer une configuration du Wiki n’annule pas un retrait du compte. Prix, probabilités, statistiques de combat et formules d’amélioration des capacités restent identiques.
Source originale c121040f et jeu intégré
Vérification du 3 novembre : l’original public 064519c8ee correspond à c121040f, avec les sept commits après d2bf542d. Il conserve 966 Pokémon, 103 capacités, 97 évolutions, niveaux, apprentissage légal et exceptions initiales. Catalogue d567c6da ; combat/récompenses f7fbcfc4 ; calendrier d667c216 ; calculs d’exécution/envoi 5c97df2e. Salles, cache et cadeaux sont versionnés séparément. Les 13 outils et modèles historiques de partage/import restent disponibles. L’intégration observée reste 3667bcad81 avec adaptation sélective f7, Community 395a0e47/559ca0a7c8 ; ces modifications du client original ne leur sont pas attribuées.
Pages liées
- Origine des informations de chaîne dans l’original
- Ce qui est récupéré et les premières étapes
- Appli installée : la page hors ligne suit la dernière visite réussie
- Retraits administratifs : soldes jamais négatifs
- Limite des anciennes copies dans la source 90cdd941
- Utilisez les soldes et possessions actuels
- Source originale 90cdd941 et jeu intégré
Mises à jour voisines
Données du jeu et sources
Les fichiers du jeu liés indiquent l’origine des valeurs, coûts et règles. Les mises à jour peuvent les modifier.
Version des données: d567c6da
- https://github.com/JPTER78/pokesurvivor/blob/c121040ff0278383e4ae67bc24f17e4cfd141a24/js/app.min.js
- https://github.com/JPTER78/pokesurvivor/commit/ad6c025958a2feb39345874673da845c57546681
- https://github.com/JPTER78/pokesurvivor/commit/c121040ff0278383e4ae67bc24f17e4cfd141a24
- https://github.com/JPTER78/pokesurvivor-live/blob/639adaf9dc019cdcfe54b16c21a5fcfe33b9e2fa/README.md
- https://github.com/JPTER78/pokesurvivor-live/blob/639adaf9dc019cdcfe54b16c21a5fcfe33b9e2fa/.github/workflows/live.yml
- https://github.com/JPTER78/pokesurvivor/blob/23c0d653dfd215690d4a617d6e0593231b9dccd3/js/app.min.js
- https://github.com/JPTER78/pokesurvivor/blob/23c0d653dfd215690d4a617d6e0593231b9dccd3/sw.js
- https://github.com/JPTER78/pokesurvivor/blob/23c0d653dfd215690d4a617d6e0593231b9dccd3/en/news/index.html
- https://github.com/JPTER78/pokesurvivor/commit/23c0d653dfd215690d4a617d6e0593231b9dccd3
- https://github.com/JPTER78/pokesurvivor/blob/90cdd941da04793e3023b4a28aff552819c70f21/js/app.min.js
- https://github.com/JPTER78/pokesurvivor/commit/90cdd941da04793e3023b4a28aff552819c70f21
- https://github.com/JPTER78/pokesurvivor/blob/b742e43772e37d077549bf2fad3d615d60f42961/js/app.min.js
- https://github.com/JPTER78/pokesurvivor/blob/b742e43772e37d077549bf2fad3d615d60f42961/css/style.css
- https://github.com/JPTER78/pokesurvivor/blob/b742e43772e37d077549bf2fad3d615d60f42961/en/news/index.html
- https://github.com/JPTER78/pokesurvivor/commit/e5997d563fd271168d4c801fbe46274622f92c13
- https://github.com/JPTER78/pokesurvivor/commit/b742e43772e37d077549bf2fad3d615d60f42961