29 May 2018

Contratar servidor de Counter Strike en Perú

Si eres un usuario que reside en Perú y estás buscando el mejor hosting costo-beneficio para Counter Strike, sin duda somos tu mejor opción, hemos estudiado y trabajado en la industria del game hosting durante muchos años. A pesar de que tenemos nuestra infraestructura y hardware en Estados Unidos (USA), hemos implementado estrategias para mejorar la jugabilidad en Perú y otros países de Sudamérica.

Te recordamos que recibimos pagos mediante tarjetas de crédito, Paypal, transferencias y depósitos bancarios en Interbank – BCP.

 


¿Por qué hostear mi servidor de Counter Strike aquí y no en otra parte?

 

Si hacemos una rápida búsqueda de hosting para Counter Strike en internet nos encontraremos con muchísimas opciones de todos los colores y sabores.

Sin embargo, no todas cuentan con nuestras características por un precio bastante tentador.

  • Localidad: Nuestros servidores son alojados en el sur de los Estados Unidos, lo que disminuye la latencia para nuestros jugadores peruanos.
  • Precio: Hemos ajustado nuestros precios junto con las mejores características de la industria del hosting para brindar un excelente servicio.
  • Recomendaciones: La mayoría de nuestros clientes siempre han estado satisfechos y nos han generado buena reputación a lo largo del tiempo.
  • Seguridad: Los servicios gaming siempre corren riesgo de recibir ataques DDoS ya sea por competencia o rencor, nosotros garantizamos seguridad frente a estas amenazas.
  • Soporte: Respondemos todas las preguntas y en tu idioma!

 


¡Nueva actualización de nuestra red disminuyó la latencia de nuestros jugadores en Perú!

 

 

Gracias a una conexión con Telefónica, la latencia/ping bajó considerablemente en nuestro datacenter con sede en Miami, Florida para nuestra línea de Virtual Servers, ahora los jugadores de Perú obtienen desde 60~90ms, lo cual es genial para servidores Counter Strike competitivos!

 

Para comprobar que la latencia es muy baja realizaré una simple prueba desde mi conexión de hogar (Movistar HFC)

Me está generando alrededor de 80~90 ms, genial. Ahora, probablemente con una conexión de fibra óptica y un enrutado más limpio tendrás mejor latencia que la mía. Ahora comprobaremos que esto es cierto, haremos una prueba a un servidor en Lima-Perú abierto para pruebas de velocidad.

60~70 ms, super genial.

 

Sin duda nuestros servidores virtuales son perfectos para gaming en Perú.


¿Qué plan me recomienda contratar para mi servidor de Counter Strike?

 

Antes quiero recordarte que contratar un servidor de CS en Perú puede costarte alrededor de $40 dólares mensuales, un monto bastante elevado para usuarios con un presupuesto bastante ajustado, sin embargo con nosotros te costará sólo $11 dólares mensuales, con mejores características que cualquier otro proveedor, incluso mejor que nuestros competidores en Florida (Estados Unidos).

Con el plan más barato de Virtual Servers en Miami https://advcom.org/vps-hosting será suficiente, además proporcionamos una guía muy detallada de cómo instalar tu servidor de Counter Strike.

 

Si aún eres un novato y no tienes ninguna experiencia en cuanto a servidores de Counter Strike, puedes contratar un plan de Game Hosting, que de seguro te ahorrará mucho trabajo: https://advcom.org/game-servers (estos plaqnes cuentan con un panel de control y sólo están disponibles en Dallas – Texas, por lo que puede aumentar la altencia/ping).

 

¡Pronto publicaremos las pruebas detalladas in game! para comprobarte una vez más que nuestros jugadores de Perú están disfrutando de esto.
Si tienes alguna pregunta escríbenos en: https://clientes.advcom.org/submitticket.php

Share this
14 Abr 2017

[NOTICIA] CS:GO tendrá el motor Source 2

Durante la presentación de Counter-Strike en China, junto a la presentación de la nueva liga organizada por Valve y Perfect World, llegaron a un acuerdo para lanzar oficialmente el juego con una importante mejora, y es que ahora CS:GO será portado al nuevo motor Source 2, esta noticia promete bastantes cambios en muchos aspectos.

Deben saber que este género no ha sido tan popular, ya que el género RTS o los MOBAS como LoL y Dota 2 han dominado el sector. Recientemente han crecido los fans y la comunidad de Counter-Strike en el país asiático, por eso Perfect World preparó esta presentación con muchas sorpresas que alegrarían a todos los seguidores de CS:GO.


CEO de Perfect World en la presentación de CS:GO. Fuente: MarsMedia

Servidores 128 tick en China y más

Recordemos que el motor gráfico Source 2 fue lanzado en el 2015 con la actualización “Reborn” de Dota 2, y mejoró increíblemente el juego con cargas más rápidas, una mejor interfaz, gráficos y elementos del juego más pulidos, etc. Además, anunciaron una nueva interfaz del juego, esto los usuarios estaban pidiéndole hace mucho tiempo a los desarrolladores. Servidores con 128 tick, los servidores actuales del juego son 64 tick y no logran recopilar todos los disparos en una partida online.


Un pollo aparece en la conferencia (se los recuerda por el mapa Italy). Fuente: MarsMedia

VALVe está desarrollando una inteligencia artificial Anti-Trampas (IA Anti-Cheat), las cuentas encontradas con hacks serán baneadas de la plataforma. Confirmaron que la octava operación de CS:GO llegará entre julio-agosto de este año, ha pasado más de 1 año desde la operación Wildfire.

Los servidores de prueba comenzarán el 18 de abril en China, entre las instalaciones de la presentación se creó una réplica en tamaño real del “Site B” del mapa Dust 2. Los asistentes pudieron tomarse fotos en uno de los mapas más emblemáticos de Counter-Strike.


Site B en tamaño real del mapa Dust 2. Fuente: MarsMedia


Site B en tamaño real del mapa Dust 2. Fuente: MarsMedia

¿Cuándo llegará esta actualización a nuestros servidores?

El último anuncio de la conferencia fue “la siguiente gran acción llegará este verano (invierno en nuestra región)”, así que lo más seguro es que junto a la octava operación tengamos la actualización “Source 2” de CS:GO. Recuerden que Krakov Major 2017 será del 16 al 23 de julio y en ese evento nos pueden soltar el anuncio con todas las novedades que llegarán a este gran juego de disparos en primera persona.

¿Estás preparado para el nuevo CS:GO?


Fuente: MarsMedia, MásGamers

Share this
08 Abr 2017
17 Mar 2017

Backup para los Game Servers

Por que siempre pensamos en tu seguridad, hemos agregado la característica de Backup en todos los Game Servers, ahora tu contenido será respaldado por un sistema de copias de seguridad automatizado que se ejecuta todas las noches. En caso de que sufras alguna incidente, esta es tu solución.

Recuerda que es muy importante que inicies un plan de prevención para evitar cualquier incidente que pueda poner en juego la integridad de tu contenido.


Beneficios

  • Protección y disponibilidad de datos todos los días.
  • Las copias de seguridad son almacenadas en el mismo disco duro de tu Game Server, por lo tanto la restauración será instantánea.
  • Privacidad de contenido (tus backups no serán difundidas por ningún motivo, excepto si usted lo autoriza)

¿Necesitas una urgente recuperación?

Para realizar una restauración de tu contenido sigue los siguientes pasos:

  1. Envíanos un ticket de soporte en el área de clientes.
  2. Espera nuestra confirmación de lectura.
  3. Tu servicio es restaurado y notificado.

“Mejor tarde que nunca”

Generalmente las pérdidas de datos ocurren por dar muchos privilegios a usuarios poco confiables, también puede ocurrir por situaciones no intencionales, sea cual sea el motivo estaremos para ayudarte.


Este servicio está sujeto a nuestros Términos y condiciones, en caso de violar alguno nos reservamos el derecho de actuar como manda nuestro TOS.

Share this
04 Nov 2016

Conexiones FTP en tu servicio de alojamiento.

Advanced Company te brindará en todos sus servicios acceso a su servidor FTP, en el cual podrás subir/descargar archivos con facilidad, rapidez y fluidez.
Gracias a nuestra excelente conexión la transferencia de archivos es impecable. Si eres una persona con conocimientos en este tipo de servicios no hace falta explicarte algunas cosas básicas.
Podrás acceder a nuestro servidor FTP desde cualquier “Cliente FTP”, por ejemplo FileZilla, uno de mis favoritos, el cual lo utilizaremos en este tutorial.
Hacer una conexión a un servidor FTP para transferir archivos es relativamente sencillo.


Realizar una conexión a un servidor FTP

La primera actividad a realizar es conectarse a un servidor.
Esta es nuestra información (Ficticia) – por favor utilice su propia información si desea continuar correctamente este tutorial.
Hostname: example.org
Username: john
Password: 7PjU#.J3

Nosotros usaremos la barra quickconnect (Conexión Rápida) para establecer la conexión:

Escriba el hostname (Nombre de Servidor) en la barra quickconnect, campo: Host , el username (Usuario) en el campo: Username:, y también el password (Contraseña) en el campo: Password. Usted puede dejar el campo Port (Puerto) libre, a menos que su información de login especifique un puerto especifico a utilizar (En Advanced Company usamos un puerto distinto al 21 por defecto, ésta y mucha más información la podrás encontrar en nuestro panel de control).

FileZilla ahora tratara de conectarse con el servidor. Si todo funciona correctamente, usted notara como en la “columna” de la derecha cambia de Not connected to any server a desplegar el listado de archivos y directorios.


Navegación y organización de la ventana

El siguiente paso es conocer la organización de la ventana de FileZilla.
Esta es una rápida introducción: Debajo de toolbar(1) y quickconnect bar (2),el message log (3) despliega mensajes relacionados con la transferencia y conexión. Debajo, usted encontrara el listado de archivos. La columna de la izquierda (local pane, 4) despliega los archivos y directorios locales, i.e. los objetos en el PC que se están usando en FileZilla. La columna de la derecha (server pane, 5) despliega los archivos y directorios que se encuentran en el servidor al cual se ha conectado usted. Ambas columnas utilizan un árbol de directorios como encabezado y también se muestra un listado detallado del directorio que se encuentra seleccionado. Usted puede navegar fácilmente a través de los directorios pinchando en ellos con el cursor del mouse, como en cualquier administrador de archivos. En el pie de la ventana se encuentra la transfer queue (6), que lista los archivos que empezarán a transferirse o los que ya han sido transferidos.


Subir archivos

Primero – en el local panel – ubíquese en el directorio en el cual se encuentran los archivos que serán subidos (e.g. index.html y images/). Ahora navegue hasta el directorio destino dentro del servidor (usando el server panel listado de archivos). Para subir la información, seleccione respectivamente los archivos/directorios y arrástrelos del panel local al panel remote. Usted notara que los archivos serán desplegados en el transfer queue del pie de ventana y pronto desaparecerán (si es que todo funciono correctamente) después de haber sido transferidos al servidor. Los archivos y directorios que fueron subidos al servidor pronto deberán de mostrarse en el listado del servidor en la columna derecha de la ventana.

Nota: Si a usted no le agrada usar drag-and-drop, también puede usar el clic derecho en los archivos/directorios (en el panel local) y seleccionar Upload para subir el contenido seleccionado – o simplemente haga doble clic sobre un archivo especifico (esto no aplica de igual manera para directorios).
Nota (avanzado): Si usted habilita el filtrado y sube un directorio completo, solo los archivos no filtrados dentro del directorio serán transferidos.


Descargar archivos

Descargar archivos, o directorios completos, funciona esencialmente de la misma forma que subir archivos – usted sencillamente arrastra los archivos/directorios del panel de servidor a su panel local, arrastra los archivos/directorios de derecha(servidor) a izquierda(local).
Nota: En caso de intentar (accidentalmente) de sobrescribir algún archivo durante la descarga o subida, FileZilla mostrara automáticamente un mensaje preguntando por la acción a realizar (sobrescribir, renombrar, brincar…).


Conclusión

Usted ahora deberá de ser capaz de usar las funciones básicas de FileZilla para la transferencia de archivos en un servidor FTP.
Comentario final: La mayoría de las actividades pueden completarse de diferentes formas. Las formas empleadas en este tutorial son las mas sencillas – si usted invierte un poco mas de tiempo investigando y leyendo la documentación mas avanzada, encontrara formas más sencillas de realizar cualquier actividad que desee (existen botones en la toolbar para las funciones más usadas, algunas funciones también se encuentran en clic derecho).
Si usted se siente mas confidente ahora, le recomendamos que también lea Instrucciones de uso(en) para aprender sobre funciones avanzadas no cubiertas en este tutorial.


Fuente: Filezilla Project

Share this
28 Sep 2016

[GRATIS] Base de datos MySQL para los servidores de juegos

Los servidores de juegos requieren un almacenamiento para todos los datos generado con el paso de los días, por ende se debe tener un espacio dedicado para información importante y privilegiada.

Gracias a las sugerencias de nuestros clientes, he instalado un nuevo equipo dedicado y seguro exclusivo para base de datos MySQL.
Como lo he anunciado en nuestra fanpage de Faceboook (https://www.facebook.com/AdvancedHosting/) es un servicio adicional y gratuito por la compra de cualquier game server.
El número de base de datos depende de los servicios que tengas alojados en Advanced Company, por cada game server obtendrás una base de datos MySQL gratis.


Pasos para obtener tu base de datos:

  1. Adquirir un servicio de Game Server superior a $5.00 USD.
  2. Enviar un ticket de soporte en nuestro panel de control solicitando tu base de datos MySQL.
  3. Esperar nuestra respuesta con los datos del acceso MySQL

Beneficios:

  • Espacio dedicado para datos que requieren permanencia.
  • Los datos no se eliminarán aun así se reinstale el game server.
  • Acceder a los datos desde cualquier servidor o web hosting (esto requiere enviar un ticket de soporte.)
  • Bases de datos alojadas en servidores con protección DDoS de hasta 500 gbps, esto garantiza una disponibilidad de los datos en un 99.9% del tiempo.

Reglas de servicio:

  • Deberás ajustarte a nuestras políticas y condiciones de uso.
  • No abusar y sobrecargar con contenido innecesario, esto podría causar la eliminación de tu base de datos.
  • Por cuestiones de seguridad no se permiten conexiones de servidores terceros, pero puedes contactarnos para excepciones.
  • Evitar acciones que conlleven a lo ilegal.
Share this
11 Ago 2016

MTA:SA y Fast Download.

Multi Theft Auto, al igual que los demás servidores comerciales con el transcurso del tiempo se va añadiendo contenido personalizado y actualizando periódicamente por los desarrolladores, esto desacelera la conexión a los usuarios que ingresan por primera vez a tu servidor.


¿Por qué?

– Los nuevos usuarios tendrán que pasar por el proceso de descarga de contenido, esto tarda según el tamaño del contenido que albergues y la conexión a internet del usuario.
– Si usted no tiene habilitado y configurado el FastDL en su servidor, es probable que tarde más de lo que debería tardar en descargar el contenido.
– Este problema se puede solucionar mediante el uso de una fuente externa de descarga (un servidor web), esto mejorará el rendimiento del servidor, la jugabilidad y la experiencia de los usuarios.


¿Qué se necesita?

1- Configurar “mtaserver.conf”.
2- Un espacio web con acceso FTP.

Lo segundo no es necesario si tienes tu servidor de MTA:SA alojado en Advanced Company. ES MÁS, no necesitas casi nada, nuestro sistema FastDL es automático, sólo necesitas configurar “mtaserver.conf” (Que también viene configurado correctamente, pero este blog fue realizado con fines educativos y nuestro objetivo es que aprendas como funciona el FastDL), en Advanced Company aceleramos todas tus expectativas, si estás interesado en adquirir algún servidor de MTA:SA haz Click Aquí.


1- Configurar “mtaserver.conf”.

En la línea que contiene las etiquetas <httpdownloadurl></httpdownloadurl> debes especificar el URL del espacio web donde están alojados los archivos de descarga rápida de tu servidor.

Los archivos que necesitan ser descargados rápidamente se encuentran en "mods/deathmatch/resource-cache/http-client-files", no se recomienda colocar el "/" al final del URL.
Configuración FastDL mtaserver.conf


Si tienes un servidor en Advanced Company no tendrás dolores de cabeza con este tema, nosotros te proporcionamos un sistema de FastDL automatizado en nuestro panel de control (TC Admin), eso quiere decir que cada vez que subas contenido a tu servidor este se sincronizará automáticamente con el espacio web (también se puede hacer manualmente en la opción “Fast Downloads Sync”).
Solo necesitas colocar el URL que está en tu panel de control en tu archivo de configuración (mtaserver.conf) añadiéndole la ruta de los archivos de descarga rápida, así:


Configuración FastDL mtaserver.conf
En las etiquetas <httpautoclientfiles></httpautoclientfiles> deben tener el valor número "1", caso contrario no funcionará. Usted puede hacer la edición a través de nuestro panel en "Configuration files" o descargando el archivo y hacerlo con cualquier editor de su preferencia.


¿Cómo funciona?

En el archivo de configuración del servidor se especifica que los archivos caché se descarguen desde una fuente externa, un servidor http, eso acelera la descarga, no entraré muy a fondo sobre eso ya que es un tema muy complejo.


Eso es todo lo que debes hacer si tienes un servidor contratado con nosotros, así de fácil y sencillo.
Si no tienes un servidor contratado con nosotros o quieres hacer un FastDL desde otro servidor web debes continuar al paso número 2.


2- Un espacio web con acceso FTP.

Si has llegado hasta aquí, recuerda que es necesario que dispongas de un espacio web (un plan hosting o un espacio de alojamiento proporcionado por tu ISP) con acceso FTP.
Primero necesitas crear un nuevo directorio con el nombre de tu servidor en tu espacio web, después debes subir los archivos de tu servidor que están en “mods/deathmatch/resource-cache/http-client-files” al directorio que creaste.


FastDL MTA en hosting web
Para este tutorial usé Filezilla.


Después de eso, deberás volver al paso número uno y configurar tu archivo “mtaserver.conf” de la misma forma. En mi caso sería “http://MIESPACIOWEB.com/mtaserver”, esta vez no es necesario especificar el “mods/deathmatch/resource-cache” al final del URL.


Eso es todo lo que necesitas hacer para habilitar FastDL en tu servidor, muy sencillo la verdad.
Un cordial saludo, hasta la próxima.

Share this
02 Ago 2016

[CS:GO] Guía sobre rates, interpolación y servidores.

El servidor y el tickrate

Un servidor se encarga de simular un entorno virtual tomando snapshots (pequeñas muestras de información) cada cierto tiempo y así poder registrar con precisión lo que sucede en la partida a cada instante. Decimos que un servidor es tickrate 100 cuando toma 100 muestras cada segundo (1 muestra cada 10 ms). Cuanto mayor sea el tickrate de un servidor mayor será la precisión en la simulación de la partida, acosta de consumir mayor ancho de banda y capacidad de proceso (CPU) en la máquina que hostea el servidor.

Tickrate 64 = 1 tick cada 15.62 ms
Tickrate 100 = 1 tick cada 10 ms
Tickrate 128 = 1 tick cada 7.8 ms
Tickrate 150 = 1 tick cada 6.7 ms

El cliente y el rate

Hasta ahora solo hemos hablado del servidor. Veamos que tienen que tener en cuenta los clientes que se conectan al mismo en función del tickrate al que se sirve la partida.

Supongamos que un cliente con un framerate estable de 100 fotogramas por segundo conecta a un servidor tickrate 100. Esto quiere decir que su máquina es capaz de producir 100 snapshots cada segundo. Para poder enviarle esa cantidad de información al servidor se requiere de un ancho de banda el cual determinaremos con el cvar rate que mide los bytes por segundo que queremos reservarle al juego a la hora de transmitir paquetes. Es importante aclarar que esta variable tan solo atañe al cliente, aunque el servidor pueda forzar el rate del cliente (sv_maxrate/sv_minrate).

Además del rate, el cliente puede definir dos parámetros más:

cl_cmdrate: cantidad de user commands (instrucciones de teclado y ratón) que el cliente sube al servidor por segundo.
cl_updaterate: cantidad de updates que el cliente demanda del servidor por segundo.

Lo más apropiado es que si el servidor es tickrate 100 y nuestra máquina es capaz de generar 100 fps, ambos cvars estén a 100. Si por el contrario nuestra máquina no fuera capaz de sustentar ese framerate lo más propio sería limitarlo en la media y ajustar tanto el cmdrate como el updaterate a esa media. Tampoco tiene ningún beneficio el subir o demandar más updates de los que el servidor puede ofrecer, así que jugar con cmdrate y updaterate superiores al tickrate del servidor es totalmente innecesario. Existe una tendencia bastante habitual a la hora de configurar el cl_cmdrate que consiste en incrementarlo una o varias unidades por encima del tickrate del servidor para corregir la posible pérdida de paquetes desde el cliente. Yo sinceramente no puedo afirmar que eso funcione porque en la documentación oficial de Valve no menciona nada al respecto. Daño no hace seguro así que si os inspira más confianza subirlo un par de unidades no os cortéis. En cuanto al cl_updaterate, como viene limitado por el tickrate del servidor, aumentarlo no tendría ningún efecto.

Es importante tener en cuenta que ambos parámetros dependen directamente del rate que tengamos definido. Tanto es así que si el rate es excesivamente bajo sufriremos de choke por no poder subir suficientes user commands al servidor o descargar el 100% de los updates que nos ofrece el servidor. Pero hablaré más sobre este tema en el siguiente apartado.

Nota: el cl_cmdrate puede también limitarse por el servidor (sv_maxcmdrate). El cl_updaterate no pero tiene su lógica… ¿para qué iba a limitar un servidor la cantidad de updates que recibe el cliente más allá del tickrate preestablecido? Precisamente cuando creamos un servidor tickrate 64, 100 o 128 estamos limitando la cantidad de updates para cada cliente.

Servidor y cliente trabajando en conjunto

Probablemente ahora os estaréis preguntando qué rate es el ideal para poder jugar en buenas condiciones. Este apartado es fundamental e involucra tanto al servidor como al cliente. Para poder explicarlo primero hay que tirar de un poco de teoría.

Counter Strike: Global Offensive tiene un parámetro definido por el servidor (net_maxroutable) que determina cual es el tamaño máximo en bytes de cada paquete de información que se envía y se recibe en las comunicaciones cliente-servidor. El estándar está definido en 1200 bytes por paquete (en el source son 1260). ¿Qué quiere decir esto? Pues que dependiendo de nuestro cmdrate/updaterate necesitaremos enviar y recibir más o menos bytes por segundo:

  • En un servidor tickrate 64 necesitaríamos 1200 * 64 = 76800 bytes. De ahí que los servidores de Valve tengan un rate por defecto de 80.000 bytes
  • En un servidor tickrate 100, 1200*100 = 120000 bytes de rate.
  • En un servidor tickrate 128*1200 = 153600 bytes de rate.

Esto es lo que dice la teoría. En la práctica el ancho de banda se optimiza muchísimo gracias a lo que se conoce como delta compression, la cual consiste en lo siguiente: el servidor no envía un snapshot completo por cada tick sino que tan solo envía los cambios que se han producido desde el último full-snapshot que se envió a cada cliente. Normalmente los full-snapshots se envían solo al inicio de cada ronda o cuando algún cliente sufre de packet loss intenso. Seguro que más de uno por aquí recordará los típicos subidones de choke que pegaban algunos servers públicos al iniciar las rondas; eso sucedía precisamente porque en ese instante el servidor trata de enviar full snapshots a todos los clientes y por algún motivo el ancho de banda es insuficiente, ya sea porque el hosting tiene una restricción de upload baja para la cantidad de clientes que tiene que soportar o porque los clientes tienen sus rates mal configurados y no perciben toda la información que el servidor necesita mandarles.

En definitva: el rate recomendado por Valve siguiendo la teoría expuesta anteriormente está muy por encima del consumo real medio que se hace gracias a la compresión delta, por lo que generalmente podríamos jugar con un rate inferior al sugerido. Ahora, yo recomiendo que todo el mundo empiece a alejarse ya de rates por debajo de los 80000 bytes en servidores tickrate 100 o 128. Y espero que esta información le llegue a unos cuantos server admins porque es bastante triste ver servidores limitados a un sv_maxrate de 30000 bytes o incluso menos.

Interpolación: cl_interp, cl_interp_ratio y lerp

La interpolación es un tema que a muchos nos trae de cabeza pero lo cierto es que es mucho más sencillo de lo que puede parecer.

La interpolación, definida de manera sencilla, consiste en generar uno o varios frames “falsos” a partir de uno anterior y otro posterior, de forma que conseguimos una animación fluída aunque no sea 100% representativa de la realidad. En un entorno virtual que funcionase casi en tiempo real (como una red LAN) la interpolación no es realmente necesaria ya que la probabilidad de que un cliente pierda algún paquete es ínfima. En cambio en entornos WAN (internet) la pérdida de paquetes se produce con relativa facilidad, especialmente en aquellas personas que juegan con wifi o con PCs que no pueden lidiar con el framerate requerido por el servidor, ya sea por insuficiencia de hardware o de ancho de banda. En esos casos la interpolación es un buen aliado.

El lerp, valor que podemos mostrar haciendo uso del net_graph 1, nos indica nuestra latencia de interpolación en milisegundos. En otras palabras: si tenemos un lerp de 10 ms en un servidor tickrate 100 significa que tenemos 1 frame extra para poder interpolar en caso de que haya pérdida de paquetes. Si tuviéramos 20 ms tendríamos 2 frames.

En cuanto a cómo configurar la interpolación, tan solo tenemos que tener en cuenta lo siguiente: el cl_interp lo dejamos a 0 y este se regulará en función del cl_interp_ratio y nuestro cl_updaterate, haciendo una división del primero entre el segundo; me explicaré con varios ejemplos:

  • Situación A: server tickrate 100 con cl_interp_ratio 1 y cl_updaterate 100. El lerp lo calcularíamos de la siguiente forma -> 1/100 = 0.01 segundos = 10 ms = 1 frame adicional para interpolar. Es, si no me equivoco, la interpolación más baja que podemos configurar. Esta configuración es la recomendada cuando nuestra conexión es buena y el servidor funciona correctamente.
  • Situación B: server tickrate 100 con cl_interp_ratio 2 y cl_updaterate 100. El lerp sería -> 2/100 = 0.02 segundos = 20 ms = 2 frames adicionales para interpolar.

Cuando el lerp está de color anaranjado significa que, en caso de pérdida de paquetes de algún cliente corremos el riesgo de perder frames y ver a la gente a saltos.
En resumen:

  • cl_interp 0 // cl_interp_ratio 1: para conexiones/servidores decentes.
  • cl_interp 0 // cl_interp_ratio 2: para conexiones/servidores poco eficientes.

El Netgraph

Es curioso que aunque somos muchos los que usamos el net_graph 1 a diario, pocos saben interpretar los distintos valores que se muestran en el mismo. Con la siguiente explicación voy a tratar de aparcar todas las dudas que podáis tener.

La captura que adjunto a continuación se ha realizado desde un cliente conectado a un servidor dedicado tickrate 128 con la siguiente configuración:

  • fps_max 61
  • cl_cmdrate 128
  • cl_updaterate 128
  • rate 80000

Después de todo lo que habéis leído hasta ahora pensaréis que es absurdo forzar el cliente a 61 fps si es capaz de lidiar un framerate superior. Lo hago simplemente en beneficio del ejemplo que explico a continuación.

A) FPS: indica la cantidad de fotogramas por segundo que se están renderizando en el cliente.

B) PING: tiempo en milisegundos que tarda un paquete enviado desde el cliente al servidor en volver de nuevo al cliente (round trip time, RTT).

C) IN: todo lo que se encuentra en esta fila, a excepción del lerp, hace referencia a la información que entra (IN) en el cliente; en otras palabras, lo que el cliente recibe del servidor.

D) OUT: todo lo que se encuentra en esta fila hace referencia a la información que sale (OUT) del cliente; en otras palabras, lo que cliente envía al servidor.

E) Tamaño en bytes de cada paquete que se recibe del servidor. Recordemos que el parámetro net_maxroutable definía que como máximo los paquetes podían ser de 1200 bytes. Aquí podemos comprobar que, gracias a la compresión delta, el tamaño de cada paquete es muy inferior a 1200 bytes.

F) Tamaño en bytes de cada paquete que el cliente envía al servidor.

G) Consumo medio de ancho de banda de descarga en kilobytes/s.

H) Consumo medio de ancho de banda de subida en kilobytes/s.

I) cl_updaterate del cliente.

J) cl_cmdrate del cliente.

K) Media de updates que se reciben del servidor por segundo.

L) Media de “client command updates” que el cliente envía al servidor por segundo. Como veréis, a pesar de tener el cl_cmdrate a 128 en la configuración de nuestro cliente, tan solo se están enviando 60. La razón es bien sencilla: el cliente tan solo está renderizando 60 frames por segundo (fps_max 61) y por lo tanto no puede subir más información que la que su máquina renderiza.

M) Lerp: latencia de interpolación del cliente en milisegundos.

Como ya expliqué en el apartado “Servidor y cliente trabajando en conjunto”, cada update que enviamos y recibimos del servidor consume una cantidad determinada de bytes. Si nos fijamos en los valores de la captura del netgraph anterior veremos que en el instante que se tomó la captura, el tamaño de los paquetes que estábamos enviando al servidor (F) era de 78 bytes. Si multiplicamos 78 por L deberíamos obtener una cifra muy aproximada a H. Hagamos la comprobación:

78 bytes * 60 = 4680 bytes; 4680 bytes / 1024 = 4,57 Kilobytes

Como veréis en el netgraph nos marca 4,59 Kilobytes. Ese desajuste de 2 centésimas es por estar tratando con medias y redondeos.

Por último destacar también que podemos deducir el tickrate del servidor a partir de los valores máximos de I y J permitidos por el servidor. En cualquier caso, si tenéis dudas podéis poner el net_graph 4 y comprobar el tick directamente.

Conclusión

Quizá la principal razón por la que en muchas ocasiones las balas no registran correctamente es por problemas de configuración tanto en cliente como en servidor. En un servidor con tickrate 100, un cliente que tan solo sube 30 command updates por segundo (cl_cmdrate 30) dificultará el registro de hits ya que el 70% de los frames serán interpolaciones, lo cual reduce la precisión notablemente. Para evitar este tipo de irregularidades y conseguir que el servidor sea equitativo con todos los clientes quizá lo más recomendable sea forzar desde el servidor tanto el rate como el cmdrate de todos los clientes a una cifra común. El rate deberá ser lo suficientemente elevado para satisfacer la demanda del tickrate del servidor.

RPV

Sabe dios que muchos no leeréis todo lo expuesto anteriormente así que aquí simplemente daré las recomendaciones pertinentes para configurar clientes y servidores de 10 slots, aunque yo os recomiendo toda la lectura para que entendáis lo que estáis poniendo. Los valores expuestos a continuación serán solo válidos en condiciones óptimas tanto de servidor como de los clientes conectados al mismo (latencias, fps, capacidad de proceso del servidor y anchos de banda). El server admin y el cliente deberán de configurar lo que se ajuste a sus necesidades, haciendo uso del netgraph como herramienta de benchmarking.

CVARS

Servidor tickrate 64

servidor:

  • sv_maxrate 80000
  • sv_minrate 80000
  • sv_maxcmdrate 64
  • sv_mincmdrate 64

cliente:

  • rate 80000
  • cl_cmdrate 64
  • cl_updaterate 64

Servidor tickrate 100

servidor:

  • sv_maxrate 120000
  • sv_minrate 120000
  • sv_maxcmdrate 100
  • sv_mincmdrate 100

cliente:

  • rate 120000
  • cl_cmdrate 100
  • cl_updaterate 100

Servidor tickrate 128

servidor:

  • sv_maxrate 153600
  • sv_minrate 153600
  • sv_maxcmdrate 128
  • sv_mincmdrate 128

cliente:

  • rate 153600
  • cl_cmdrate 128
  • cl_updaterate 128

Interpolación:

  • cl_inter 0 // cl_interp_ratio 1: para conexiones/servidores decentes.
  • cl_interp 0 // cl_interp_ratio 2: para conexiones/servidores poco eficientes.

Nota: Cuando se fuerzan los valores rate y cmdrate desde el servidor, el cliente solo tiene control sobre el updaterate.

Fuente: mediavida

Share this

© 2018 Advanced Company. Todos los derechos reservados.

Click Me