Affidabilità

Affidabilità dei bot Travian: ripristino e controllo

Vangrd salva gli orari delle attività, ripristina le sessioni, riprova dopo guasti del browser e segnala le attività bloccate. Scopri come funziona il ripristino.

Ultima revisione: 12 ott 2026

Cosa succede quando le attività vengono interrotte

Attività salvate dopo un riavvio

Vangrd salva impostazioni, definizioni e orari delle attività. Dopo un riavvio, il pianificatore ripristina gli orari e controlla quali attività possono partire. I flussi personalizzati salvano la posizione ai confini delle azioni e dei ritardi.

Eventi di attivazione dei flussi e avanzamento salvato

Ripristino del browser e della sessione

I controlli di stato rilevano browser guasti o che non rispondono. Il ripristino usa ritardi crescenti tra i tentativi e limiti agli errori ripetuti. Vangrd salva cookie e archiviazione locale durante il riavvio controllato del browser per aiutare a ripristinare le sessioni.

Controlla lo stato dell'agente e delle attività

Continuità del browser durante gli aggiornamenti

Il servizio che ospita i browser può eseguire Chromium separatamente dal servizio di automazione. Con questa modalità attiva, un aggiornamento del servizio si scollega dal browser e si ricollega dopo. Il servizio che ospita i browser deve restare in esecuzione.

Come funziona l'esecuzione nel cloud

Proseguimento quando un villaggio attende

Le catene di attività indipendenti dei villaggi contengono gli errori ordinari e le attese per le risorse. Le altre catene possono proseguire. Le scadenze del pianificatore e un controllo di sorveglianza rilevano anche le attività ferme. Un guasto del browser continua a influire sulle attività che lo condividono.

Piani di costruzione e controlli delle code

Risorse aggiornate prima delle decisioni

Le attività controllano quanto sono aggiornati i dati delle risorse e aggiornano lo stato dei villaggi non recente. Le previsioni delle risorse usano l'ultima scansione come base. Gli aggiornamenti delle spedizioni dalle risposte del gioco aiutano le attività di rifornimento a considerare mercanti e risorse in viaggio.

Collegamenti di rifornimento e riserve di risorse

Le azioni programmate hanno controlli propri

I piani di attacco salvano lo stato e i tentativi di invio. Una pianificazione dedicata gestisce le scadenze di attacco e difesa. Dopo un riavvio, le attività in scadenza vengono ricontrollate. Tempi mancati e preparativi non aggiornati possono far fallire un piano invece di inviarlo in ritardo.

Configura gli invii degli attacchi e gli orari di arrivo

Le attività bloccate hanno un motivo

La pagina Stato mostra attività, esecuzioni e problemi. Le attese per risorse e i limiti delle code compaiono come stati di attesa. Le attività fallite usano ritardi tra i tentativi. Le credenziali rifiutate richiedono una correzione prima di poter riprendere quell'accesso.

Consulta gli stati di attesa e i problemi

Le modifiche al gioco lasciano tracce

I controlli delle pagine riconoscono le disposizioni dell'interfaccia supportate. Gli errori riconosciuti possono produrre screenshot e una cronologia delle azioni per la diagnosi. Questi dati aiutano a individuare problemi di compatibilità e preparare correzioni.

Leggi le correzioni di compatibilità nel registro delle modifiche

Come verifichiamo questi meccanismi

I nostri test di regressione coprono il recupero dopo un riavvio, i ritardi tra tentativi, le attività ferme del pianificatore, il contenimento degli errori dei villaggi e la ripresa dei flussi. I test usano errori controllati e pagine di gioco campione. Verificano il comportamento atteso in quelle condizioni.

Questi meccanismi di ripristino fanno proseguire le attività consentite e rendono visibili le interruzioni. Le azioni di gioco richiedono una sessione valida e una connessione funzionante.

Un campione registrato dei tempi di attacco

Nel campione registrato, le risposte di invio riuscito sono arrivate con una mediana di 374 ms dopo l'orario previsto. Sedici delle 18 risposte riuscite sono arrivate meno di 1,000 ms dopo l'orario previsto.

Misurazione interna: un account, 19 tentativi, 18 attività completate e un errore prima del gestore di invio finale. Il periodo di osservazione va dal 10 ottobre 2026 alle 05:45 UTC all'11 ottobre 2026 alle 05:45 UTC, estremo finale escluso.

Come abbiamo misurato questo campione

Abbiamo abbinato gli avvii conservati delle attività di invio pianificato ai loro esiti registrati. I tempi misurano quando il client ha osservato una risposta HTTP 302 dopo averne letto il corpo, rispetto all'orario di invio previsto. Includono la rete e l'elaborazione della risposta. Non misurano l'invio della richiesta, l'accettazione del gioco o l'arrivo delle truppe.

Il campione dei tempi include le 18 risposte riuscite. Tutti i 19 tentativi osservati contano nel totale degli esiti. I registri conservati non possono dimostrare ogni intenzione programmata né la raccolta continua. Questo campione di un solo account non stabilisce un tasso dei tempi o del ripristino per tutti gli agenti.

Segui la cronologia di manutenzione

Le note sul prodotto datate mostrano correzioni specifiche, inclusi gli invii critici dopo un riavvio, l'invio di risorse e i prerequisiti degli edifici. Ogni nota ha un collegamento permanente.