Les tirages avec compte nécessitent le serveur original. Erreurs, conflits de sauvegarde, amis, salons et classements ; les règles invité et boutique restent disponibles.

Principaux changements

  • Depuis la mise à jour originale du 4 novembre, un compte connecté envoie son tirage au service original. Hors ligne ou en cas d'échec de la requête, le client affiche une erreur sans effectuer de tirage local de secours. L'invité conserve l'algorithme local. L'annonce officielle laisse le jeu courant et la boutique inchangés : cette exigence concerne les tirages avec compte, pas toutes les actions hors ligne.
  • Le client original conserve la connexion Firebase mais lit et écrit les sauvegardes via le service original, sans charger les clients directs Firestore/Realtime Database. Cela décrit le transport public, pas le stockage interne inconnu. Une réponse indiquant l'absence de sauvegarde se distingue d'une requête échouée ; un échec ne signifie ni compte vide ni synchronisation réussie. Sauvegardes locales, conservation des copies signées et protection entre onglets restent utiles.
  • Dans cet instantané original, la signalisation des salons utilise toujours WebSocket ; l'ancien choix local RTDB n'est plus une solution de secours. WebRTC/TURN et la file de l'hôte sont distincts et conservent leur comportement de combat. Amis et invitations passent par le service original plutôt que par des abonnements directs aux bases. Les consultations sont espacées d'environ 9,6–14,4 secondes dans les menus et 36–54 en jeu, avec retards réseau possibles ; une page masquée saute les demandes périodiques et actualise à son retour.
  • Le client original utilise désormais systématiquement son service de classement ; les indications précédentes sur Firestore par défaut et un service facultatif concernent d'anciens instantanés. Le signal périodique nécessite toujours des identifiants de partie signés valides et est appelé toutes les 60 secondes de jeu. Leur obtention conserve jusqu'à huit essais, des pauses de trois secondes, un délai de requête de 15 secondes et un budget total de 80 secondes ; un refus d'authentification arrête les essais. Cela ne prouve ni l'implémentation privée ni sa disponibilité.
  • Les cadeaux et retraits des administrateurs originaux passent par le service original, avec jusqu'à trois essais en cas de conflit. Économie non négative, retraits de collection et partenaire de remplacement sont conservés ; ce Wiki n'accorde aucun droit et ne modifie aucun solde. L'interface restreinte ajoute une liste de signalements du serveur (jusqu'à 500 selon les chiffres ; les rapports peuvent ajouter des entrées), motifs/rapports et chiffres économiques, avec classement sans suite et bannissement confirmé explicitement. Un signalement ne prouve pas une triche et ne démontre pas un bannissement automatique.
  • Le client public ajoute au démarrage un contrôle de maintenance avec un délai de quatre secondes. Le mode « servidor », une réponse indisponible ou sans mode valide autorisent le démarrage ; une autre chaîne affiche l'avis original de migration des serveurs. Cet écran conditionnel ne prouve pas une maintenance active maintenant. L'avis demande de revenir plus tard ; conservez la sauvegarde du navigateur au lieu de l'effacer à cause de cet écran.
  • Vérification du 5 novembre : le dépôt configuré JPTER78/pokesurvivor, HEAD et les liens auparavant lisibles renvoient 404. Cela ne précise pas s'il est privé, déplacé ou retiré et ne signifie pas absence de mise à jour. Les réglages/mentions du jeu original retirent aussi les boutons GitHub. Les citations historiques gardent leur date ; cette révision utilise l'annonce officielle du 4 novembre et l'instantané public client/version eae98df1a1 figé par SHA-256. Il s'agit d'un identifiant de version publique, pas d'un commit Git inventé. L'intervalle complet depuis d2bf542d reste inaccessible ; le dernier Git vérifié reste c121040f.

Les tirages avec compte nécessitent une connexion

Depuis la mise à jour originale du 4 novembre, un compte connecté envoie son tirage au service original. Hors ligne ou en cas d'échec de la requête, le client affiche une erreur sans effectuer de tirage local de secours. L'invité conserve l'algorithme local. L'annonce officielle laisse le jeu courant et la boutique inchangés : cette exigence concerne les tirages avec compte, pas toutes les actions hors ligne.

Vérifiez d'abord le portail ouvert et les tickets. Le client verrouille le tirage pendant son traitement, attend l'écriture en cours et réutilise le même identifiant d'opération lors des essais. Un conflit de révision fusionne la sauvegarde reçue puis réessaie avec la nouvelle révision, au plus quatre passages ; une panne de transport n'a qu'un premier nouvel essai, pas quatre essais réseau garantis. Portail fermé, tickets insuffisants, hors ligne et échec général sont distincts. La réponse réussie fixe pièces, deux soldes de tickets, registre, collection, chromatiques, pity et total des tirages avant l'animation.

Après un délai dépassé, reconnectez le même compte et laissez-le se synchroniser ; contrôlez tickets, collection et pity réels avant de recommencer. Une réponse perdue ne prouve pas que le serveur n'a rien traité et ne garantit aucun remboursement. N'effacez pas le stockage et ne modifiez pas les copies signées. Les formules locales publiées de probabilités, pity, coûts des séries de 10/100, doublons et chromatiques sont inchangées dans cet instantané. Les calculateurs Wiki servent à planifier avec les dernières valeurs confirmées ; ils n'exécutent, ne restaurent ni ne certifient un tirage réel.

Conflits de sauvegarde et soldes confirmés

Le client original conserve la connexion Firebase mais lit et écrit les sauvegardes via le service original, sans charger les clients directs Firestore/Realtime Database. Cela décrit le transport public, pas le stockage interne inconnu. Une réponse indiquant l'absence de sauvegarde se distingue d'une requête échouée ; un échec ne signifie ni compte vide ni synchronisation réussie. Sauvegardes locales, conservation des copies signées et protection entre onglets restent utiles.

Une sauvegarde acceptée peut corriger pièces, deux types de tickets, registre, retraits, améliorations permanentes, sac et CT selon le serveur. En conflit, le client fusionne la copie reçue et réessaie une révision supérieure. Une limitation avec délai laisse la sauvegarde en attente pendant les secondes indiquées (20 par défaut), plus une demi-seconde. Un refus peut laisser les changements récents uniquement dans ce navigateur. Conservez ses données et attendez une synchronisation acceptée avant de changer d'appareil ou d'effacer le stockage.

Les requêtes exigent un utilisateur connecté. Le client renouvelle une fois le jeton après un 401 ; un nouvel échec d'authentification n'est pas une sauvegarde réussie. Le délai usuel est de 12 secondes (15 pour les tirages) ; pannes réseau, erreurs serveur et réponses illisibles signifient indisponibilité. Reconnectez-vous et vérifiez l'état de synchronisation ; le Wiki ne répare pas les identifiants et ne déduit pas les soldes acceptés d'un indicateur de chargement.

Salons, amis et statut différé

Dans cet instantané original, la signalisation des salons utilise toujours WebSocket ; l'ancien choix local RTDB n'est plus une solution de secours. WebRTC/TURN et la file de l'hôte sont distincts et conservent leur comportement de combat. Amis et invitations passent par le service original plutôt que par des abonnements directs aux bases. Les consultations sont espacées d'environ 9,6–14,4 secondes dans les menus et 36–54 en jeu, avec retards réseau possibles ; une page masquée saute les demandes périodiques et actualise à son retour.

Les entrées d'amis reçues sont initialisées hors ligne, hors partie et sans salon. Ce badge ne prouve pas qu'un ami ne peut pas rejoindre dans cette version : essayez une invitation ou un salon connu, puis attendez l'actualisation. Une invitation expire après trois minutes ; la même invitation répétée avant 20 secondes est supprimée. Les actions peuvent aussi rafraîchir la liste. Profil et pseudo conservent l'intervalle de six heures, le délai de 800 ms et un cache de dix minutes ; une limitation attend les secondes reçues (cinq par défaut) plus 0,2 seconde. Ces délais du client ne garantissent pas la livraison.

Les classements passent par le service original

Le client original utilise désormais systématiquement son service de classement ; les indications précédentes sur Firestore par défaut et un service facultatif concernent d'anciens instantanés. Le signal périodique nécessite toujours des identifiants de partie signés valides et est appelé toutes les 60 secondes de jeu. Leur obtention conserve jusqu'à huit essais, des pauses de trois secondes, un délai de requête de 15 secondes et un budget total de 80 secondes ; un refus d'authentification arrête les essais. Cela ne prouve ni l'implémentation privée ni sa disponibilité.

Les seuils d'envoi de 120 secondes globales et 600 par Pokémon, la conservation du dommage historique, le top 50 des amis, les caches de 8/6/2 heures et le plafond cumulé 5c97df2e sont inchangés. La chronologie conserve donc ses calculs et la restauration des anciens liens. Le changement de transport n'augmente pas les dégâts de combat et ne modifie pas les dates d'événements ; vérifiez le bon classement et l'admissibilité avant de confondre retard et progression perdue.

Cadeaux, modération et suppression de compte

Les cadeaux et retraits des administrateurs originaux passent par le service original, avec jusqu'à trois essais en cas de conflit. Économie non négative, retraits de collection et partenaire de remplacement sont conservés ; ce Wiki n'accorde aucun droit et ne modifie aucun solde. L'interface restreinte ajoute une liste de signalements du serveur (jusqu'à 500 selon les chiffres ; les rapports peuvent ajouter des entrées), motifs/rapports et chiffres économiques, avec classement sans suite et bannissement confirmé explicitement. Un signalement ne prouve pas une triche et ne démontre pas un bannissement automatique.

La suppression du compte original exige toujours une réauthentification, puis une demande au service original avant le nettoyage social/classement et la suppression Firebase. Ce client permet de continuer après 403 comme après 200 ; cela ne prouve pas l'effacement de tous les enregistrements internes. Utilisez les commandes originales et vérifiez leur résultat auprès de ce service. JSON des outils, données de planification locales et jeu indépendant intégré restent distincts ; ce Wiki ne reçoit aucun pouvoir de suppression de compte.

Écran de maintenance original et nouveaux essais

Le client public ajoute au démarrage un contrôle de maintenance avec un délai de quatre secondes. Le mode « servidor », une réponse indisponible ou sans mode valide autorisent le démarrage ; une autre chaîne affiche l'avis original de migration des serveurs. Cet écran conditionnel ne prouve pas une maintenance active maintenant. L'avis demande de revenir plus tard ; conservez la sauvegarde du navigateur au lieu de l'effacer à cause de cet écran.

Sur cet écran, « Try again » recharge la page. Un contrôle automatique est programmé toutes les 60–75 secondes : il recharge si le mode autorise le démarrage (y compris si sa lecture échoue), ou si une nouvelle version lisible diffère de la version initiale lisible. Sinon, il programme un nouveau contrôle. Le service worker est inchangé dans cette comparaison ; une page hors ligne récente n'active ni tirages avec compte ni synchronisation cloud hors ligne. La version indépendante intégrée n'a pas reçu ce changement de démarrage.

Client public et historique Git inaccessible

Vérification du 5 novembre : le dépôt configuré JPTER78/pokesurvivor, HEAD et les liens auparavant lisibles renvoient 404. Cela ne précise pas s'il est privé, déplacé ou retiré et ne signifie pas absence de mise à jour. Les réglages/mentions du jeu original retirent aussi les boutons GitHub. Les citations historiques gardent leur date ; cette révision utilise l'annonce officielle du 4 novembre et l'instantané public client/version eae98df1a1 figé par SHA-256. Il s'agit d'un identifiant de version publique, pas d'un commit Git inventé. L'intervalle complet depuis d2bf542d reste inaccessible ; le dernier Git vérifié reste c121040f.

Instantané original actuel et modèle des outils

Client original public eae98df1a1 (horodatage du 4 novembre à 23:19:53 UTC), revu le 5. La comparaison des modules complets normalisés trouve 101 identiques et 13 modifiés/nouveaux. Le catalogue exécuté conserve 966 Pokémon, 103 capacités, 97 évolutions, 4 830 contrôles de statistiques et 412 transitions de niveau ; les formules de tirage, combat, boutique et progression sont inchangées. Les treize outils conservent calculs, partage et récupération JSON ; planifiez avec les soldes confirmés. Catalogue d567c6da, exécution/score 5c97df2e, règles saisonnières f7fbcfc4 et calendrier d667c216 restent versionnés séparément.

Le jeu intégré reste la version indépendante survivorpoke.com/play/ 3667bcad81 avec certains changements saisonniers f7 ; les calculs Community gardent leur modèle fixe. Cette mise à jour Wiki ne déploie pas le nouveau service de compte ni les tirages en ligne dans ce jeu intégré. Ces versions ne sont pas identiques.

Pages liées

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

Version des données →