Registro de impactos sin compensación de lag Server-now hit validation

ID de la causa sy-no-lagcomp · Responsable principal Desarrollo de servidor (Equipo de desarrollo) · También Desarrollo de cliente (Equipo de desarrollo)

Abrir la ficha interactiva con gráficos y simulaciones →

Si el servidor resuelve los impactos solo con “la posición actual en el servidor”, lo que viste en tu pantalla y el resultado no coinciden.

Por qué En tu pantalla, el rival está en su posición de hace unos 0.2 s (con 150 ms de ping y 100 ms de interpolación) → Efecto El servidor resuelve con la posición actual, y el rival ya no está donde apuntaste → En pantalla En tu pantalla le diste, pero cuenta como fallo. Hay que disparar por delante de los objetivos en movimiento

Síntomas: Acción perdida / rollback
Factores: Latencia
A quién afecta: Solo yo
Cuándo: Al hacer ciertas acciones
Responsable: Responsable principal Desarrollo de servidor (Equipo de desarrollo) · También Desarrollo de cliente (Equipo de desarrollo)
Tareas (Equipo de desarrollo): Servidor: rebobinar hasta el momento que veía el atacante y resolver ahí (compensación de lag), o cambiar a un sistema de selección de objetivo. Cliente: enviar con cada ataque el momento que estaba viendo (la hora del servidor que se está interpolando).
En el gráfico: Alto solo en algunos · Tasa de acierto contra objetivos en movimiento (por rango de ping)
Dónde mirar: Registrar juntos en el log de resolución del servidor la hora del ataque, la posición del objetivo en la pantalla del atacante (valor enviado por el cliente), la posición del objetivo en el servidor usada para resolver y el RTT del atacante. En una build de desarrollo se ve de inmediato si se dibuja sobre la pantalla del cliente la posición que usó el servidor
Se confirma si: En los fallos, la diferencia entre las dos posiciones es aproximadamente la velocidad del objetivo × (RTT del atacante + tiempo de interpolación), y cuanto más ping, más baja solo la tasa de acierto contra objetivos en movimiento
Se descarta si: Si también se falla contra objetivos quietos, es un problema de hitboxes o de detección de colisiones. Si hay desajuste incluso con rebobinado, revisar si el cliente informa mal al servidor de su tiempo de interpolación
Se verifica con: Requiere logs y métricas del servidor o el cliente del juego

Fuentes

Latency Compensating Methods in Client/Server In-game Protocol Design and Optimization (Yahn W. Bernier, GDC 2001) Valve
Sin compensación de lag hay que disparar por delante, tanto como la latencia. Con compensación de lag, el servidor rebobina la latencia más el tiempo de interpolación para resolver
Peeking into VALORANT's Netcode Riot Games
El servidor rebobina hasta el estado del juego que veía el jugador al disparar para resolver el impacto; el cliente envía también la hora de simulación que estaba viendo
Source SDK 2013: player_lagcompensation.cpp Valve
Tiempo que rebobina el motor Source = latencia de red + tiempo de interpolación

Ver también

Misma capa: Diseño del netcode

Causas de otras capas con el mismo síntoma (Acción perdida / rollback)

Error de sincronización del reloj L1 Proceso del juego en el cliente
Límites de conexiones y puertos del gateway NAT en la nube L5 Equipos de red del centro de datos
Microrráfagas en el switch L5 Equipos de red del centro de datos
Búfer circular (ring buffer) insuficiente L6 Tarjeta de red del servidor
Límite de PPS de la nube superado L6 Tarjeta de red del servidor
OOM killer L7 SO del servidor (kernel)
Salto del reloj del sistema (step de NTP) L7 SO del servidor (kernel)
Agotamiento de puertos efímeros en conexiones entre servidores L7 SO del servidor (kernel)

Ver la ficha interactiva con gráficos y simulaciones