Setari pentru jucatori

[r00t]

Acest articol descrie ce setari sunt optime pentru jucatorii de pe serverele de Counter Strike 1.6 si Condition Zero Informatiile au fost obtinute din documentatia oferita de Valve, din articolul scris de Jon Mellin pentru GotFrag.com, din comentariile facute de Cameron Lloyd, din codul sursa al unei versiuni alpha a jocului Half Life 2 si bineinteles in urma unor numeroase teste.
Ghid rapid

Pentru cei care nu sunt interesati de prea multe detalii tehnice setarile care pot fi folosite sunt specificate in urmatorul tabel. Valorile optime sunt recomandate pentru cei care joaca just for fun si care nu au pretentii prea mari, in timp ce valorile din coloana PRO sunt recomandate pentru pentru cei care sunt mai pretentiosi si care au chiar si un al 7-lea simt dezvoltat special pentru acest joc, insa bineinteles trebuie sa aiba si o conexiune pe masura

Comunicatia client & server

Serverul comunica cu un client prin pachete UDP, numarul acestora depinzand atat de setarile serverului cat si de ale clientului, variind din principiu intre 20 si ~200 pe secunda. Dimensiunea pachetelor este destul de mica, avand in medie 30-50 de bytes in cazul celor trimise de clienti catre server si 250-300 de bytes in cazul celor trimise de server catre clienti. De notat faptul ca doi clienti nu comunica niciodata direct intre ei.

CVAR-ul cl_updaterate


Specifica numarul de update-uri pe secunda cerute de catre un client de la server.
Aceste update-uri contin informatii despre ce se intampla pe server, in special despre coechipieri si adversari, motiv pentru care este de preferat ca numarul lor sa fie cat mai mare posibil. Valoarea minima este 10, adica un update odata la aproximativ 100ms, in timp ce valoarea maxima acceptata de engine-ul Half Life este 102, ceea ce inseamna un update la aproximativ 9.8ms. Cu cat valoarea folosita este mai mare cu atat clientul obtine de la server mai repede informatii despre pozitia adversarilor lui, ceea ce in principal inseamna ca diferenta intre ce vede pe monitor si ce "stie" serverul este mai mica.


Un server poate restrictiona numarul de update-uri care pot fi cerute de clienti folosind CVAR-urile sv_minupdaterate si sv_maxupdaterate


In urma unor teste efectuate a rezultat ca engine-ul Half Life nu poate trimite exact numarul de update-uri cerute de clienti, in cazul in care se cer 100 fiind trimise doar ~92, acest lucru fiind valabil chiar daca la server nu mai este conectat alt jucator iar hardware-ul folosit este unul foarte performant.



Din pacate la ora actuala un client nu poate afla usor numarul real de update-uri primite de la server, ceea ce poate duce la probleme legate de hit registration. De exemplu un client care joaca cu cl_updaterate 100 si ex_interp 0.01 pe un server care nu trimite mai mult de 30 update-uri (fie pentru ca nu este capabil de acest lucru, fie pentru ca sv_maxupdaterate este setat la 30) se va astepta sa primeasca un update odata la ~10ms, insa in realitate va primi unul odata la ~34ms, ceea ce duce la extrapolare, adica predictie privind pozitia coechipierilor si a adversarilor pe harta.
CVAR-ul cl_cmdrate

Specifica numarul de update-uri pe secunda pe care clientul doreste sa le trimita la server, fiecare update continand din principiu un "snapshot" privind tastatura si mouse-ul acestuia.
Ceea ce putini stiu este ca numarul propriu zis de update-uri trimise la server in fiecare secunda este limitat si de catre numarul de FPS-uri pe care le are clientul, deoarece nu se poate trimite catre server decat cel mult un update in timpul unui frame. De exemplu daca un client are maxim 60 de FPS-uri atunci el va trimite catre server maxim 60 de update-uri, dar nu mai mult de valoarea specificata folosind cl_cmdrate, ceea ce inseamna ca teoretic limita este data de maximul dintre aceste 2 valori:

"numar update-uri reale trimise = minimul dintre numar FPS-uri si cl_cmdrate"

Testele pe un server WAR au aratat ca este recomandat ca acest CVAR sa fie setat la o valoare putin mai mare decat numarul maxim de FPS-uri, in caz contrar vor exista frame-uri in care nu se trimite nici un update la server, lucru care bineinteles trebuie evitat. De exemplu este o diferenta foarte mare intre cl_cmdrate 100 si cl_cmdrate 101 in cazul unui client care are maxim 100 de FPS-uri, in primul caz trimitandu-se in realitate la server doar 72-73 de update-uri in fiecare secunda, pe cand in al doilea caz numarul acestora fiind 98-99. Acelasi lucru este valabil si daca clientul are 60 de frame-uri pe secunda, in cazul cl_cmdrate 60 trimitandu-se intre 33 si 34 de update-uri la server, pe cand pentru cl_cmdrate 61 numarul de update-uri trimise fiind aproximativ 59. In concluzie:

"cl_cmdrate trebuie sa fie setat la o valoare mai mare sau egala decat fps_max + 1"

In urmatoarea imagine se poate observa clar diferenta dintre cl_cmdrate 101 si cl_cmdrate 100 pentru 100 de FPS-uri (cl_updaterate fiind setat la 102 si ex_interp setat la 0.01), in al doilea graph fiind vizibile multe puncte rosii in partea de jos, ceea ce inseamna frame-uri in care nu s-a trimis un update catre server:

In cazul celor care au mai mult de 100 de FPS-uri (developer 1, fps_max setat la o valoare mai mare de 100, hardware corespunzator) este recomandata o valoare putin mai mare decat numarul maxim de FPS-uri, sau chiar o valoare absurda, gen 999.

CVAR-ul rate

Este un CVAR devenit intr-un fel inutil in aceste zile, permitand clientilor sa limiteze traficul facut intre ei si server, valoarea minima permisa fiind 1000 si valoarea maxima permisa fiind 20000 (valori hardcodate in engine-ul Half Life), insa un server poate adauga restrictii suplimentare folosind CVAR-urile sv_minrate si sv_maxrate.

Din codul sursa al Half Life 2 se pare ca acest CVAR este luat in calcul doar in ceea ce priveste informatiile trimise de server catre client si, logic, cu cat valoarea folosita este mai mare cu atat serverul poate trimite mai multa informatie catre client.
CVAR-ul ex_interp

Specifica intarzierea cu care informatia primita de la server este vizibila si pe monitorul unui client, valorile posibile fiind intre 0.009 (o intarziere de 9ms) si 0.1 (o intarziere de 100ms), insa valoarea minima care poate fi folosita de catre un client depinde de numarul de update-uri cerute de la server, fiind calculata folosind forumula 1 / cl_updaterate (adica intervalul intre 2 update-uri primite de la server). De exemplu pentru cl_updaterate 30 se poate folosi ex_interp 0.033, pentru cl_updaterate 50 se poate folosi ex_interp 0.02, in timp ce un jucator care cere 100 de update-uri de la server va putea folosi ex_interp 0.01.

De notat ca valoarea 0 pentru ex_interp este una speciala, engine-ul Half Life folosind valoarea minima posibila calculata conform formulei descrisa mai sus.
Aceasta intarziere este necesara pentru engine-ul grafic, fiind prezenta chiar si in cazul in care serverul este pornit de catre unul din clienti (optiunea New Game din meniul principal), altfel animatia avand "probleme" daca pozitia celorlalti jucatori si a altor obiecte de pe harta ar fi actualizata imediat ce informatia ar fi primita de la server.
Este logic ca o intarziere mai mica (o valoare ex_interp mai mica) este in avantajul unui client, in timp ce o intarziere mai mare (ex_interp mai mare) reprezinta un dezavantaj. De exemplu un jucator care foloseste ex_interp 0.01 (o intarziere de 10ms) are teoretic un avantaj de 90ms fata de un jucator care foloseste ex_interp 0.1 (o intarziere de 100ms), acest lucru bineinteles in cazul in care cei 2 jucatori au acelasi timp de raspuns (ping).
O descriere mai detaliata a acestui CVAR este facuta de Valve in documentatia pentru engine-ul Source, informatiile oferite fiind in mare parte valabile si pentru engine-ul Goldsource (folosit de jocurile Counter Strike 1.6 si Condition Zero).
fps_max & fps_modem

Aceste CVAR-uri sunt folosite pentru a limita numarul maxim de frame-uri pe secunda (FPS) pe care le poate avea un client.
Teoretic fps_modem este un CVAR vechi care n-ar trebui sa mai fie suportat de catre ultima versiune a engine-ului Half Life, insa suprinzator se pare ca la ora actuala are chiar prioritate fata de fps_max, exceptand cazul in care este setat la valoarea 0. De exemplu pentru fps_max 100 si fps_modem 30 engine-ul va limita numarul de FPS-uri la valoarea 30, in timp ce pentru fps_max 30 si fps_modem 60 engine-ul va limita numarul de FPS-uri la 60, ceea ce inseamna ca practic CVAR-ul fps_max este folosit doar daca fps_modem este 0.


De notat ca in mod normal engine-ul Half Life nu permite un numar de FPS-uri mai mare decat 100, exceptand cazul in care modul developer este activat (developer 1), ceea ce nu este recomandat.

[D3vIlBl@cK]

mersi chiar foarte folositoare