Zuverlässigkeit

Travian-Bot-Zuverlässigkeit: Wiederherstellung und Kontrolle

Vangrd speichert Aufgabenzeiten, stellt Sitzungen wieder her, wiederholt Browserfehler und meldet blockierte Arbeit. Sieh, wie die Wiederherstellung funktioniert.

Zuletzt geprüft: 12. Okt. 2026

Was bei einer Unterbrechung passiert

Gespeicherte Arbeit nach einem Neustart

Vangrd speichert Einstellungen, Aufgabendefinitionen und Aufgabenzeiten. Nach einem Neustart stellt der Planer die Zeiten wieder her und prüft ausführbare Aufgaben. Eigene Abläufe speichern ihren Stand an Aktions- und Verzögerungsgrenzen.

Ablaufauslöser und gespeicherter Fortschritt

Browser- und Sitzungswiederherstellung

Zustandsprüfungen erkennen ausgefallene oder nicht reagierende Browser. Die Wiederherstellung nutzt steigende Wiederholungsabstände und Grenzen für wiederholte Fehler. Vangrd speichert Cookies und lokalen Speicher bei kontrollierten Browserneustarts, um Sitzungen wiederherzustellen.

Agenten- und Aufgabenstatus prüfen

Browser bleibt bei Aktualisierungen verfügbar

Der Browserhost kann Chromium getrennt vom Automatisierungsdienst ausführen. In diesem Modus löst eine Dienstaktualisierung die Browserverbindung und stellt sie danach wieder her. Der Browserhost selbst muss weiterlaufen.

So funktioniert der Cloudbetrieb

Fortschritt, wenn ein Dorf wartet

Unabhängige Dorfaufgabenketten begrenzen gewöhnliche Fehler und Ressourcenwartezeiten. Andere Ketten können weiterlaufen. Zeitgrenzen des Planers und eine Überwachung erkennen auch blockierte Arbeit. Ein Browserausfall betrifft weiterhin Aufgaben, die diesen Browser teilen.

Baupläne und Warteschlangenprüfungen

Aktuelle Ressourcen vor Entscheidungen

Aufgaben prüfen die Aktualität der Ressourcendaten und aktualisieren veraltete Dorfzustände. Ressourcenprognosen nutzen den zuletzt erfassten Ausgangsstand. Versandupdates aus Spielantworten helfen Versorgungsaufgaben, unterwegs befindliche Händler und Ressourcen zu berücksichtigen.

Versorgungsverknüpfungen und Ressourcenreserven

Zeitgesteuerte Aktionen haben eigene Prüfungen

Angriffspläne speichern ihren Zustand und Sendeversuche. Eine eigene Zeitplanung bearbeitet Angriffs- und Verteidigungsfristen. Nach einem Neustart wird fällige Arbeit erneut geprüft. Verpasste Zeiten und veraltete Vorbereitung können einen Plan scheitern lassen, statt ihn verspätet zu senden.

Angriffssendungen und Ankunftszeiten einstellen

Blockierte Arbeit hat einen Grund

Die Statusseite zeigt Aufgaben, Ausführungen und Probleme. Ressourcenmangel und Warteschlangenlimits erscheinen als Wartezustände. Fehlgeschlagene Aufgaben nutzen Wiederholungsabstände. Abgelehnte Zugangsdaten müssen korrigiert werden, bevor der Zugriff fortgesetzt wird.

Wartezustände und Probleme lesen

Spieländerungen hinterlassen Belege

Seitenprüfungen erkennen unterstützte Oberflächenlayouts. Erkannte Fehler können Screenshots und einen Aktionsverlauf zur Diagnose erfassen. Diese Aufzeichnungen helfen, Kompatibilitätsprobleme nachzuvollziehen und Korrekturen vorzubereiten.

Kompatibilitätskorrekturen im Änderungsverlauf lesen

So prüfen wir diese Mechanismen

Unsere Regressionstests prüfen Übernahme nach Neustarts, Wiederholungsabstände, blockierte Planeraufgaben, Fehlerbegrenzung pro Dorf und Fortsetzung von Abläufen. Sie nutzen kontrollierte Fehler und nachgebildete Spielseiten. Sie prüfen das erwartete Verhalten unter diesen Bedingungen.

Diese Wiederherstellungsmechanismen halten ausführbare Arbeit in Gang und machen Unterbrechungen sichtbar. Spielaktionen brauchen eine gültige Sitzung und funktionierende Verbindung.

Eine aufgezeichnete Stichprobe zur Angriffszeit

Erfolgreiche Senderückmeldungen kamen in unserer Stichprobe im Median 374 ms nach der geplanten Zeit zurück. Sechzehn von 18 erfolgreichen Rückmeldungen kamen weniger als 1,000 ms nach der geplanten Zeit zurück.

Interne Messung: ein Konto, 19 Versuche, 18 abgeschlossene Aufgaben und ein Fehler vor der abschließenden Sendefunktion. Der Beobachtungszeitraum reicht vom 10. Oktober 2026 um 05:45 UTC bis zum 11. Oktober 2026 um 05:45 UTC, ohne den Endzeitpunkt.

So haben wir diese Stichprobe gemessen

Wir verknüpften gespeicherte Starts geplanter Sendeaufgaben mit ihren aufgezeichneten Ergebnissen. Das Timing misst, wann der Client eine Antwort mit Status HTTP 302 nach Lesen ihres Inhalts beobachtete, relativ zur geplanten Sendezeit. Es umfasst Netzwerk- und Antwortverarbeitung. Es misst weder Anfrageversand noch Spielannahme oder Truppenankunft.

Die Zeitstichprobe enthält die 18 erfolgreichen Rückmeldungen. Alle 19 beobachteten Versuche zählen zum Gesamtergebnis. Gespeicherte Daten belegen nicht jede geplante Absicht oder eine durchgängige Erfassung. Diese Stichprobe eines Kontos belegt keine flottenweite Zeitgenauigkeit oder Wiederherstellungsquote.

Wartungshistorie verfolgen

Datierte Produkthinweise beschreiben konkrete Korrekturen, darunter kritische Sendungen nach Neustarts, Ressourcensendungen und Bauvoraussetzungen. Jeder Hinweis hat einen dauerhaften Link.