[DUDA] Procesador de comandos
#1

Hola a todos, vн que mi sv corre re-lag y quiero saber que procesador de comandos es el mбs rбpido y eficiente... me dijieron que el ycmd, pero necesito estar seguro ya que solo uso strcmp xD

Si es asн, como se usan los comandos? gracias )
Reply
#2

no va a correr re-lag por tu procesador de comandos, porque la diferencia entre uno y otro no es mas que 2 ms es decir, 0,002 segundos. Debe haber otra cosa que estй afectando en cuanto al rendimiento
Reply
#3

Capaz la cantidad de maps, o fijate que no tengas un bucle infinito.
Reply
#4

A mi gusto, es el y_commands ("ycmd") en uso conjunto a sscanf2, ambos de ******... Igualmente, strcmp no es un procesador de comandos, es mбs bien una funciуn que tiene como funciуn (lo describн bien) la de comparar cadenas.
Reply
#5

No pueden ser los mapas los que den lag, las razones mas probables son, exeso de timers (mas de 3 ya comienza a haber lag notorio) o funciones muy cargadas en las callbacks que se llaman siempre (por ejemplo OnPlayerText), tambien puede ser por el abuso exesivo de OnPlayerUpdate, y tambien puede ser por el host, recuerda que debes tener muchos recursos y una buena coneccion.

pd; si aun quieres un procesador de comandos, te recomiendo el <a_cmd> que postee, es muy bueno o tambien el zcmd.
Reply
#6

En cuanto al lag, como dijo SD, son varias razones, empezando con los timers y luego con la callback OnPlayerUpdate, la cual es llamada 30 veces por segundo por cada jugador. Imaginбte si OnPlayerUpdate tiene cуdigos extensos para actualizarse, y tenйs un servidor con 200 jugadores conectados al mismo tiempo... 30*200 = 600 veces serнa llamada la callback por segundo...

Te recomiendo varias cosas, como por ejemplo, usar lo menos posible OnPlayerUpdate, el guardado y cargado de datos puede ser mediante funciones, por ejemplo, GuardarCuenta y CargarCuenta, GuardarCuenta serнa llamada en la callback OnPlayerDisconnect, para que al desconectarse el jugador, se guarde su cuenta, tambiйn en OnGameModeExit para los casos en los que se caiga el servidor, con un bucle foreach sуlo para jugadores, y CargarCuenta se utilice en la callback OnPlayerConnect, para cargarle la cuenta al jugador, de йsta forma se estarнan guardado y cargando los datos sуlamente cuando йsto se precisa, en lugar de guardarlos constantemente en OnPlayerUpdate, que en lugar de guardarlos se actualizan. Podrнas usar el include fixes, el include fixes2 junto con su plugin, para poder reparar varios errores en los timers, ademбs de complementarlo con el YSI/y_timers, serнan timers perfectos.. Podrнas usar la funciуn GetPlayerTicketCount en algunos casos, para disminuir los timers, podrнas usar un sуlo timer para funciones que utilicen timers de iguales milisegundos.. En cuanto al guardado de datos, te recomendarнa MySQL R7. Y recuerda, los bucles serнa mejor usarlos con foreach, ya que sуlo es especнfico para jugadores si asн lo especificas, y se colapsa menos el servidor. En cuanto a los comandos, claramente, es mejor usar algo como YSI/y_commands (YCMD) en conjunto con el plugin sscanf con su respectivo include sscanf2, y tambiйn en conjunto con otras librerнas YSI, que mejoran el rendimiento. Serнa indispensable utilizar tambiйn el plugin e include streamer de Incognito, por el tema de los objetos..

Y como siempre, trata de optimizar, como usar switch's con condicionantes case's en lugar de usar condicionantes if y else if.

Teniendo por ejemplo un servidor con йstas caracterнsticas y un buen host, habrнa una mejor conexiуn.

En cuanto a preferencias, te recomendarнa no trabajar con include's como OSRP, si bien, se trabaja "algo" mбs ordenado, a veces uno se pierde, lo ъnico que usarнa como include serнa uno donde se guardarнan todos los mapeados (RemoveBuildingForPlayer, CreateObject/CreateDynamicObject, etc).
Reply
#7

Quote:
Originally Posted by spell
Посмотреть сообщение
no va a correr re-lag por tu procesador de comandos, porque la diferencia entre uno y otro no es mas que 2 ms es decir, 0,002 segundos. Debe haber otra cosa que estй afectando en cuanto al rendimiento
con strcmp entre mбs comandos mбs lag puede haber, en especial si el usuario usa exactamente el ultimo comando del cуdigo
Reply
#8

Quote:
Originally Posted by Josstaa
Посмотреть сообщение
con strcmp entre mбs comandos mбs lag puede haber, en especial si el usuario usa exactamente el ultimo comando del cуdigo
o si se usa un comando que no exista igual tendrб que recorrer hasta el final de la callback, pero no creo que sea suficiente para causar lag.

Con respecto a los timers, lo que en realidad causa lag es el cуdigo que se ejecuta dentro de el, puedes tener mбs de 200 timers con cуdigo bien hecho y no deberia de haber lag.
Reply
#9

Quote:
Originally Posted by Daniel-92
Посмотреть сообщение
o si se usa un comando que no exista igual tendrб que recorrer hasta el final de la callback, pero no creo que sea suficiente para causar lag.

Con respecto a los timers, lo que en realidad causa lag es el cуdigo que se ejecuta dentro de el, puedes tener mбs de 200 timers con cуdigo bien hecho y no deberia de haber lag.
No. Causan LAG ambos. Aunque el "timer" no tenga contenido.

Aunque decir que 3 de estos causan LAG notorio es algo exagerado. Yo, en un servidor de 40 usuarios, cada usuario tenia 3 "timers" por lo que habian 120 "timers" y se notaba algo de LAG hasta que lo cambiй.
Reply
#10

Quote:
Originally Posted by DesingMyCry
Посмотреть сообщение
No. Causan LAG ambos. Aunque el "timer" no tenga contenido.

Aunque decir que 3 de estos causan LAG notorio es algo exagerado. Yo, en un servidor de 40 usuarios, cada usuario tenia 3 "timers" por lo que habian 120 "timers" y se notaba algo de LAG hasta que lo cambiй.
A como dices causar lag si que causa pero no es capaz de notarse mucho (hablo de +200 timers). Ahora el usuario aquн estб preocupado por solo tener 8 timers y estaba viendo la opciуn de cambiarse a y_timers por lo que lo veo que le va a ser inutil para bajar su lag, lo que tiene que hacer es optimizar mejor su cуdido dentro de los timers, OnPlayerUpdate y ver que no use sistemas de guardados lentos como dini.
Reply


Forum Jump:


Users browsing this thread: 3 Guest(s)