Rechazo del servidor tras el feedback anticipado Client-side feedback rejected by server
ID de la causa sy-optimistic-reject · Responsable principal Desarrollo de cliente (Equipo de desarrollo) · También Desarrollo de servidor (Equipo de desarrollo)
Si el servidor no acepta después un golpe o una habilidad que tu pantalla ya mostró, lo que viste claramente queda anulado.
Por qué Los efectos de golpe y las animaciones de habilidad se reproducen antes de la confirmación del servidor (feedback anticipado) → Efecto El servidor vuelve a comprobar el alcance, la posición del objetivo, el cooldown y los recursos, y lo rechaza → En pantalla Salta sangre pero no hay daño, la habilidad hace la animación pero no tiene efecto, solo se activa el cooldown
Responsable principal Desarrollo de cliente (Equipo de desarrollo) · También Desarrollo de servidor (Equipo de desarrollo)
Tareas (Equipo de desarrollo)
Cliente: mostrar con el resultado del servidor solo lo que necesita confirmación, como los números de daño, las muertes o las recompensas, comprobar primero los motivos de rechazo más comunes y, si hay rechazo, devolver el cooldown y los recursos y mostrar el motivo. Servidor: dejar un margen equivalente al ping en las comprobaciones de alcance y posición del objetivo, incluir el motivo en la respuesta de rechazo, recopilar como métrica la tasa de rechazo por habilidad.
Cifras de referencia
El rechazo llega un ping + la espera del tick después de presionar. Con 150 ms de ping, durante unos 0.2 s crees que acertaste.
En el gráfico
Alto solo en algunos · Tasa de rechazo del servidor por habilidad (por rango de ping)
Dónde mirar
Recopilar en el servidor la tasa de rechazo por habilidad y los motivos de rechazo (alcance, posición del objetivo, cooldown, recursos), y dividirlos por rangos de RTT del jugador. En el cliente, registrar cuántas veces se rechaza una acción con feedback anticipado
Se confirma si
Los rechazos se concentran en habilidades concretas y en los motivos de alcance o posición del objetivo, y la tasa de rechazo sube con el ping
Se descarta si
Si los motivos son el cooldown o los recursos y no dependen del ping, revisar si los valores de datos (cooldown, costo) difieren entre el cliente y el servidor. Si no hay rechazos y el feedback empieza solo tras la respuesta del servidor, apunta a “Feedback solo tras la respuesta del servidor (solicitud-respuesta)”
Se verifica con
Requiere logs y métricas del servidor o el cliente del juego
Para saber más
El feedback anticipado es la mejor forma de disimular el ping. Pero cuanto más difiere la información que usan el cliente y el servidor para decidir (posición del rival, recursos restantes), más frecuentes son los rechazos. Si se recopila la tasa de rechazo por habilidad como métrica, es fácil encontrar dónde no coinciden las validaciones.
Fuentes
Using Gameplay Abilities in Unreal EngineEpic Games Las habilidades Local Predicted se ejecutan al instante en el cliente, pero el servidor decide al final y puede revertir el resultado