Spielupdate · Artikel aktualisiert
Änderungen im Überblick
- Seit dem Originalupdate vom 4. November sendet ein angemeldetes Cloudkonto seine Ziehung an den Originaldienst. Bei fehlender Verbindung oder gescheiterter Anfrage meldet der Client einen Fehler und führt keine lokale Ersatzziehung aus. Gäste verwenden weiterhin den lokalen Algorithmus. Laut offizieller Meldung bleiben normales Spielen und Shop unverändert; die Verbindungspflicht betrifft Kontoziehungen, nicht jede Offlineaktion.
- Der Originalclient behält die Firebase-Anmeldung, liest und schreibt Cloudstände jedoch über den Originaldienst statt direkte Firestore-/Realtime-Database-Clients zu laden. Das beschreibt den öffentlichen Clienttransport, nicht unbekannte interne Datenspeicherung. Eine Antwort ohne gefundenen Spielstand unterscheidet sich von einer fehlgeschlagenen Anfrage; ein Fehler bedeutet weder leeres Konto noch erfolgreiche Synchronisierung. Lokale Sicherungen, geschützte signierte Kopien und Schutz zwischen Tabs bleiben relevant.
- In diesem Originalstand verwendet die Raumsignalisierung immer WebSocket; der frühere lokale RTDB-Schalter bietet keinen unterstützten Ausweichweg mehr. WebRTC/TURN und die Warteschlange des Hosts sind getrennte Ebenen mit unverändertem Kampfverhalten. Freunde und Einladungen werden über den Originaldienst statt direkter Datenbankabonnements aktualisiert. Abfragen erfolgen meist etwa alle 9,6–14,4 Sekunden im Menü und 36–54 Sekunden im Spiel; Netzwerkverzögerungen sind möglich. Versteckte Seiten überspringen regelmäßige Anfragen und aktualisieren beim erneuten Anzeigen.
- Der Originalclient verwendet seinen Ranglistendienst jetzt durchgehend; frühere Hinweise auf Firestore als Standard und einen optionalen Dienst beschreiben ältere Stände. Der alle 60 Sekunden Spielzeit aufgerufene Heartbeat benötigt weiterhin gültige signierte Laufdaten. Deren Beschaffung behält bis zu acht Versuche, drei Sekunden Pause, 15 Sekunden Anfragetimeout und insgesamt 80 Sekunden Budget; eine abgelehnte Authentifizierung beendet Wiederholungen. Das beweist weder die interne Umsetzung noch die Verfügbarkeit des privaten Dienstes.
- Geschenke und Rücknahmen der Originaladministration werden über den Originaldienst gelesen/geschrieben, mit bis zu drei Versuchen bei Revisionskonflikten. Nichtnegative Guthaben, Sammlungsrücknahmen und Partnerersatz bleiben erhalten; dieses Wiki vergibt keine Administratorrechte und ändert keine Guthaben. Die geschützte Verwaltungsoberfläche ergänzt eine vom Server gelieferte Verdachtsliste (bis zu 500 nach Wirtschaftswerten; Meldungen können weitere Einträge ergänzen), Gründe/Meldungen und Wirtschaftswerte sowie Verwerfen und ausdrücklich bestätigtes Sperren. Eine Markierung beweist keinen Betrug und für sich keine automatische Sperre.
- Der öffentliche Client ergänzt beim Start eine Wartungsprüfung mit vier Sekunden Anfragetimeout. Modus „servidor“, eine nicht verfügbare Antwort oder kein gültiger Modus erlauben den normalen Start; eine andere Zeichenfolge zeigt den Originalhinweis zum Serverumzug. Der bedingte Bildschirm beweist keine derzeit aktive Wartung. Der Hinweis bittet um spätere Rückkehr; bewahre den Browserspielstand auf, statt ihn wegen dieser Anzeige zu löschen.
- Am 5. November geprüft: Das konfigurierte Repository JPTER78/pokesurvivor, HEAD und zuvor lesbare Commitlinks liefern 404. Ob es privat, verschoben oder entfernt wurde, ist damit nicht geklärt; fehlende Updates sind dadurch nicht bewiesen. Auch die Originaleinstellungen/Rechtshinweise entfernen GitHub-Schaltflächen. Historische Quellen behalten ihre Datierung; diese Prüfung nutzt die offizielle Meldung vom 4. November und den per SHA-256 eingefrorenen öffentlichen Client-/Versionsstand eae98df1a1. Das ist eine öffentliche Versionskennung, kein erfundener Git-Commit. Der vollständige Bereich seit d2bf542d bleibt unzugänglich; letzter geprüfter Gitstand ist c121040f.
Kontoziehungen benötigen eine Verbindung
Seit dem Originalupdate vom 4. November sendet ein angemeldetes Cloudkonto seine Ziehung an den Originaldienst. Bei fehlender Verbindung oder gescheiterter Anfrage meldet der Client einen Fehler und führt keine lokale Ersatzziehung aus. Gäste verwenden weiterhin den lokalen Algorithmus. Laut offizieller Meldung bleiben normales Spielen und Shop unverändert; die Verbindungspflicht betrifft Kontoziehungen, nicht jede Offlineaktion.
Prüfe zuerst das offene Banner und genügend Tickets. Während der Verarbeitung sperrt der Client weitere Ziehungen, wartet auf einen laufenden Speichervorgang und verwendet bei Wiederholungen dieselbe Vorgangs-ID. Bei einem Revisionskonflikt wird der empfangene Spielstand zusammengeführt und mit neuer Revision erneut gesendet, höchstens vier Schleifendurchläufe; ein Transportfehler erhält nur einen ersten Wiederholungsversuch, keine vier garantierten Netzwerkversuche. Geschlossenes Banner, fehlende Tickets, offline und allgemeiner Fehler sind getrennte Ergebnisse. Eine erfolgreiche Antwort setzt Münzen, beide Ticketsalden, Journal, Sammlung, Shinys, Banner-Pity und Gesamtziehungen vor der Animation.
Verbinde nach einem Timeout dasselbe Konto erneut und lasse es synchronisieren; prüfe vor einer weiteren Ziehung die tatsächlichen Tickets, Sammlung und Pity. Eine verlorene Antwort beweist nicht, dass der Server nichts verarbeitet hat, und garantiert keine Erstattung. Lösche keinen Browserspeicher und bearbeite keine signierten Kopien. Die veröffentlichten lokalen Formeln für Chancen, Pity, 10er-/100er-Kosten, Duplikate und Shinys sind in diesem Clientstand unverändert. Wiki-Rechner planen mit den zuletzt bestätigten Kontowerten; sie führen keine echten Serverziehungen aus und können sie weder wiederherstellen noch bestätigen.
Cloudkonflikte und bestätigte Guthaben
Der Originalclient behält die Firebase-Anmeldung, liest und schreibt Cloudstände jedoch über den Originaldienst statt direkte Firestore-/Realtime-Database-Clients zu laden. Das beschreibt den öffentlichen Clienttransport, nicht unbekannte interne Datenspeicherung. Eine Antwort ohne gefundenen Spielstand unterscheidet sich von einer fehlgeschlagenen Anfrage; ein Fehler bedeutet weder leeres Konto noch erfolgreiche Synchronisierung. Lokale Sicherungen, geschützte signierte Kopien und Schutz zwischen Tabs bleiben relevant.
Eine angenommene Speicherung kann Münzen, beide Tickets, Journal, Rücknahmen, dauerhafte Upgrades, Tasche und TMs durch Serverwerte korrigieren. Bei Konflikten führt der Client die empfangene Kopie zusammen und versucht eine höhere Revision. Eine Ratenbegrenzung mit Warteangabe lässt die Speicherung ausstehend und wartet die angegebenen Sekunden (standardmäßig 20) plus eine halbe Sekunde. Bei Ablehnung können neue Änderungen nur in diesem Browser liegen. Behalte dessen Daten und warte vor Gerätewechsel oder Speicherlöschung auf eine tatsächlich angenommene Synchronisierung.
Anfragen benötigen einen angemeldeten Nutzer. Nach einer 401-Antwort erneuert der Client das Anmeldetoken einmal; ein erneuter Authentifizierungsfehler ist keine erfolgreiche Speicherung. Üblich sind 12 Sekunden Timeout (15 bei Ziehungen); Netzwerk-, Serverfehler und unlesbare Antworten gelten als nicht verfügbar. Verbinde dich erneut und prüfe den Synchronisierungsstatus; das Wiki repariert keine Zugangsdaten und leitet aus einer Ladeanzeige kein bestätigtes Guthaben ab.
Räume, Freunde und verzögerter Status
In diesem Originalstand verwendet die Raumsignalisierung immer WebSocket; der frühere lokale RTDB-Schalter bietet keinen unterstützten Ausweichweg mehr. WebRTC/TURN und die Warteschlange des Hosts sind getrennte Ebenen mit unverändertem Kampfverhalten. Freunde und Einladungen werden über den Originaldienst statt direkter Datenbankabonnements aktualisiert. Abfragen erfolgen meist etwa alle 9,6–14,4 Sekunden im Menü und 36–54 Sekunden im Spiel; Netzwerkverzögerungen sind möglich. Versteckte Seiten überspringen regelmäßige Anfragen und aktualisieren beim erneuten Anzeigen.
Empfangene Freunde starten mit offline/nicht spielend und leerem Raum. Dieses Symbol beweist in dieser Version nicht zuverlässig, dass ein Freund nicht beitreten kann: versuche eine Einladung oder einen bekannten Raum und warte auf die Aktualisierung. Einladungen verfallen nach drei Minuten; dieselbe Einladung innerhalb von 20 Sekunden wird unterdrückt. Aktionen können die Liste ebenfalls aktualisieren. Profil/Nickname behalten sechs Stunden Abstand, 800 ms Entprellung und zehn Minuten Profilcache; bei einer Profilbegrenzung gelten die empfangenen Sekunden (standardmäßig fünf) plus 0,2 Sekunden. Das sind Clientzeiten, keine Zustellgarantien.
Ranglisten verwenden jetzt den Originaldienst
Der Originalclient verwendet seinen Ranglistendienst jetzt durchgehend; frühere Hinweise auf Firestore als Standard und einen optionalen Dienst beschreiben ältere Stände. Der alle 60 Sekunden Spielzeit aufgerufene Heartbeat benötigt weiterhin gültige signierte Laufdaten. Deren Beschaffung behält bis zu acht Versuche, drei Sekunden Pause, 15 Sekunden Anfragetimeout und insgesamt 80 Sekunden Budget; eine abgelehnte Authentifizierung beendet Wiederholungen. Das beweist weder die interne Umsetzung noch die Verfügbarkeit des privaten Dienstes.
Unverändert bleiben die Uploadgrenzen von 120 Sekunden insgesamt und 600 pro Pokémon, historische Schadenswerte, der Freunde-Top-50-Bereich, 8/6/2 Stunden Cache und das kumulierte Schadenslimit aus 5c97df2e. Die Laufzeitleiste behält deshalb Berechnungen und Wiederherstellung alter Freigaben. Ein Transportwechsel erhöht keinen Kampfschaden und verschiebt keine Ereignisse; aktualisiere die richtige Liste und prüfe die Uploadbedingungen, bevor du verzögerte Anzeigen als verlorenen Fortschritt deutest.
Geschenke, Moderation und Kontolöschung
Geschenke und Rücknahmen der Originaladministration werden über den Originaldienst gelesen/geschrieben, mit bis zu drei Versuchen bei Revisionskonflikten. Nichtnegative Guthaben, Sammlungsrücknahmen und Partnerersatz bleiben erhalten; dieses Wiki vergibt keine Administratorrechte und ändert keine Guthaben. Die geschützte Verwaltungsoberfläche ergänzt eine vom Server gelieferte Verdachtsliste (bis zu 500 nach Wirtschaftswerten; Meldungen können weitere Einträge ergänzen), Gründe/Meldungen und Wirtschaftswerte sowie Verwerfen und ausdrücklich bestätigtes Sperren. Eine Markierung beweist keinen Betrug und für sich keine automatische Sperre.
Die Löschung des Originalkontos verlangt weiterhin erneute Authentifizierung und eine Anfrage an den Originaldienst, danach folgen Sozial-/Ranglistenbereinigung und Firebase-Nutzerlöschung. Dieser Client lässt die Fortsetzung sowohl nach 403 als auch nach 200 zu; das beweist keine vollständige Löschung aller Backenddaten. Nutze die Originalkontoverwaltung und prüfe deren tatsächliches Ergebnis beim Dienst. Werkzeug-JSON, lokale Planungsdaten und das unabhängig eingebettete Spiel sind getrennt; dieses Wiki erhält dadurch keine Kontolöschrechte.
Originaler Wartungsbildschirm und erneuter Versuch
Der öffentliche Client ergänzt beim Start eine Wartungsprüfung mit vier Sekunden Anfragetimeout. Modus „servidor“, eine nicht verfügbare Antwort oder kein gültiger Modus erlauben den normalen Start; eine andere Zeichenfolge zeigt den Originalhinweis zum Serverumzug. Der bedingte Bildschirm beweist keine derzeit aktive Wartung. Der Hinweis bittet um spätere Rückkehr; bewahre den Browserspielstand auf, statt ihn wegen dieser Anzeige zu löschen.
Auf diesem Bildschirm lädt „Try again“ die Seite neu. Eine automatische Prüfung wird alle 60–75 Sekunden geplant: Sie lädt neu, wenn der Modus den Start erlaubt (auch bei fehlgeschlagener Modusabfrage) oder eine neu lesbare Version von der anfangs lesbaren Version abweicht. Sonst wird erneut geprüft. Der Service Worker ist unverändert; eine zwischengespeicherte Offlineoberfläche ermöglicht keine Kontoziehungen oder Cloudsync ohne Internet. Die eingebettete unabhängige Version hat diese Startänderung nicht erhalten.
Öffentlicher Client und nicht erreichbare Git-Historie
Am 5. November geprüft: Das konfigurierte Repository JPTER78/pokesurvivor, HEAD und zuvor lesbare Commitlinks liefern 404. Ob es privat, verschoben oder entfernt wurde, ist damit nicht geklärt; fehlende Updates sind dadurch nicht bewiesen. Auch die Originaleinstellungen/Rechtshinweise entfernen GitHub-Schaltflächen. Historische Quellen behalten ihre Datierung; diese Prüfung nutzt die offizielle Meldung vom 4. November und den per SHA-256 eingefrorenen öffentlichen Client-/Versionsstand eae98df1a1. Das ist eine öffentliche Versionskennung, kein erfundener Git-Commit. Der vollständige Bereich seit d2bf542d bleibt unzugänglich; letzter geprüfter Gitstand ist c121040f.
Aktueller Originalstand und Werkzeugmodell
Öffentlicher Originalclient eae98df1a1 (Versionszeit 4. November, 23:19:53 UTC), am 5. geprüft. Der Vergleich vollständiger normalisierter Clientmodule findet 101 unveränderte und 13 geänderte/neue Module. Ausgeführte Katalogvergleiche bestätigen weiterhin 966 Pokémon, 103 Attacken, 97 Entwicklungen, 4.830 Statistikprüfungen und 412 Attacken-Levelübergänge; Ziehungs-, Kampf-, Shop- und Fortschrittsformeln sind unverändert. Alle dreizehn Werkzeuge behalten Berechnungen, Teilen und JSON-Wiederherstellung; plane mit bestätigten Guthaben. Katalog d567c6da, Ausführung/Upload 5c97df2e, Saisonregeln f7fbcfc4 und Kalender d667c216 bleiben getrennt versioniert.
Das eingebettete Spiel bleibt die unabhängige survivorpoke.com/play/-Version 3667bcad81 mit ausgewählten f7-Saisonänderungen; Community-Berechnungen behalten ihr eigenes festes Modell. Dieses Wiki-Update hat den neuen Kontodienst und Onlineziehungen nicht in das eingebettete Spiel übertragen. Die Versionen sind nicht identisch.
Verwandte Seiten
- Kontoziehungen benötigen eine Verbindung
- Cloudkonflikte und bestätigte Guthaben
- Räume, Freunde und verzögerter Status
- Ranglisten verwenden jetzt den Originaldienst
- Geschenke, Moderation und Kontolöschung
- Originaler Wartungsbildschirm und erneuter Versuch
- Öffentlicher Client und nicht erreichbare Git-Historie
- Aktueller Originalstand und Werkzeugmodell
Vorherige und nächste Updates
Spieldaten und Quellen
Die verlinkten Spieldateien zeigen die Herkunft der Werte, Kosten und Regeln. Spielupdates können sie ändern.
Datenversion: d567c6da
- https://pokesurvivor.com/en/news/
- https://pokesurvivor.com/version.json
- https://pokesurvivor.com/js/app.min.js?v=eae98df1a1
- 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