Hemos viciado con el CS:S lo suficiente como para saber como es el funcionamiento de este juego y para descubrir algunas cosas interesantes que se deben saber a la hora de jugar. Lo que sigue son una serie de explicaciones, algunas complicadas, otras mas simples, otras mas interesantes y tambien las hay aburridas
Hay tres situaciones que trataremos de aclarar:
1. Si disparas por encima de una caja o una pared y vuelves rapidamente, no se ve el fuego enemigo, e igualmente resultas herido aunque hayas vuelto a cubrirte.
2. Doblas una esquina del mapa y apareces justo enfrente de un oponente, le vacias el cargador entero y lo mata. Luego abres la consola y ésta indica que sus disparos impactaron sólo un par de veces, a pesar de que le hayas vaciado el arma disparándole a quemarropa.
3. Un jugador dispara o corre hacia ti, disparas y ves sangre en el otro modelo del jugador, y el daño no se registra.
Para aclarar esto, primero algunas definiciones:
Latencia (ping) - El tiempo de retraso entre tu computadora enviando un paquete de informacion o actualizacion, y el server recibiendolo (y vice versa).
Servidor - El motor de un servidor de CS:Source, usualmente corriendo en una computadora en internet.
Cliente - El juego corriendo en tu computadora. La cosa con armas, sonidos y gente corriendo alrededor.
Trayectoria de tiro - La linea que une el final del cañon del arma que usas y la bala que has disparado impacta en algo.
Hitbox - Los modelos de los jugadores de CS:Source estan divididos en "hitboxes", los cuales son areas del modelo en forma de bloques. Si un tiro impacta en un hitbox, anota un tiro. Tu puedes ver los hitboxes del personaje abriendo el modelo con un editor.
CS:Source - Las bases
Como cualquier juego online de tiros el problema principal es la latencia. Cada jugador necesita sentir que él y sus oponentes se mueven libre y suavemente cuando en realidad el juego se actualiza periodicamente y hay grandes retrasos de tiempo entre el envio de tales actualizaciones y el arribo a su destino.
Primero algunas cosas simples:
Tu posición en tu cliente, en el servidor y en la de los demas clientes nunca esta sincronizada. Esto es debido al retraso entre tu enviando tu posicion en el servidor, el servidor simulando un "cuadro" del juego y actualizando tu posicion, el servidor enviando hacia afuera una actualizacion de tu posicion a los demas clientes, y ellos recibiendola.
La manera de la cual esta situación conduce a algunos efectos confusos que puedan ser visto a veces en el juego.
Situación 1: *El hitbox lagoso*
Si disparas por encima de una caja o una pared y vuelves rapidamente, no se ve el juego enemigo, e igualmente resultas herido aunque hayas vuelto a cubrirte.
La Explicación:
Para explicar que esta pasando tenemos que considerar que pasa en tu cliente (jugador 1), el servidor, y el cliente enemigo (jugador 2).
Cosas que necesitas saber antes de continuar:
1. Los golpes reales (posiciones del hitbox) se calculan en el servidor. El cliente no pierde de vista los hitboxes para los efectos del cliente (como las chispas de un casco), pero hablaré más sobre esto en la situación 3.
2. Asumo un tiempo de actualización de 30ms (hay retraso de 30ms para que actualices el servidor y el servidor para actualizarte). Este número no es realmente importante, sólo es el hecho de que hay retraso causado por el tiempo que se toman los paquetes en ir desde el cliente hasta el server. En realidad, este número es realmente un poco mas alto (sin importar el ping)
3. El tiempo que le toma al server/cliente para procesar una actualización es demasiado chico para ser ignorado.
La situación ocurre por la "compensación del lag" que esta dentro del motor del juego. Para apreciar por que lo necesitamos, primero veamos que pasaria si no hubiese "compensación del lag".
0ms (foto 1)
Jugador 1: presiona la tecla "strafe" --> sale de atrás de una caja --> apunta al jugador 2 (quien esta inmóvil por simplicidad)
Servidor: nada (actualización no se ha alcanzado todavía)
Jugador 2: nada --> está todavía, esperando que salga el jugador 1
30ms (foto 2)
Jugador 1: presiona la tecla "strafe" opuesta --> vuelva atrás de la caja
servidor: Recibe la actualización de la posición del jugador 1 (foto 1) y envía una actualización al jugador 2
Jugador 2: Nada (recuerda que la actualización le tomará 30ms para alcanzarlo)
60ms (foto 3)
Jugador 1: Esta detrás de la caja en su cliente
Servidor: recibe la actualización de la foto 3, pone la posición del jugador 1 detrás de la caja (entonces el jugador 1 y el servidor están sincronizados)
Jugador 2: consigue la foto 1 de actualización del servidor - > ve al jugador 1 - > dispara al jugador 1 - > pega en el aire
Cuando el servidor recibe los disparos del jugador 2, la posición del jugador 1 es detrás de la caja entonces los disparos no le pegan. Esto no es muy justo, por que en la pantalla del jugador 2 el jugador 1 estaba a la vista y el tiro daba en el blanco, no obstante en el servidor el jugador 1 estaba en otra parte. mmm, no es muy bueno.
Entonces, como solucionar este problema? bueno lo que el motor de Source es aplicar un poquito de matemática inteligente que toma la trayectoria de los disparos del jugador 2 y los movimientos, si estos dieron en el blanco (jugador 1 donde quiera que este ahora). el servidor calcula la cantidad exacta para "mover" la trayectoria basada en la latencia de cada cliente (ping).
El "hitbox" rojo muestra donde estaba el modelo del jugador cuando el cliente disparo. El "hitbox" azul muestra donde estaba el modelo del jugador en el servidor cuando yo recibía la actualización de los disparos. El bloque rojo en el "hitbox" demuestra donde mi tiro golpeó el modelo del jugador en mi cliente, el bloque azul en el "hitbox" demuestra la posición que el servidor tradujo inteligentemente mi tiro basado en mi ping. Nota eso en el cliente de otro jugador, su posición es probablemente la misma distancia otra vez delante del "hitbox" azul. Confuso!!
Entonces "CON" la corrección del lag, el escenario seria como este:
0ms (foto 1)
Jugador 1: presiona la tecla "strafe" --> sale de atrás de la baja --> ve al jugador 2.
Servidor: nada (actualización no se ha realizado todavía)
Jugador 2: nada -> todavía quieto, esperando que el jugador 1 salga.
30ms (foto 2)
Jugador 1: Presiona la tecla opuesta --> se mueve detrás de la caja
Servidor: Recibe la actualización --> la posición del jugador??? (Nadie más ha visto al jugador 1 moverse todavía)
Jugador 2: Nada
60ms (foto 3)
Jugador 1: Esta detrás de la caja
Servidor: Consigue la foto 2 de actualización del servidor - > posiciona al jugador detrás de la caja - > con la compensación del lag en efecto: los disparos que peguen en la posición del jugador 1 en la foto 2 serán trasladados a su posición detrás de la caja.
Jugador 2: Consigue la foto 1 de actualización del servidor --> ve al jugador 1 --> dispara al blanco --> cuando el servidor recibe el disparo, revisa la latencia del jugador 2, aplica la formula mágica de transferencia (que ubica el disparo derecho a tu posición detrás de la caja) y por lo tanto concluye que el tiro estaba en el blanco. El daño se envía al jugador 1, quien se confunde con esto por que esta detrás de la caja/pared.
Ahora "esto" es justo, aunque en su cliente el jugador 1 esta seguro detrás de la caja, el jugador 2 disparo al momento de haber visto al jugador 1, y entonces es justo que espere haber pegado sus disparos. El único problema es que el jugador 1 recibe el daño cuando él esta detrás de la caja que puede llegar a confundirlo. Entonces lo que la compensación de lag hace es permitir que el jugador 2 dispare y le pegue al jugador 1 sin importar el retraso entre su movimiento y el momento en que ve al jugador moverse.
Otra ventaja a este tipo de compensación por lag (retraso) es que no se necesita "adelantarse" a su objetivo para poder impactar en el mismo, y cuando dos jugadores se encuentran al doblar una esquina frente a frente, el jugador con menor ping no obtiene ningún tipo de ventaja sobre el otro.
Mire estas capturas de pantalla (tomados con sv_showimpacts 1), que muestran la diferencia entre las posiciones del cliente (en rojo) y el server (en azul) y la forma en que la trayectoria son movidas (compensadas) desde el cliente hacia la posición del server (el lugar el disparo impacta se muestra como un bloque en rojo o en azul)
Situación 2: * Es una mentira... le pegué como 15 veces *
Ud. dobla una esquina del mapa y aparece justo enfrente de un oponente, le vacia el cargador entero y lo mata. Luego abre la consola y ésta le indica que sus disparos impactaron sólo un par de veces, a pesar de que Ud le haya vaciado el arma disparándole a quemarropa.
Explicación:
Esta situación se presenta (al igual que la primera situación antes descripta) debido a la latencia (retraso) entre los eventos que que ocurren en el servidor y lo que Ud. ve en su cliente. Las razones detrás de estos acontecimientos son muy similares a aquellos descriptos en la situación 1.
Lo más importante a recordar aquí, es que las cosas suceden en el servidor * antes de que * usted las vea en su cliente. Sólo para simplificar, vamos a asumir que ambos clientes tienen el mismo estado de latencia así que usted no tiene que preocuparse de los ajustes de la compensación de la latencia.
A medida que Ud. se acerca a la esquina, ambos clientes están enterados que el opositor está a la vuelta de la misma, así que no hay retroso en que se vean entre ellos mismos. Tan pronto como aparezca el otro, ambos comienzan a dispararse. Ahora debido al retraso, tomará 60ms (suponiendo los mismos valores usados en la situación 1) para que cada cliente vea al otro disparándole, y para que cualquier dato de los daños sea enviado del servidor a los clientes. Esto significa que en el tiempo en que le lleva al servidor calcular los impactos y enviar la información sobre el daño, Ud puede haber realizado 10 disparos. Ahora, si su oponente disparó una fracción de segundo antes que Ud. (o si disparó después pero el tiro impactó en su cabeza), para el servidor Ud. ya está probablemente muerto pero su cliente no lo sabe por lo menos hasta 60ms después que Ud. vio a su oponente. Así que si bien Ud. supuestamente sigue disparando, el servidor simplemente ignora los disparos que haga hasta que el cliente registre la información que le envia el servidor y toma conocimiento de ello y lo mata.
Situación 3: * El disparo que no daña *
Un jugador le dispara o atraviesa junto a Ud. que le dispara y se ve sangre en el modelo del jugador, a pesar de todo el disparo no se registra y se registra que no le produce ningún daño al oponente.
Esto tiene que ver con la forma en que el servidor traduce la trayectoria de sus disparos a su nueva posición desde el lado del servidor. No sólo el servidor registra la información acerca de la posición de todos los objetos y modelos, pero, en el caso de los modelos de los jugadores, tambien ejecuta las animaciones (tales como correr, caminar, etc.). Cuando disparas, y la trayectoria del disparo es traducida por el servidor, el modelo del jugador raramente se encuentra sincronizado (v.g. raramente se encuentra en el mismo cuadro (frame) de la animación, así que la postura del modelo del jugador en un punto determinado es diferente a la del otro. Animaciones tales como correr y disparar causan una cantidad considerable de movimiento sobre todo el modelo. La cabeza se sacude, así como los brazos y las piernas tiemblan. El problema que esto provoca es que un disparo que en el cliente se muestra como impactando en el brazo, la pierna o la cabeza podría en realidad ser traducido como habiendo impactado en el modelo del servidor en una posicion muy diferente. (v.g. puede haber sido en un lugar más bajo, o la pierna puede estar en diferente posición y el disparo en realidad no impacta).
He aquí una captura de pantalla que muesta la distinta postura de un modelo para el cliente y para el servidor.
Observer particularmente la posición de las piernas que son muy distintas entre el modelo rojo y el modelo azul. Un disparo que impacta para el cliente en la posición señalada como "A" (rojo), no será registrada para el cliente porque la pierna del modelo del jugador se encuentra en una posición más baja (diferente cuadro en la animación en curso).
He aquí un disparo que generalmente no se registra - Le disparo a un oponente justo en el borde de la espalda (que en realidad se encuentra en una posición diferente en el servidor gracias al "bob"), y el bloque azul se encuentra en la pared de atrás (sin impactar en el bloque azul) por lo que el servidor no lo registra.
Esto no es tanto un bug (error de programación) sino un solución necesaria que se implementa por razones de rendimiento. A los efectos de testear los disparos para una misma posición de un modelo que se muestra en el cliente en un instante determinado, el servidor debería mantener un registro o calcular todas las posiciones retrasadas de los modelo para cada jugador en el servidor.
En un servidor con 16 jugadores esto significaría:
16 x 15 = 240 posiciones de modelos que necesitan ser calculadas y testeadas para impactos si todos los jugadores se encuentran en el mismo lugar y disparandose simultaneamente (en el peor de los casos).
Así que no es factible hacer esto eficientemente.
Observe que lo contrario a esta situación también ocurre (Ud. no acierta en el cliente pero impacta en el servidor) así que de todas formas se nivelan las diferencias.
Resumen de informaciones útiles y conclusiones.
1. sv_showimpacts es el padre de todos los comandos del servidor. Permite que usted vea donde sus tiros impactan exactamente tanto en los modelos de los jugadores como en los objetos brindándole información indispensable para corregir su puntería. También le permite testear que objetos y paredes pueden ser atravesados y con que armas. Disparándole a las paredes, se puede examinar la dispersión de los proyectiles y la precisión de cada arma a corto, medio y largo rango mientras se encuentra parado, agachado, corriendo, etc. Cada arma tiene distinta dispersión y el primer disparo en algunas no es el más preciso. Use este comando para ajustar sus ráfagas al número de disparos óptimo para mantener la precisión.
2. Si usted desea garantizar un impacto entonces necesita dispararle al modelo del jugador oponente en el medio. Brazos y piernas son los peores lugares para disparar porque son los que presentan la mayor diferencia entre el cliente y el servidor (usted tiene cerca de un 70% de registros de la información). La parte superior o trasera de la cabeza tampoco es aconsejable ya que la misma se balancea.
3. Las salpicaduras de sangre en el modelo del lado del cliente, no necesariamente indican un impacto real. Salpicaduras de sangre en el piso y en las paredes son el mejor indicador de un impacto exitoso. Chispas que se producen en el casco al impactar son tambien registradas del lado del modelo del cliente.
4. Usted no necesita apuntar más adelante de su objetivo tratando de anticipar su dirección. Si usted apunta directamente hacia ellos y dispara, usted impactará en los mismos (a no ser que dispare a un brazo, pierna o la parte superior de la cabeza mientras se encuentran corriendo o dispando, en cuyo caso usted tiene un 70% de probabilidades de regitrar un impacto exitoso).
5. Un ping alto (mientras no sea acompañado por estrangulación -choke- o la pérdida -loss-) no es una desventaja dentro de límites razonables debido a la compensación del retraso. No puedo decirle cuáles son los límites (100? 150?) porque no hay ninguna manera de conseguir un alto ping en el servidor que esté en el cuarto contiguo para correr las pruebas.
-------------------------------------------
P: ¿Qué es el tickrate?
R: En CS:S los servidores tiene diferentes tickrates. El tickrate consiste en el porcentaje de envio de paquetes de datos desde el servidor hacia el cliente. Cuando se crea un servidor, el tickrate básico es de 33, pudiéndose incrementar a 66 o 100. El incrementar el tickrate de un servidor conlleva a que el ping mejore y no ocurra el fenomeno de "balas perdidas". Ahora bien subir, el tickrate de un servidor conlleva al aumento de recursos de pc, esto es, un servidor con el tickrate a 66 necesita mas recursos de ordenador para funcionar que uno de 33.
_____________________________________________
P: ¿Cómo puedo saber el tickrate de un servidor?
R: Activando en consola el comando "net_graph 3" y fijándonos a la derecha del todo el porcentaje de envio y recepcion de datos (33, 66, 100).
_____________________________________________
P: ¿Qué es el CSP?
R: El CSP es el Cal server plugin un programa que se usa en la CAL (Cyberathlete Amateur League).
Su funciónn es prohibir el uso, de cfgs retocadas, bloqueando comandos e invalidando aliases. Básicamente el objetivo de este programa es "forzar" al usuario a jugar default invalidandole comandos e incluso retocando su propia cfg.
Saludos!
Counter Strike Source: Preguntas Frecuentes
Mode Lineal
