#60 si, pero ten en cuenta que el rate va en base a la conexión que tienes, si tienes 20MB no llevas el mismo rate que si llevas 6MB, o que si llevas 50MB o 100MB.
De cualquier manera es mejor pasarse que quedarse corto.
Como cambio el modo de servidor(a competitivo)? Desde el panel de control no me dice nada.
GameTypes: could not find matching game type "".
No puedo entrar al server 
#43 El tickrate se deduce del cl_cmdrate máximo que te permite el servidor. Habría que ser muy cafre para montar un servidor tickrate 128 y limitar el sv_maxcmdrate a 100 o 66 por ejemplo. Y aunque ese fuera el caso, al cliente lo único que le interesa al fin y al cabo es su límite de cmdrate.
A mi lo que me falta es un netgraph que muestre el choke sin tener que tragarse gráficas de colorines. Para monitorizar nuestro server jugaba con ese netgraph y al final ni veía los gráficos pero hay que reconocer que sin ellos se juega más cómodo xD
#44 Gracias tío! Ya está corregido 
#60 Efectivamente. De hecho nuestro server está configurado tal que así:
sv_minrate 80000
sv_maxrate 80000
sv_mincmdrate 128
sv_maxcmdrate 128
Estuve haciendo pruebas con 10 clientes y no había subidas de choke durante el partido, solo durante el freeze time por eso de que el server envía full snapshots en vez de delta snapshots. Y siempre estaba por debajo del 5%.
#65 Por lo que expliqué de la compresión delta (delta snapshots). A menos que el servidor o algún cliente tenga problemas de conectividad, con rate 80000 vas sobrado.
Nosotros no ponemos más porque nuestro server es casero y no tiene ancho de banda suficiente. A ver si se lo encasquetamos a mi primo y nos lo cuela en su universidad, que ahí tenemos 10 Megabits de subida xD
edit: además, hay que tener en cuenta que rate 120000 son 117 KBytes de subida, lo que equivale a una conexión con una subida de 1 megabit. Eso es bastante subida para un cliente. Aquí en España la mayoría de la gente no tiene ni medio megabit de subida xD
Como comentaba anteriormente, lo importante es no sufrir choke durante la partida. Tu fíjate en tu netgraph y en los Kilobytes que envías al server (OUT). Si en algún momento necesitases más de 35 kbytes/s y tu rate fuese de 30000 bytes/s tendrías choke ya que la cantidad de información que necesitas enviar al servidor no puede llegar debido a insuficiencia del ancho de banda asignado por el rate. Y en servidores tickrate 128 eso puede suceder con cierta frecuencia y por eso se recomienda jugar con rate 80000, para ir con buen margen.
Hola, estoy intentando configurar un servidor DM tick128 pero no hay manera, se queda recibiendo el cliente tick64 tanto de subida como de bajada, ¿ alguien me ayuda ?
he puesto lo que comentaba s1l3nce
sv_minrate 80000
sv_maxrate 80000
sv_mincmdrate 128
sv_maxcmdrate 128
#68 Me ha funcionado a la perfección. muchas gracias ahora solo falta que entre gente al dm.
5.9.217.78:27015 hay que probarlo asi que cuando vea que esta lleno si la cpu se pone loca (es un vps aleman) tendré q bajar los slots o el tickrate
#68 una pregunta....yo tengo un sv q pone el tikrate 64
si en opciones de lanzamiento del sv pongo -tickrate 128.....puedo meterle los sv_max y sv_min del tickrate 128?
o aunq en opciones de lanzamiento del sv le ponga -tickrate 128 seguira siendo de 64?
se queda aquí:
Server approved grace request...
Retrying connection to 5.9.217.78:27015, server requires lobby reservation but is unreserved.
Received game details information from 5.9.217.78:27015...
[MM] Sending reservation request to 5.9.217.78:27015
[MM] Sending reservation request to 5.9.217.78:27015
#72 Si en opciones de lanzamiento pones -tickrate 128 será un server con 128 updates por segundo. Así que lo suyo es que limites el sv_maxrate/sv_minrate y sv_maxcmdrate/sv_mincmdrate a 128 si tu server es tick 128.
#74 Todos esos valores a 128? a mi me vienen así de la ESL
sv_maxcmdrate 128 // If sv_mincmdrate is > 0), this sets the maximum value for cl_cmdrate.
sv_maxrate 0 // min. 0.000000 max. 30000.000000 replicated Max bandwidth rate allowed on server, 0 == unlimited
sv_mincmdrate 30 // This sets the minimum value for cl_cmdrate. 0 == unlimited.
sv_minrate 20000
#75 La config de la ESL, además de desactualizada (el que la ha escrito vive en el pasado) es demasiado permisiva con los putos lamers que se ponen el cmdrate a 30 para que sea jodidísimo endiñarles cuando van corriendo. Son muy listillos... se bajan el cmdrate pero el updaterate (lo que recibes del servidor) se lo ponen al máximo.Yo prefiero bloquearlo para que todo el mundo se gaste los mismos cmdrates.
En cuanto al rate, un minrate de 20k es bajísimo. En un server tickrate 128, alguien con 20k de rate tiene choke entre 5% y 10% continuamente. No es nada recomendable bloquearlo tan bajo. Por otro lado, el limitarlo a un máximo es a gusto personal ya que, en teoría, ningún cliente va a consumir más bytes de los que se requieren para mantener 128 command updates (cl_cmdrate 128). El límite teórico son 153600 bytes por segundo en caso de que subiésemos full snapshots (paquetes completos de 1200 bytes por paquete) pero como son delta snapshots (información comprimida) lo normal es que durante la partida con 80000 bytes vayamos muy sobrados. Ten en cuenta que cada paquete/snapshot que recibes o envías al servidor son de un tamaño máximo de 1200 bytes; de hecho normalmente nunca usan ni la mitad de los bytes y de ahí que con rate 80000 nos sobre ancho de banda.
Yo recomiendo que si tu server es tickrate 128 y va holgado de ancho de banda le metas estos valores:
- sv_maxrate 153600 (o cero si no lo quieres limitar).
- sv_minrate 80000
- sv_maxcmdrate 128
- sv_mincmdrate 128
La
la parte que está en negrita es absolutamente falsa.
Según está redactada, da a entender que si hubiera un arma que disparase 100 balas/segundo, una persona con cmdrate 66 / updaterate 100 sólo podría ser impactada por 66 de esas balas. No sé de dónde habrá salido tal idea pero es una ida de olla increíble, el hitbox no desaparece en esos 34 ticks.
#76 El de NLS por defecto es tickrate 64 así que cambiaré el mincmdrate por 64 y listo. Gracias de todas formas
#77 No es falsa, es netcode puro y duro.
Un tipo que solo sube 66 command updates al server (cl_cmdrate 66) solo sube 66; ni uno más, ni uno menos. El resto se interpola, como ya expliqué en el apartado de la interpolación. Y lamentablemente la interpolación está muy lejos de la realidad, especialmente cuando un tipo manda solo el 66% de sus paquetes. De ahí que dar a un tipo corriendo que sólo sube poco más de la mitad de sus paquetes sea tan jodido.
Y teniendo en cuenta que la cfg de la ESL permite un mincmdrate 30 pues ya puedes fliparlo. Son putos caspers por el mapa.
#78 En ese caso es tu mejor opción. Pero apriétales xD
edit: Sinso, te corrijo con datos sobre la mesa y tú sigues en tus trece. Veo que no has cambiado nada en todos estos años xD
En mi server forzaré lo que me salga de las pelotas. Tenemos a uno en el equipo que va con wifi del vecino y fue el primero en tomar esa decisión xD Bastante que lo vamos a pillar fuera de España. Lo que me parece lamentable es que me digas tú como tengo yo que configurar mi server, cuando yo aquí solo he dado recomendaciones (con datos sobre la mesa, te lo recuerdo). Que cada uno juegue y configure su server como le salga de las pelotas. Cuando juegue en el nuestro ya sabe lo que hay.
En cuanto a la interpolación del source, aunque es un buen remedio no es la cura de todos los males (especialmente con los lamers de turno). Y utilizarla es una soplapollez como un templo que entendería hasta un casual de consola (y se ha explicado en este hilo).
Lo que sí tiene un trabajazo de quitarse el sombrero es el lag compensation, aunque eso va de mano del netcode. Con tenerlo activado es suficiente.
#79 No es falsa, es falsísima en mayúsculas. De siempre ha existido este tema semitabú en el que si hay una persona que no usa la misma configuración que yo es que tiene ventaja de alguna manera que yo desconozco, nunca le perjudica.
Lo que es absurdo es querer imponer la misma configuración a una persona que juega con 100mb simétricos que a otra persona que juega vía wifi de 1mb.
La interpolación que aplica el motor source es brillante (tiene sus problemas, por supuesto) si se utiliza correctamente, forzar a todo el mundo a jugar con rate 120K y cmdrate y update 129 no sea que el vecino sepa algo que yo no se es lamentable (y seguirá haciendose)
Puestos a forzar (ya que la interpolación es el diablo), después del rate y del cmdrate 129, por qué no "interpolate 0"? No hace falta que contestes, ambos conocemos la respuesta.
#78 ¿Qué datos? Si lo más llamativo que hay en #1 es leer que un tío con cmdrate 66 tiene un 34% menos probabilidad de recibir impactos que uno con cmdrate 100 y esa "conclusión" te la sacas de la manga igual que un vidente te dice que te va a ir bien económicamente. Tú eres una persona con cerebro, esas conspiraciones son dignas de un canal de irc.
Yo no impongo nada, vuestro server configuradlo como os salga del pene, faltaría más, para eso lo pagáis. Más imposición es advertir sobre problemas ilusorios si no se hacen las cosas como dictas. De la misma forma que tu das una opinión yo doy otra como he hecho en montones de threads que considero equivocados antes que éste.
Y fíjate que no me meto en
. Los cálculos para establecer ese rate aconsejado en #1 se toman partiendo de la premisa que todos los paquetes ocupan esa cantidad. El tema es cuanto menos cuestionable, entiendo que la multiplicación se haga para prevenir un hipotético momento en el que los 100 ticks o 128 ticks necesitasen tener ese tamaño, pero esa situación puede llegar a darse realmente? Yo tengo mi opinión sobre el asunto pero no voy a entrar por esa puerta.
No me verás discutiendo con nadie sobre la compensación de lag, por supuesto.
#80 Lo más llamativo que hay en #1 es un tochopost que evidentemente no te has leído.
Me sales con la chorrada de la "desaparición" de hitboxes por puro desconocimiento, me molesto en aclararte lo que sucede con un cliente que envía menos paquetes de los requeridos por el servidor (que ya estaba explicado en #1, por cierto) y acabas yéndote por la tangente moralfag para decir que te parece lamentable bloquear rates y cmdrates porque la gente con wifi de 1 mega no puede jugar. Además, por supuesto que puede; que el rate máximo/mínimo de nuestro server sea 80k no significa que necesites una subida continua de 78 kbytes/s. De hecho el 99% del tiempo no estarás usando ni el 20% de ese bandwidth. Y teniendo en cuenta que la subida mínima que se ofrece en España son 320 kbps, estás dentro del margen. Tan solo notarán algo de choke en los inicios de ronda o si pierden paquetes con frecuencia (también explicado en #1).
En cuanto al último párrafo, vuelvo a lo mismo: no te has leído el thread. Eso también está explicado y se llama "delta compression" (cuarto párrafo del tercer apartado). Es que hasta estaba en jodida negrita xD
¿Sabes el valor que tiene la opinión de alguien que ni sabe, ni entiende, se las da de sabido y cuando se le ponen los datos sobre la mesa se pira por la tangente? pues eso.
No voy a seguir discutiendo sobre este tema porque está más claro que el agua.
#81 ¿Te refieres a los frames de salida, no?
#82 en el net graph me sale 100 de out 70 80 ....y eso me va fatal en el juego....los rates cuales son aqui siguen suiendo 25000 101 101 cl_interp 0 y cl interp radio 1?
#83 Suponiendo que estés en un server tickrate 128 y tengas el framerate bloqueado a 101 o el cmdrate a 101 es normal que no suba de ahí. Súbelos ambos a 128.
Los rates deberías ajustarlo en función del tickrate del servidor.
Cuando estés en un server tickrate 128 haz una screenshot para ver tu netgraph y súbelo por aquí.
#84 http://postimage.org/image/7f8wbnvut/
tengo 75 constantes y sube asta 100...aqui voi a rate 100 100 25000....las balas se las come
el server es de 100 de tick
#85 Creo que, si no me equivoco, las balas se las come el server porque el LERP lo tienes naranja y pierdes paquetes.
Para que te vaya bien, el LERP, tienes que tenerlo blanco.
dos preguntas:
1º
pongo el cl_interp a 0 ----> todo bien
pongo el cl_interp_ratio 1 ----> y el lerp se me pone de color naranja, y si le pongo a 2, se pone en blanco (supuestamente es mejor tenerlo en blanco)
mi pregunta es:
porq si le pongo a 1 el lerp se me pone en naranja? (decir q tengo una muy buena conexion de fibra optica)
2º
paso de los 100 fps sin problemas.
es mejor limitarlo a 100 fps o dejarlo a 300 y q corra el por donde le de la gana? paso de los 100, pero unas veces llega a 200 otra baja a 120 otra vez sube.....etc
#85 Si el server es tick 100 lo suyo es que tengas el cmdrate a 100 y el updaterate a 100. Y el rate, con tenerlo a 80000 te aseguras de que no vas a tener problemas por tener un margen bastante amplio.
Pero ya te advierto que lo de dar o no dar no depende solo de ti sino de la configuración del resto de jugadores y del propio server.
#86 #88 El tema del lerp ya está explicado en el apartado de interpolación. Copio y pego:
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.
La recomendación general es que si tienes una conexión decente y tanto server como clientes en el server van bien que tengas el cl_interp_ratio a 1. Si no es el caso, a 2.
En cuanto a los fps, si el feedback sensorial que te produce el tenerlo limitado a 300 te resulta más agradable que el tenerlos limitados al tickrate del server pues déjalo así. No hay problema.
