[CS:1.6] Configuración Avanzada de Rates

Introducción: Es una admisiòn echa por Steampowered, es una maravillosa herramienta para ayudar a diagnosticar porblemas de conecciòn y distinguir si el problema està relacionado con el cliente, el server o la red. Permite, además, determinar si una screenshot fue tomada durante un partido en vivo o sobre una demo del mismo Opciones para la optimizaciòn cl_cmdrate Número de veces por segundo que el cliente manda información al server Haga click aquí para mostrar el contenido Lo ideal es que este valor iguale los fps del server, NO los fps del cliente como la mayoría piensa. Si uno manda información al server más veces que los que el mismo calcula recibir,los frames exedidos en el mismo período de tiempo se perderán, osea que el server no va a recibir nuestra información, por lo tanto, el valor máximo de cl_cmdrate no debe ser demasiado , sino perderá ancho de banda." cl_cmdrate ES un factor de sus FPS. Para probar esto tipee en la consola net_graph 1, mire sus fps actuales. Si su cl_cmdrate es MÀS BAJO que sus fps, notará los puntos rojos que son exhibidos abajo del gràfico: Suba levemente el valor de cl_cmdrate sobre el valor de los fps y mire como los puntos rojos desaparecen: El área final es la luz azul y (a veces) la roja al fondo del gráfico. Esta lìnea se basa en sus fps y en su ajuste en el valor de cl_cmdrate. Por cada frame donde una serie de paquetes es actualizado y mandado cuando se updatea, la luz azul aparece en el gráfico. Si estas series son acumuladas cuando estamos updateando aparecerán los puntos rojos en el gráfico. Pruebe poner el valor de cl_cmdrate a la mitad de sus fps para ver el efecto." De cualquier manera, los puntos rojos significan que su valor de cl_cmdrate es demasiado bajo y las series se están acumulando, porque usted tiene un valor de FPS más alto que el valor de cl_cmdrate. Recomendaciòn: Haga click aquí para mostrar el contenido Fije su valor de cl_cmdrate con un número 5 veces más alto que el valor de los FPS. Esto asegurará que usted esté enviando tantas series de paquetes como sean posible. Si su conexiòn es irregular y empieza a laguearse en las situaciones de enfrentamiento directo (tiroteos), es posible que el valor que le dio al cl_cmdrate es alto. cl_updaterate y ex_interp Nùmero de veces por segundo que el cliente pide información al server | tiempo de interpolación. Haga click aquí para mostrar el contenido Elcl_updaterate debe ser igual al valor de sv_maxupdaterate del server en el que estemos. Esto trabaja de la misma manera que el cl_cmdrate. Deseamos mandar/recibir la cantidad de paquetes MÁXIMOS como sea posible. En relación con el gráfico el área cuatro funciona correlativamente a como el cliente renderiza los cuadros. Por cada cuadro renderizado, el gráfico indica cuanta interpolación fue utilizada en objetos. Si no está consiguiendo un numero suficiente de actualizaciones del servidor o pierde bastantes paquetes, no podrá interpolar, y en lugar de interpolar, deberá extrapolar. En este caso, se puede ver en la parte inferior del gráfico pasar por encima la línea grisácea (sobre el área azul marino) se torna desde amarillo a rojo/anaranjado, dependiendo de cuanto tardan en llegar los paquetes. Entonces, debemos poder fijar el valor de cl_updaterate correctamente, y esto fijarà el ex_interp a su valor correcto (solamente si su sistema fija automàticamente al ex_interp en 0). Tipee en la consola "net_Graph 1" Ahora fijamos el valor de cl_updaterate a 51. Fijamos el valor de ex_interp a 0. Y automáticamente se setea ex_interp a cualquier valor. PERO, si miramos el gráfico. estamos recibiendo puntos amarillos/anaranjados, que quieren decir que estamos extrapolando. Sucede esto porque estamos recibiendo 51 paquetes, cuando el servidor puede enviar solamente 30 (sv_maxupdaterate 30). Por lo tanto, estamos perdiendo paquetes y estamos extrapolando. No deseamos esto asì que cambiamos nuestro cl_updaterate a 40, y nuestro ex_interp se fija automáticamente otra vez. Conseguimos este resultado: Notese como los puntos amarillos son más bajos comparado con el cuadro de cl_updaterate 51. Esto es porque todavía estamos perdiendo paquetes porque recibimos solo 30 del servidor. Esto hace mala interpolación otra vez, osea, extrapolamos. Cambiando nuestro cl_updaterate a 30, se fija el valor de ex_interp automáticamente y conseguimos esto: Ahora, estamos recibiendo los paquetes máximos del servidor como es posible y por lo tanto no perdemos ningún paquete. Por ende se fija nuestro ex_interp al valor correcto. En conclusión, tenemos que emparejar nuestro cl_updaterate con el sv_maxupdaterate de los servidores en los que juguemos, de modo que podamos interpolar correctamente los movimientos del jugador basados en los paquetes REALES que recibimos y no se pierden. Rate Lìmite màximo de bytes por segundo que el server puede mandar al cliente. Haga click aquí para mostrar el contenido Todos tenemos que hacer que el rate aumente gradualmente, asi no recibimos choke cuando estamos en combate directo. Esto garantiza que se están enviando y recibiendo todos nuestros paquetes, de lo contrario el valor de ex_interp es incorrecto. cl_smoothtime Las predicciones de correcciones de errores pueden ser absolutamente sensibles. Para alisar visualmente ese efecto, el error de la predicción se corrige gradualmente sobre una cantidad de tiempo corta (el cl_smoothtime)." Deseamos ver la interpolación de los paquetes REALES recibidos. Por lo tanto, si fijamos el cl_smoothtime a 0, nuestra interpolación "no será alisada" o corregida y veremos la posición real de los jugadores. Esto causará un "salto" en los movimientos de los jugadores, pero estará todo correctamente funcionando.