Se o servidor checa com rigidez demais a velocidade de movimento, o cooldown e o alcance, rejeita até inputs normais que chegaram juntos por causa do jitter.
Por quê Critérios rígidos como “distância máxima por tick” e “tolerância de 0 ms no cooldown” → Efeito Quando o jitter faz dois comandos chegarem no mesmo tick, o servidor considera violação da regra → Na tela Rubber banding, skill rejeitada mesmo com o cooldown pronto
Aleatoriamente, de vez em quando, Em movimento ou ao trocar de mapa
Responsável
Responsável principal Desenvolvimento do servidor (Equipe de desenvolvimento)
O que fazer (Equipe de desenvolvimento)
Checar por tolerância acumulada (token bucket), deixar folga do tamanho do ping e do jitter.
No gráfico
Picos aleatórios · Rejeições na validação do servidor e correções de posição
Onde olhar
Registrar no log do servidor, a cada rejeição na validação ou correção de posição, o motivo, quantos comandos daquele jogador chegaram naquele tick e o intervalo de chegada desde o comando anterior
Confirma se
As rejeições e correções se concentram nos momentos em que 2 ou mais comandos chegaram no mesmo tick, e o deslocamento e o número de usos somados em janelas de alguns segundos ficam dentro da regra
Descarta se
Passa da regra mesmo somando em janelas de alguns segundos: possível excesso de velocidade real ou cheat. Rejeições concentradas em uma operadora e no horário da noite: aponta para “Falsos positivos da validação concentrados em uma operadora”
Como verificar
Exige logs e métricas do servidor ou do cliente do jogo
Fontes
Source SDK 2013: player.cppValve Um orçamento de processamento de comandos que se acumula a cada tick (no máximo sv_maxusrcmdprocessticks, 24 ticks) permite comandos que chegam juntos. Comentário de desenvolvimento dizendo que bloquear com mais rigidez fazia jogadores normais também terem engasgos