Wersja z 18:46, 9 sie 2006

Wstęp

Trochę stary artykuł, będę musiał go odkurzyć z debilizmów, więc się będzie zmieniał co jakiś czas.

--KaszpiR 15:52, 9 sie 2006 (CEST)

Historia

CS 1.6 Netcode Explained po Polsku (tlumaczenie by _KaszpiR_ http://nvt.prv.pl )

Artykul byl najpierw dostepny ogolnie na Gotfrag. Nastepnie stal sie tzw Prime - czyli widocznym tylko dla zarejestrowanych. Coz, ale http://google.com przeszlo przez niego i zrobilo cache - dlatego bez obrazka, ale liczy sie tresc.

A ja pozwolilem sobie to przetlumaczyc, ale bez zbytniego lania wody zostawiajac esencje. Dodatkowo troche zmienilem uklad aby tresc nie byla tak poszatkowana jak w oryginale - wiec opisy zmiennych/komend sa razem a nie osobno (co wprowadzalo w pewne zaklopotanie coponiektorych :D )

• Originally by:' Jon MellinBy, Submitted by: Jason, last updated April 7 2004 at 4:34 PM EDT Gotfrag http://www.gotfrag.net

CS Netcode Explained

Opis

W artykule zapoznasz sie z tzw. netkodem gry Half-Life, czyli ta czescia gry ktora odpowiada za protokol sieciowy itp. Mam nadzieje, ze pomoze ci on lepiej ustawic wartosci aby osiagnac lepsze wykini w grze, jak i usprawnc serwer.

Notka:

Komendy/zmienne zaczynajace sie od sv_ czy tez sys_ sa komendami/zmiennymi dzialajacymi tylko na serwerze - dedykowanym czy tzw listen. Wykonanie powyzszych komend w konsoli u klienta zwroci ustawienia na lokalnym komputerze a nie na serwerze. Dlatego tez trzeba te komendy wpisywac albo w konsoli hlds bezposrednio (jak jest na screen'ie itp., albo wraz z uzyciem komendy rcon, albo z uzyciem rcon zastepczych komend/aplikacji dzialajacych na serwer - mam tu na mysli komendy typu amx_rcon czy cm_rcon.

Zaleznosc miedzy komenda ex_interp a cl_updaterate jest bardzo wazna i prosimy nie czytac tylko jednego opisu, tylko przeczytac tez info o drugiej komendzie. Ogolnie przeczytaj wszystko aby miec ogolny zarys tego, co sie dzieje jak sie bawimy kilkoma komendami na raz.

Artykul oryginalnie byl napisany dla osob o szerokopasmowym dostepie do internetu. W naszych warunkach czytaj - cos lepszego niz SDI, najlepiej Neostrada i temu podobne.

Najpierw ogolny opis komend/zmiennych a potem szczegoly, wiec sie nie wkurzac ze 2x to samo czytacie - oryginalny artykul byl bardziej poszatkowany.

Ogólnie o zmiennych

cl_cmdrate

• definiuje ile maksymalnie pakietow moze wyslac klient (tzn. ty, graczu ze swojej maszyny) do serwera.
• numer oznacza liczbe pakietow na sekunde

Oczywiscie wiecej znaczy lepiej - szybciej serwer zareaguje na twoje reakcje. Traktuj to mniej wiecej tak - im wieksza wartosc tym mniejszy poslizg pomiedzy nacisnieciem fire a wyslaniem pakietu.

Jak masz dobre lacze i siedzisz na laczu sam to spoko mozesz zwiekszyc. Jak wspoldzielisz z kims lacze (np. neo na 2 osoby) to zbyt wysokie wartosci u obu graczy beda powodowac nagle lagi i ping spike. Warotsc maksymalna zalezy tu od tego jaki masz upstream do provider'a - czyli ile mozesz wyslac w internet.

W idealnym przypadku ta komenda powinna sie rownac liczbie fps serwera!!! a nie klienta. Jak wyslesz wiecej pakietow to serwer je po prostu zignoruje bo nie bedzie wyrabiac. Tak wiec za wysokie wartosci nie zaszkodza ale tylko beda marnowac twoje lacze :D Rekomendujemy cl_cmdrate rowne fps serwera lub troche wieksze

Dlatego na serwerach linuksowych czesto jest 50 a na widowsowych 70 oczywiscie jak serwer ma wiecej fps to walimy 100 i sie cieszymy

cl_updaterate

• podobna do poprzedniej komendy ale dziala w odwrotnym kierunku.
• numer definiuje maksymalna liczbe pakietow na sekunde jaka ty mozesz otrzymac od serwera.
• wiecej znaczy lepiej ale tez zwieksza uzycie lacza.

traktuj to jak efekt blyskawicy - ktos strzela to nastepuje blysk (widoczny dla serwera natychmiast), jednakze ty jestes nastawiony na grzmot. im wieksza wartosc tym szybciej do ciebie grzmot dojdzie (wiem wiem, lopatologicznie...)

• Po prostu szybciej bedziesz mogl zareagowac.
• Dodatkowo daje to dokladniejsze informacje o rzeczywistym polozeniu przeciwnikow, trafien po kulach itp.

• Wartosc maksymalna zalezy od twojego downstream'u czyli jak szybko mozesz zasysac od provider'a.

Przewaznie ta wartosc (mam na mysli downstream) jest 4x wieksza od twojego upstream'u Dlatego czasem cl_updaterate jest wiekszy 4 razy od cmdate

• Minimalna wartosc jest 10 (dlatego ex_interp ma 0.1, patrz nizej)

Kiedys myslano ze cl_updaterate trza walnac na 101 i zjezdzac w dol. z wartosciami az bedziemy mieli w miare niski i zadowalajacy choke (prawie zero ale moze byc 2...3) choke widac na net_graph 3

Jednak caly system cl_updaterate jest bardziej zlozony. np. serwery CAL daja sv_maxupdaterate 101 wiec normalnie kazdy by se tyle dal na kliencie. w teorii jest to poprawne jednak praktyka sie tu rozmija.

Wiekszosc serwerow nie wyciaga 100fps aby obliczyc te wlasnie 100 updaterate na sekunde. oznacza to ze nie ma szans aby serwer tyle wyslal w rzeczywistosci.

Pomyslisz - walne se 101 updaterate i tak czy siak tyle max pakietow dostane.

Jak u siebie dasz cl_updaterate 101 to ex_interp bedzie 0.009ms - spodziewa sie gra ze bedziesz mial pakiety co 9ms i wszystko bedzie cacy. Jednakze serwer ma 50 fps czyli maksymalnie pusci 50 pakietow!!! tak wiec 2 razy mniej. Co sie stanie? Pakiety przychodza za rzadko i gra nie ma z czego interpolowac polozenia graczy - masz efekt skaczacych modeli. No dobra. dajmy na to ze zjade na 70 - efekt skaczacych modeli spadnie. Oczywiscie idealnie jak bedziemy mieli cl_updaterate 50 - wtedy iterp bedzie 0.02 i modele nie powinny az tak skakac (tylko z rzadka z powodu lagow)

• Poniewaz klient bez rcon'a nie ma jak sprawdzic ile serwer ma fps i se dobrze dobrac te zmienna, trzeba zgadywac.

Na szczescie mozna to zrobic doswiadczalnie w prostu sposob. 1. zacznij z cl_updaterate 101, ex_interp 0 2. zjezdzaj z cl_updaterate w dol. (mniej wiecej o 10 ) az zauwazysz ze modele az tak bardzo nie skacza. (tylko z rzadka z powodu zmiany pinga, lagow itp.)

Oczywiscie "bardzo nie skacza" to kwestia gustu. Dopoki ex_interp = 1/cl_updaterate modele beda na wioch rzeczywistych miejscach.

Oznacza to ze kazdy serwer bedzie mial swoje wlasne ustawienia cl_updaterate zalezne od ilosci graczy/lacza/fps - po prosu ile w danej chwili serwer moze z siebie wycisnac. Nie bojmy sie zejsc z wartosciami ponizej updaterate 50 bo tak czy siak interpolacja bedzie dzialac.

No dobra, ktos pomysli, ale ja wezme updaterate 20 i bede szedl w gore. No to nie jest dobry pomysl bo ex_interp = 1/cl_updaterate. Jak mamy 20 to ex_interp = 1/20 = 0.05 a jak zwierzymy na 50 to mamy ex_interp = 1/50 = 0.02 a ex intern 0.05 > 0.02 a H-L domyslnie nie zmniejsza sam z siebie interna. wtedy musisz wystukac za kadmy razem ex_interp 0 recznie aby obliczyc go.

tak wiec widac ze istnieje zaleznosc pomiedzy serwer fps, cl_udpaterate i ex_interp 0 razem. najlepiej miec updaterate rowny fps serwera a ex_interp 0

Rekomendacja: cl_updaterate rowny fps serwera i nie wiekszy od sv_maxupdaterate.

Koncowa notka: wiele serwerow uzywa sv_maxupdaterate 30 tak wiec cl_updaterate 30 bedzie wtedy wartoscia najlepsza w takiej sytuacji.

sv_maxupdaterate

Jak cl_maxupdaterate ale zdziala na serwer - ile klient maksymalnie moze przyjac od serwera. Szczegolnie uzyteczna jak serwer nie ma za dobrego lacza. Numer oznacz liczbe pakietow na sekunde jaka serwer moze wyslac. sv_maxupdaterate specifies the maximum number of packets per second a server is allowed to send. Dlatego jesli klient ma cl_updaterate 100, a serwer ma sv_maxupdaterate 50, to ten klient i tak nie dostanie wiecej niz. te 50.

sys_ticrate

Definiuje ile maksymalnie klatek na sekunde moze wyciagnac serwer. Domyslnie jest 100, maksymalnie 10 000 :D Po co to komu? Miedzy innymi wiecej fps daje ci lepsze poczucie gry. Serwery normalnie maja okolo 50fps na linuksie i 64 na widowsach - ale czasem spada to do 20-30 to juz slabo. Dobre serwery maja tak ustawione ten ticrate aby fps sie wahalo w granicy 150-180 fps(tzn. ogolnie do 200fps) Wiecej i tak ci nic nie da bo nie zauwazysz.

Czasem ta komenda nie dziala na nieskorych platformach. dodatkowo im wiekszy ticrate tym wieksze uzycie procka. Czasem na mapach de_inferno i de_aztec uzycie procka skacze czasem do szalonych wartosci - ale to mowie - czasem. Oczywiscie najlepiej aby miec w miare stabilny poziom fps - bo skoki z 100 do 500 i po chwili znowu na 100 nie sa przyjemne i wszystko raczej dziala gorzej - to zalezy od hardware'u Wiec lepiej aby miec mniej ale z mniejszymi fluktuacjami.

Jak masz dostep do rcon to mozesz sprawdzic aktualne fps na serwerze wpisujac

rcon stats

Aby sprawdzic jakiego kopa dostanie serwer na chwile wlacz rcon sys_ticrate 10000 Jest teraz sprawdzisz rcon status i twoj serwer ma powyzej 100fps to znaczy ze boosting dziala i sie ciesz, inaczej szukaj innych metod poprawy dzialania sprzetu

Zawsze sprawdz statusy kilka razy

ex_interp

interpolacja czyli przyblizenie wartosci korzystajac z co najmniej 2 wartosci granicznych np. srednia ocen w szkole to interpolacja .... :D

Czemu to sluzy? W idealnym ustawieniu mialbys nieskonczona liczbe synchronizacji i bys wiedzial gdzie jest przeciwnik. Oczywiste internet na to ci nie pozwoli i dostaniesz tylko skonczona liczbe pakietow. Najlatwiej tu jest sie posluzyc interpolacja kola. Masz kolo - idealny ksztalt rzeczywisty. Ale ty masz skonczona liczbe kresek do wykorzystania. tak wiec wpisujesz wielokat foremny aby jak najbardziej upodobnic go do kola Z daleka patrzac nie zauwazysz roznicy czy masz wielokat o 100 bokach czy kolo no ale jak usiadziesz z lupa to sie kapniesz :D Przewaznie w CS mamy wielokat o 20 bokach no i tu widac ze nie zawsze pozycja gracza jest pozycja realna gracza.

Na szczescie do gry to starcza gdyz dziala interpolacja - wszelkie pozycje gdzie nie masz informacji gdzie sie znajduje gracz sa interpolowane. Po prostu modele na ekranie nie skacza, tylko poruszaja sie plynnie bo sa interpolowane bazujac na pakietach jakie otrzymujesz od serwera.

oznacza tu przedzial czasowy do wykorzystania przez gre - jako ulamek sekundy. Domyslnie jest to maksymalnie 0.1 Czyli 100 ms - oznacza to ze jesli nie dostaniesz pakietu o polozeniu gracza w ciagu 100ms to H-L bedzie Obliczal gdzie on sie znajduje.

normalnie ex_interp powinien byc rowny lub troszke wiekszy od 1/cl_updaterate

natomiast niektorzy rekomenduja ex_interp 0 wtedy H-L sam obliczy te wartosc i ci powie ze "ex_interp forced to msec" tylko ze jest problem 1. jak zmieniasz jakkolwiek cl_updaterate to potem musisz wywolac ex_interp 0 aby to obliczyl 2. jak masz ex_interp 0 to modela moga zaczac skakac - bo pakiety sie spozniaja, to normalne.

maksymalnie ex_interp ma 0.1 czyli 100 milisekund - to jest duzo najczesciej jak masz cl_updaterate 20 to masz ex_interp 0.05 oczywiscie im wiekszy update tym mniejsza liczba

niektorzy tylko rekomenduja operowanie cl_updaterate i zostawianie ex_interp'a w spokoju aby sam sie kalkulowal... no ale jestesmy na polskich laczach...

czasem wartosci ex_interp ponizej 1/cl_updaterate nie da sie ustawic. czasem wartosci powyzej 1/cl_updaterate sa uwazane za exploit gdyz powoduje z musisz strzelac za rzeczywistym modelem

dlatego jest efekt spozniony headshot'ow - koles przebiegl, ty strzeliles gdzie on "byl" i dostal heda, a krew sika z pustki

ja sugeruje popatrzec ile ex_interp 0 wyliczy i potem dodac recznie +0.01 np. cl_updatertae 20 ex_interp 0.05 dodajemy i mamy ex_interp 0.06 efektu spoznionych hedow nie powinno byc tak wiele i modele nie powinny az tak bardzo skakac - no chyba ze lagi :D natomiast modele nie biegaja na tyle wczesnie aby inni uwazali ze oszukujesz. ja uwazam ze dodanie 0.01 to nie jest expliotem bo netcode nie jest idealny, szczegolnie jak na polskie warunki

moim zdaniem exploitem jest jak gracz ma cl_updaterate 101 i wtedy powinien miec ex_interp 0.009 (no powiedzmy 0.01) a w rzeczywistosci uzywa ex_interp 0.1 czyli 10x wiekszego!!!

ostateczna rekomendacja ex_interp 0

rate

jest to ile bajtow mozesz przeslac do serwera. maksymalnie jest 20000, bo wyzej H-L nie wyciagnie. standardowo jest chyba 5000 albo i mniej ale np. clanbase uzywa 9999. rekomendujemy zatem albo 9999 albo 20000 jesli serwer pozwala.

sv_maxrate

domyslnie jest rowne 0 co nie oznacza ze jest najlepiej. Dlaczego? sv_maxtrate 0 wykryje rate kazdego gracza i bedzie sie staralo spelnic wymogi gracza. teraz zalozmy ze H-L daje mozliwosc dania rate powyzej 20 kafli, a jakis gracz ma fantazje i walnie ostra wartosc np. 9999999999 (kosmiczna liczba) serwer w tym przypadku probowalby wypchac te kosmiczna ilosc danych do tego gracza i tylko by marnowal lacze do tej osoby bo i tak tyle nie wysle a reszta bedzie lagowana bo nie dostanie nic. dlatego lepiej jest ustawiac sv_maxtrate na 20000. moze sie wydawac ze to nie ma sensu ale chyba mozna sie po valve spodziewac wszystkiego od czasow steam.

sys_ticrate

znajdowanie optymalnej wartosci wymaga troche eksperymentow. najpierw sprawdz czy serwer jest boots'owany, bo inaczej nic ci to nie da. pamietaj ze podnoszenie fps powyzej 200 jest zbyteczne ze wzgledow mozliwosci samej gry i laczy internetowych. dodatkowo wyciskanie za duzo fps na maszynie ktora ma kilka serwerow hlds na sobie jest niekorzystne dla innych serwerow spowoduje to tylko pogorszenie gry na obu serwerach bo procesor nie bedzie wyrabial. nie zapominaj ze czesto na serwerach dziala tez www , mail i ftp.

dodatkowo nie kazdy wie ze czasem serwer fps wskazuje na niektore tylko wartosci albo po prostu dziala na innych np. na jednej z maszyn zaobserwowano ze fps ukladaja sie tak: 85, 102, 128, 170, 256 ... i zadnych fps (liczb) miedzy nimi.

wiec jak damy w tym przypadku sys_ticrate 100 to serwer bedzie dzialal na predkosci nizszej ni zapodana w typ wypadu bedzie to 85 fps

dlatego lepiej jest dawac sys_ticrate zwiekszone o 20 do 50 fps niz. te ktora chcesz osiagnac np. moze sie zdarzyc ze masz sys_ticrate 150 a serwer bedzie wyciagal tylko 128 fps.

rekomendowane: sys_ticrate 110 - 180 w zaleznosci od mozliwosci twojego sprzetu.

LAN

No a jak grac na LAN'ie organizacje typu CPL uzywaja cl_updaterate 101 gdyz to sie wiaze z jakoscia serwowanych przez nich serwery - silne maszyny z booster'ami. aby latwo sie przekonac czy serwer na lanie jest z booster'em - popatrz na ping graczy z lan'u. normalny serwer bez booster'a na 60-65 fps powoduje ze gracze maja pingi powyzej 15ms natomiast jak serwer ma wiecej fps i ma booster'a to pingi sa o wiele mniejsze - przewaznie w granicy 5ms. Wiadomo ze CPL, ESWC i WCG uzywaja serwerow z booster'ami.

Podziękowania

Special thanks to: Alfred Reynolds, Valve Software Yahn Bernier, Valve Software Zibbo, UDPSoft The HLDS Mailing Lists The server.counter-strike.net forums

translated from english by _KaszpiR_ 9 May 2004