Fenomeno
Mensagens : 8
Data de inscrição : 27/08/2011
 |  Assunto: source Net Code  Sex Nov 25, 2011 3:25 pm | |
| Netcode fonte
Netcode Source Counter-Strike
- O peculiaridades final.
Esta foi originalmente postado por "Factor The Unknown" no Usuários de Fóruns de vapor , por isso todo o crédito vai para ele.
Renúncia
Este artigo descreve os problemas atuais que o netcode ainda tem underspecific clientside e serverside net convars relacionados. Este é NÃO uma repetição de qualquer vídeo que tenha sido comprovada de forma incorreta 10 vezes mais já, esta não é uma reclamação sobre o recebimento de rego hit pobres, este é um artigo apoiado por evidências e cenários de teste para você experimentar.
Índice
Explicação sobre o conceito atual do netcode counterstrike source.
Explicação sobre as questões atuais com a implementação atual do netcode.
Conceito atual netcode
O netcode Source Counter-Strike é feita sob a suposição de muitos cenários de pior caso, porém também com flexibilidade em mente. Por exemplo, a configuração padrão de atraso interpolação cliente é o suficiente para suportar uma conexão de perder 2 de cada 3 pacotes de dados.
Com isso em mente eu vou primeiro link para um link de referência da válvula que tem a dizer sobre o netcode .
Vamos começar explicando o que muitas pessoas aqui estão simplesmente lendo a compreensão do passado ou não.
Primeiro de tudo, para fazer seu trabalho o "Counter Strike Source netcode cliente" (Como lida seu computador com todo o material que recebe do servidor) , usa um sistema de interpolação tardia, agora não se preocupe, eu vou explicar o que isso significa para você. Porque o netcode fonte é feita para tais cenários de pior caso, ele só assume o jogador que está sendo abled para receber uma atualização a partir do servidor, aproximadamente, 30 vezes por segundo, agora isso pode parecer muito para você, mas o seu computador quer saber muito mais do que isso. Por exemplo, se você tiver um avarage de 50 frames por segundo, 30 atualizações por segundo vai ser 20 a menos. Por exemplo, se o jogador está em execução a partir do lado esquerdo da tela para o lado direito de sua tela, com 30 atualizações por segundo em 50 quadros por segundo, o jogador vai se mover em um frame, e parecem ser parado em o próximo. Isto definitivamente não é o que queremos.
Para contrariar este efeito, o computador não vai imediatamente mostrar-lhe algo assim que receber os dados, em vez disso, buffers os dados para um período de tempo curto (Por padrão, essa é de 0,1 segundos, porém a duração do tempo esses dados estão sendo armazenados para antes de serem exibidos podem ser alteradas usando o seu cl_interp comando), durante este tempo de atraso o seu computador irá receber mais informações do servidor, agora uma vez que seu computador começa a apresentar as informações que recebeu em primeiro lugar, ele já sabe o que está indo acontecer em seguida, porque o seu computador sabe disso, ele pode criar uma transição suave entre as duas peças de informação.
Este é basicamente o que tudo se resume a, à espera de receber mais informações para que você possa fazer uma estimativa educada do que aconteceu entre esses pontos no tempo.
Agora a maior parte deste pode ser modificada (e deve ser, se você pretende jogar em um ambiente competitivo), eu vou mencionar o mais importante: Para bons resultados, muito precisa ser modificado, por exemplo, um servidor padrão será apenas tornar a eventos do mundo 33 vezes por segundo (tickrate) , a fim de aumentar o seu rendimento informação que você precisa para aumentar o tickrate do servidor. Agora uma vez que o tickrate foi aumentado (máximo de 100, o padrão de 33) , você pode alterar as configurações como a quantidade de datapackages desejar receber a partir do servidor (cl_updaterate) , a quantidade de largura de banda que você está disposto a definir disponíveis para este (taxa) , a quantidade de pacotes de dados que você está disposto a enviar para o servidor (cl_cmdrate) , e quanto tempo você deseja para o seu computador para esperar e buffer de informações antes de exibi-lo realmente (cl_interp) , todos estes convars precisam ser conjunto com uma boa relação com um e eachother, por exemplo, se você deseja receber um monte de atualizações do servidor, mas ainda assim, uma baixa quantidade de largura de banda disponível para isso, você receberá "engasgar".
Agora você pode estar pensando, se alguém que eu estou vendo na tela do meu realmente esteve lá há pouco tempo, é por isso que eu sinto falta quando eu matá-lo? O anwser não é, na maioria dos cenários que você acabou de perder, em outros há questões mais complicadas que eu não vou passar no primeiro post, no entanto pode passar por se perguntado sobre. Por que o anwser não é? O servidor mantém o controle das configurações relevantes para netcode para cada cliente, Quando você atirar uma bala, não basta verificar quando tiro ele, ele também verifica o quanto a latência da rede que você está recebendo, em média, e ele verifica o que você teria visto quando você disparou sua bala, em outras palavras, parece no momento em que recebeu o aviso sobre você disparar sua bala, então ele vai voltar no tempo para onde você tirou sua bala no seu computador (rede / internet latência) , em seguida, ele verifica o seu valor cl_interp (ou o tempo que eram visualmente adiada por) e volta no tempo que muito extra. Usando essas informações o servidor pode verificar se a bala que disparou deve acertar alguém ou não.
Para todos aqueles que vi o "hitboxes estão off" vídeos por aí na net, o que estes exibir vídeos não é falsificado, ele irá mostrar como essa. No entanto, o hitboxes você está vendo não é o hitboxes que o jogador tem. O jogador não tem hitboxes, apenas o servidor faz, eles são os locais hitbox do servidor, isso significa que cl_interp não vai atrasar-los de qualquer forma, isso também significa que atirando neles que você vai fazer nada de bom, como o servidor irá ainda reduzir latência da rede e atraso de interpolação do seu tempo de disparo de bala para fazer suas verificações de registro hit.
Problemas com a implementação netcode atual.
Existem actualmente duas grandes questões ainda presentes no netcode source counterstrike, um deles só ocorre com interpolação clientside inteiramente condicionada (cl_interpolate 0, não padrão), e os outros (no entanto, muito menos significativo) com interpolação habilitado (padrão).
Vou começar com o problema existente quando interpolação é ativada, tudo isso começou quando Drax, um ex-CAL - Convidar jogador postou a sua lista de desejos do que deve tornar-se fonte de counterstrike, incluiu uma prova pequeno vídeo mostrando que quando a interpolação é ativado, o atraso foi realmente muito mais do que o atraso definido pelo cl_interp.
Isto pode ser encontrado aqui
Agora, um monte de pessoas têm questionado o seu método de sincronização de ambas as partes do vídeo, assim também eu, como uma questão de fato, eu fui em frente e perguntou-me Drax. Sua anwser? Ele usou o relógio dentro do jogo para sincronizá-los. Pessoalmente, eu não estou totalmente certo de que a precisão deste relógio é, então eu conduzi minha própria parte de pesquisa.
Aqui está o que eu fiz. Uma vez que estamos testando interpolação clientside, servidores coisa não tem nada o que tão sempre a ver com, podemos até testar isso em um ambiente de servidor ouve - ou seja, um servidor não-dedicado - e se você realmente precisar, você pode até mesmo usar um bot para realizar este teste (Quanto ao objectivo deste teste, os resultados são exatamente os interpolação, mesmo simplesmente funciona exatamente da mesma). O que fiz foi, criei um servidor, juntou-se espectadores, e tinha outra pessoa se juntar ao time contra-terrorista. Fui ao seu lado em um ângulo perfeito 90, permitiu que o "hitboxes" (para mostrar a localização do servidor do jogador), e tomou screenshots do jogador correndo para a frente em uma linha reta perfeita, tomei várias amostras para que eu pudesse ler a média, para as leituras mais precisas.
Os resultados podem ser encontrados aqui
Eu conduzi este teste para várias configurações de um cenário de atraso o cliente interpolação (cl_interp), comecei a testar usando cl_interp 0,01-,04, agora os resultados desses testes foram todos os linear, a distância aumentou à taxa mesmo de 0.01 to ,002-,03 a 0,04, então eu tirei a linha de muito mais à frente a 0,1, realizou o teste exato mesmo novamente, e recebeu um resultado preciso em que o calculado e os resultados testados foram uma partida bastante precisa.
cl_interpolate 1; cl_interp 0,01
Média compensado de 9 amostras; 107.89px
cl_interpolate 1; cl_interp 0,02
Média compensado de 9 amostras; 122.00px
cl_interpolate 1; cl_interp 0,03
Média compensado de 9 amostras; 136.78px
cl_interpolate 1; cl_interp 0,10
Média de compensar as de 9 amostras; 233.11px
No entanto, se eu fosse para desenhar a linha de volta para o outro lado, a um cl_interp de 0 (atualmente não é uma opção), eu não acabar sem uma distância entre o servidor eo cliente localização deste jogador. Então eu fui para calcular:
Se um incremento de 0,01 segundo para levar um incremento de 14,11 pixels, uma redução para um cl_interp teórica de 0 corresponderia a um deslocamento de 93,78 restante pixels, já que anteriormente calculou que traduz 0,01 segundo em uma distância de 14,11 pixels, podemos dizer que 93,78 pixels corresponder ~ 0,066 segundo ((93.78/14.11) * 0,01 = 0,06646).
Para aqueles que não tinham chegado ainda, isso significa que o atraso usada por seu computador não é apenas a sua latência da rede e sua cl_interp juntos, há também um extra de 0,066 segundo acrescentou no topo desta (pode não parecer muito , mas 'no jogo' isso se traduz em mais tempo do que você imagina.
Que descreve muito bem a primeira edição (cl_interpolate 1), agora para explicar a questão cl_interpolate 0;
Esta questão é muito mais difícil realmente explicar, porém muito mais fácil de testemunha, e de investigação é conduzida de forma relativamente fácil, primeiro eu vou explicar como você pode reproduzir os resultados do teste que realizei. O método que eu estou descrevendo não é para ser usado como prova, este é apenas um 'experimentar e ver por si mesmo "passo a passo. Criar um servidor de ouvir, adicione um bot, habilitar e permitir sv_cheats bot_stop, pegue uma arma precisa (de preferência o fiveseven), encontrar o bot, mp_friendlyfire 1, tipo cl_interpolate 0 no console, e digite 'bot_mimic_yaw_offset 360', e 'bot_mimic 1' no console. Estes farão o bot fazer exatamente o que você faz. Iniciar strafing de forma lateral, enquanto enfrenta o bot, coloque sua cruz sobre a sua cabeça enquanto strafing, e disparar. Agora coloque o seu crosshair ligeiramente atrás da cabeça do bot (se você está se movendo para o lado direito, coloque-o no lado esquerdo da cabeça (além da cabeça)), strafe mais uma vez, e disparar, você deve ver um respingos de sangue apear. Este é o problema em questão. Você pode replicar o teste exato mesmo em um servidor dedicado com os seres humanos normais, eu fiz isso também e recebeu estes resultados
Pessoalmente espero que isto está relacionado com a questão 0,066 existentes com cl_interpolate 1, no entanto não tenho evidense reais para apoiar isso, é pura especulação. O que eu sei, inquestionável e está na minha mente é que há um problema com o comportamento atual do hitregistration netcode quando interpolação está desativado. Para referência, costumava haver um bug no netcode que causou servidores para não ter consciência do facto de os jogadores usam a interpolação, este bug está actualmente fixado, o servidor vai saber quando um cliente não é interpolação, e vai ignorar totalmente o valor de uma jogadores cl_interp nos cálculos de registro hit quando o jogador não é interpolação.
http://whisper.ausgamers.com/wiki/index.php/Source_Netcode
Última edição por Fenomeno em Sex Nov 25, 2011 3:29 pm, editado 1 vez(es) (Motivo da edição : http://whisper.ausgamers.com/wiki/index.php/Source_Netcode) | |
|
