














En el archivo pbsv.cfg, tenemos la línea pb_sv_guidrelax que debería estar configurada a 0, para no permitir guid's duplicadas, ni guid's erroneas ni ip's "malas". Es decir, todas las restricciones sobre guid's e ip's activadas.
Bien, el bug lo que produce es que tras rotación del primer mapa, cambio de mapa o reinicio de mapa, el valor de pb_sv_guidrelax cambia de 0 a 7 y deshabilita todas las restricciones.
Para solucionar dicho bug, deberemos añadir la siguiente rutina en el archivo pbsv.cfg del punkbuster de nuestro/nuestros servidores, para que vaya restableciendo el valor por defecto a 0
pb_sv_task 60 300 pb_sv_guidrelax 0
pero , logicamente de primeras a un server original no puede entrar otro tio con la misma key basciamente porke esta en uso :S , i a otro server original tmpko
la guid va ligada a la key no? quiero decir, a no ser que no te dupliquen la key , con lo cual es lo que dice shocki, no te pueden duplicar tu guid. A mi entender es eso :S
Si teneís razon, así debería ser pero es un bug del pb del CoD4.
He visto en servidor CoD4 original, en streaming con GV, dos "conocidos" jugadores con la misma guid, misma ip y distinto puerto y que son hermanos....y que hay algun hilo sobre ellos en la sección PB de CoD2.
muy interesante la aportacion.
gracias
Exacto, muy interesante la aportacion, pero por muy original que sea, si pones ''pb_sv_guidrelax 7'' pueden entrar dos guids (keys) iguales.
El tema de si pasa con streaming o no tb sería interesante..
igual, eso no interfiere en el Streaming.....
te haré un matiz, en streaming seguro, que que requiere del archivo pb.cfg que incorpora ese comando. En servers sin streaming, depende si lo han configurado con la cfg del pb o no.
#5 Pasa con streaming, si. Streaming con GV.
El problema parece que se remonta en el tiempo desde la salida del CoD4, Noviembre del 2007 :
Foros oficiales de IW, en el último post evenbalance dice que está trabajando en el problema
Y ya en Junio del 2008, aún estaban igual que ahora, como he podido comprobar :
Hilo sobre el tema en los foros de PBBans
en mi servidor se sigue quedando en 7, esta en promod con gv, puede ser por eso.....
Un saludo
#8 Si has añadido la rutina pb_sv_task 60 300 pb_sv_guidrelax 0 en pbsv.cfg, solo te cambia el valor a 7 tras cada cambio de mapa, tal como comentamos en #0, en el momento que se ejecuta otra vez la rutina el valor queda en 0 otra vez.
Abre el archivo console_mp.log y vas buscando los distintos guidrelax, casi siempre los verás a 0, solo depués de cambio de mapa pasa a ser 7 y en el momento que vuelve a ejecutarse la rutina el valor se restablece a 0. Y así hasta siguiente cambio de mapa.
ok lo probare , gracias
Un saludo
No le des vueltas Volde.
Se trata de una rutina del PB que en cada mapa, como se reinicia el Pb se resetean los valores igualmente.
Ademas, el archivo pbsv.cfg, es reescrito en cada cambio de mapa por el valor conceptual del PB.
Con esta linea: pb_sv_task 60 300 pb_sv_guidrelax 0 solo haces lo que ya el Pb esta haciendo, que al cambio de mapa cambie el valor, solo que lo alteras para que pase al que deseas.
como solución temporal puede ser practica, pero conlleva un sacrificio de consumo del server bastante alto, ya que ese cambio es logueado dos veces por mapas, una al principio y otra al final antes del cambio al siguiente.
En mi opinión, es un cambio introducido en la ultima actualizacion del PB, al objeto de controlar las guids que "ciertos personajes" dedicados al "arte del cheteo" proporcionan a sus "clientes" y creo que Pb esta en su linea, introduciendo este cambio para cazar a estos "personajes".
En cualquier caso, la linea exacta para obetener el guidrelax que deseas seria esta:
pb_sv_task 60 300 pb_sv_guidrelax 0 ( la que posteaste)
Asi siempre la tendras a cero.
Saludos!
Nas Mikel
No, no viene de la última actualización de pb, mira los links en #7
En el primer link, mandan un tiket a evenbalance y éstos responden que están trabajando en ello para solucionarlo "cuanto antes".... Septiembre de 2008 y aún seguimos igual.
Y si en cada cambio de mapa se resetean los valores, éstos deberían tomar el valor que yo tengo configurado en mi pbsv.cfg y que no es 7. Mi línea es : pb_sv_guidrelax 0.
Se nos puso la mosca detrás de la oreja, en una war amistosa, en un server del rival, el rival contaba con dos "infils" con la misma guid. Pensamos que era cuestión de tiempo que el pb los kikeara....no pasó nada.
Luego, vimos a los dos personajes, en uno de nuestros servers en streaming con GV, con la misma guid jugando tan ricamente. Configuramos el pb_sv_guidrelax a 0, aún así seguian campando a sus anchas con sus dos guids idénticas.
La verdad, el asunto nos hubiera pasado por alto en cualquier otra circunstacia. No nos pasó por alto, ya que son jugadores que vienen "marcados" por sus debaneos cheteros en el CoD2, eso fué lo que nos llamó la atención.
Apartir de aquí empezamos a investigar, sobre los "misterios" del pb_sv_guidrelax en el CoD4.
Otra cosa que no esta haciendo la gente es agregar los comandos del pb, que vienen en el promod que son estos:
pb_sv_cvar sc_enable in 0
pb_sv_cvar sm_enable in 0
pb_sv_cvar r_dlight_limit in 0
pb_sv_cvar dynent_active in 0
pb_sv_cvar snaps in 30
pb_sv_cvar cl_maxpackets in 100
pb_sv_cvar rate in 25000
pb_sv_cvar cg_nopredict in 0
pb_sv_task 60 300 pb_sv_guidrelax 0 <---- este lo he agregado yo, tal como lei el post me parecio buena idea
Dichos comandos, tiene que agregarse en el archivos pbsv.cfg del pb
Los servidores en cuestión, los que han campado los de idéntica guid son pam y rsm de Zeroy. Aunque podría ser en cualquier server, con cualquer mod o sin mod.
El de promod lo tenemos así mismo, tal como posteas iMax y con la línea de la rutina en questión.
Aquí el script de punkbuster para Promod a añadir tal como indicas en pbsv.cfg
mikel evidentemente lo que propone voldemort es un "apaño", pero es lo que hay para resolver las chapuzas del pb, pero no hay nada mejor asi que es recomendable.
Yo tambien creo que la idea es buena, si es pb no hay una cosa bien, tendremos que forzarlo a que lo haga.
La cosa va funcionando correctamente, en sv_violations.log :