Si el servidor comprueba con demasiada rigidez la velocidad de movimiento, los cooldowns o el alcance, rechaza incluso inputs legítimos que llegaron juntos por el jitter.
Por qué Criterios estrictos como “distancia máxima por tick” o “tolerancia de cooldown: 0 ms” → Efecto Si por el jitter llegan dos comandos en el mismo tick, se consideran una infracción de las reglas → En pantalla Rubber banding, una habilidad rechazada aunque el cooldown ya terminó
De vez en cuando, al azar, Al moverse o cambiar de zona
Responsable
Responsable principal Desarrollo de servidor (Equipo de desarrollo)
Tareas (Equipo de desarrollo)
Validar con un margen acumulado (token bucket), dejar un margen equivalente al ping y el jitter.
En el gráfico
Picos aleatorios · Rechazos de validación y correcciones de posición del servidor
Dónde mirar
Registrar en el log del servidor, para cada rechazo de validación o corrección de posición, el motivo, el número de comandos de ese jugador que llegaron en ese tick y el intervalo de llegada respecto al comando anterior
Se confirma si
Los rechazos y correcciones se concentran en los momentos en que llegaron 2 o más comandos en un mismo tick, y el movimiento y el número de usos sumados en ventanas de unos segundos están dentro de las reglas
Se descarta si
Si incluso sumando en ventanas de unos segundos se superan las reglas, puede haber exceso de velocidad o trampas reales. Si los rechazos se concentran en un ISP concreto y por la noche, apunta a “Falsos positivos de validación concentrados en un ISP”
Se verifica con
Requiere logs y métricas del servidor o el cliente del juego
Fuentes
Source SDK 2013: player.cppValve Admite comandos que llegan juntos con un presupuesto de procesamiento que se acumula en cada tick (máximo sv_maxusrcmdprocessticks, 24 ticks). Comentario de los desarrolladores: con un bloqueo más estricto, los jugadores legítimos también sufrían tirones