#26 Todavía no he jugado en un server de tickrate 128, por eso comentaba lo de las balas xD :palm: :mad: 
#31 pues concreta, ...se las traga el server de tickrate 64 xD, porque el registro de este juego en realidad es muy bueno.
#29 Eso ya...
yo siempre he pensado que en el CS hay que "especializarse" en 5 armas e ir a por ellas siempre.
2 Pipas: USP / Glock o a veces cojo Five Seven. Los patrones de disparo continuado son parecidos.
1 Intermedia baratilla: P90 en mi caso. El recoil lo tengo super pillado y lo compenso casi a la perfección cuando pego algún manguerazo, que no es habitual.
2 Fusiles: Ak y M4-s. El recoil de la M4 lo tengo pillado perfecto, puedo disparar casi un cartucho entero a un mismo punto aun en movimiento y sin que se disperse mucho; la suelo utilizar más para pegar no más de 3 tiros juntos. Con la AK soy más selectivo, no controlo muy bien el recoil para manguerazos, y siempre la uso para bala a bala...
#34 La P90 de baratilla nada. Salvo haciendo/defendiendo rush, por ese dinero prefiero compar una FAMAS/Galil.
#39 más o menos la explicación que puedo darte en base a experiencia propia con cosas de curro y proyectos aparte es :
Valve explains Tickrate as: "During each tick, the server processes incoming user commands, runs a physical simulation step, checks the game rules, and updates all object states. After simulating a tick, the server decides if any client needs a world update and takes a snapshot of the current world state if necessary. A higher tickrate increases the simulation precision, but also requires more CPU power and available bandwidth on both server and client."
Básicamente, cada tick se dedica a "recoger" los eventos realizados y a procesarlos.
El tickrate es un concepto no único de CS, y varios de los problemas que esto comporta en simulación son :
Acota inferiormente la latencia efectiva a 1/TR. Esto es, aun teniendo una latencia < 1/TR los eventos van a ser realizados y observados a un tiempo >= 1/TR. De paso, añadir que con esto podemos deducir que un servidor perfecto sería el que tuviera infinito TR.
Depende muchísimo de la implementación, y desconozco como está hecho en este juego, pero una aproximación bastante cutre (aunque bastante usada) es guardar los eventos en una especie de cola y procesarlos por este orden. Si esto se suma a la latencia propia de los clientes es bastante natural que, por ejemplo, mueras en un tiroteo aun habiendo disparado tú primero.
No acabo de entender por qué se pierden balas, en los proyectos en los que he participado no "se perdía" nada, "sólo" observabas (a veces) una serie de eventos un poco inconsistente y/o extraña por lo del punto anterior, también añadir que era simulación en entornos mucho más reducidos. Lo único que se me ocurre es, que al ser la cantidad de eventos independiente y 1/TR el time window para procesarlos, a bajos tickrates recibes mayor cantidad de eventos por tick y esto puede crear un cuello de botella aun teniendo mayor tiempo para procesarlos.
12 días después
1 mes después
12 días después
9 meses después
La gente tiene demasiada esperanza en el 128 tick por sus mangueras, pero si eres un aimer el 64 te va genial.
