Fiabilidad

Fiabilidad de bots de Travian: recuperación y control

Vangrd guarda horarios de tareas, restaura sesiones, reintenta fallos del navegador e informa del trabajo bloqueado. Consulta cómo funciona la recuperación.

Última revisión: 12 oct 2026

Qué ocurre cuando se interrumpe el trabajo

Trabajo guardado tras reiniciar

Vangrd guarda ajustes, definiciones y horarios de tareas. Tras reiniciar, el planificador restaura los horarios y comprueba qué tareas pueden ejecutarse. Los procesos personalizados guardan su posición al terminar acciones y retrasos.

Activadores de procesos y progreso guardado

Recuperación del navegador y la sesión

Las comprobaciones de estado detectan navegadores fallidos o que no responden. La recuperación usa retrasos crecientes entre reintentos y límites de fallos repetidos. Vangrd guarda cookies y almacenamiento local durante los reinicios controlados del navegador para restaurar sesiones.

Comprobar el estado de tu agente y las tareas

Continuidad del navegador durante las actualizaciones

El servidor de navegadores puede ejecutar Chromium separado del servicio de automatización. Con este modo, una actualización del servicio se desconecta del navegador y luego se reconecta. El servidor de navegadores debe seguir activo.

Cómo funciona la operación en la nube

Avanzar cuando un pueblo espera

Las cadenas independientes de tareas de cada pueblo contienen errores ordinarios y esperas de recursos. Las demás pueden continuar. Los plazos del planificador y un supervisor detectan también bloqueos. Un fallo del navegador sigue afectando a las tareas que lo comparten.

Planes de construcción y comprobaciones de colas

Recursos actualizados antes de decidir

Las tareas comprueban la actualidad de los recursos y actualizan el estado desfasado del pueblo. Las previsiones usan la última base observada. Los estados de envío obtenidos de respuestas del juego ayudan a contabilizar mercaderes y recursos en tránsito.

Enlaces de suministro y reservas de recursos

Las acciones programadas tienen sus propias comprobaciones

Los planes de ataque guardan su estado y los intentos de envío. Una programación dedicada gestiona los plazos de ataque y defensa. Tras reiniciar, se vuelve a comprobar el trabajo pendiente. Un plazo incumplido o una preparación desactualizada puede hacer fallar el plan en lugar de enviarlo tarde.

Configurar envíos de ataques y horas de llegada

El trabajo bloqueado tiene un motivo

La página Estado muestra tareas, ejecuciones y problemas. La falta de recursos y los límites de cola aparecen como estados de espera. Las tareas fallidas aplican retrasos de reintento. Hay que corregir las credenciales rechazadas antes de continuar ese acceso.

Leer estados de espera y problemas

Los cambios del juego dejan pruebas

Las comprobaciones de página reconocen diseños compatibles. Los fallos reconocidos pueden guardar capturas y una cronología de acciones para el diagnóstico. Estos registros ayudan a rastrear problemas de compatibilidad y preparar correcciones.

Leer correcciones de compatibilidad en el registro de cambios

Cómo comprobamos estos mecanismos

Nuestras pruebas de regresión cubren la recuperación tras reiniciar, los retrasos de reintento, los bloqueos del planificador, el aislamiento de errores por pueblo y la reanudación de procesos. Usan fallos controlados y páginas de juego simuladas. Verifican el comportamiento esperado en esas condiciones.

Estos mecanismos mantienen el trabajo disponible y hacen visibles las interrupciones. Las acciones del juego necesitan una sesión válida y una conexión funcional.

Una muestra registrada de tiempos de ataque

En nuestra muestra, las respuestas de envíos correctos llegaron con una mediana de 374 ms tras la hora prevista. Dieciséis de las 18 respuestas correctas llegaron menos de 1,000 ms después de esa hora.

Medición interna: una cuenta, 19 intentos, 18 tareas completadas y un fallo antes del controlador de envío final. La observación abarcó del 10 de octubre de 2026 a las 05:45 UTC al 11 de octubre de 2026 a las 05:45 UTC, sin incluir el extremo final.

Cómo medimos esta muestra

Relacionamos los inicios conservados de tareas de envío planificado con sus resultados registrados. El tiempo mide cuándo el cliente observó una respuesta HTTP 302 tras leer su cuerpo, respecto al envío previsto. Incluye red y procesamiento de respuesta. No mide despacho de solicitudes, aceptación del juego ni llegada de tropas.

La muestra temporal incluye las 18 respuestas correctas. Los 19 intentos observados cuentan en el total de resultados. Los registros conservados no permiten establecer cada intención programada ni una recogida continua. Esta muestra de una cuenta no establece una tasa temporal o de recuperación para todos los agentes.

Seguir el historial de mantenimiento

Las notas fechadas describen correcciones concretas, como envíos críticos tras reiniciar, envío de recursos y requisitos de construcción. Cada nota tiene un enlace permanente.