Wersja z 13:31, 6 lip 2007

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 (tłumaczenie by _KaszpiR_ http://nvt.prv.pl )

Artykuł był najpierw dostępny ogólnie na Gotfrag. Następnie stal sie tzw Primie - czyli widocznym tylko dla zarejestrowanych. Cóż, ale http://google.com przeszło przez niego i zrobiło cache - dlatego bez obrazka, ale liczy sie treść.

A ja pozwoliłem sobie to przetłumaczyć, ale bez zbytniego lania wody zostawiając esencje. Dodatkowo trochę zmieniłem układ aby treść nie była tak poszatkowana jak w oryginale - wiec opisy zmiennych/komend są razem a nie osobno (co wprowadzało w pewne zakłopotanie co poniektórych :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 częścią gry która odpowiada za protokół sieciowy itp.

Mam nadzieje, ze pomoże ci on lepiej ustawić wartości aby osiągnąć lepsze wyniki w grze, jak i usprawnić serwer.

• Notka: Komendy/zmienne zaczynające sie od sv_ czy tez sys_ są komendami/zmiennymi działającymi tylko na serwerze - dedykowanym czy tzw listen.

Wykonanie powyższych komend w konsoli u klienta zwróci ustawienia na lokalnym komputerze a nie na serwerze. Dlatego tez trzeba te komendy wpisywać albo w konsoli hlds bezpośrednio (jak jest na screen'ie itp., albo wraz z użyciem komendy rcon, albo z żzyciem rcon zastępczych komend/aplikacji działających na serwer - mam tu na myśli komendy typu amx_rcon czy cm_rcon.

Zależność miedzy komenda ex_interp a cl_updaterate jest bardzo ważna i prosimy nie czytać tylko jednego opisu, tylko przeczytać tez info o drugiej komendzie. Ogólnie przeczytaj wszystko aby mieć ogólny zarys tego, co sie dzieje jak sie bawimy kilkoma komendami na raz.

Artykuł oryginalnie był napisany dla osób o szerokopasmowym dostępie do internetu. W naszych warunkach czytaj - cos lepszego niż SDI, najlepiej Neostrada i temu podobne.

• Najpierw ogólny opis komend/zmiennych a potem szczegóły, wiec sie nie wkurzać ze 2x to samo czytacie - oryginalny artykuł był 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 równe 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 dziala na serwer - ile klient maksymalnie moze przyjąć od serwera.
• Szczegolnie uzyteczna jak serwer nie ma za dobrego lacza.
• Numer oznacz liczbe pakietow na sekunde jaka serwer moze wyslac na sekundę do klienta.
• przeważnie daje sie sv_maxupdaterate 101.

Dlatego jesli klient ma cl_updaterate 100, a serwer ma sv_maxupdaterate 50, to ten klient i tak nie dostanie wiecej niz. te 50.

Rekomendyujemy zmieniać jaeśli pozwana na to łącze serwera i jego moc procesora.

sys_ticrate

• Definiuje ile maksymalnie tików na sekundę serwer może przetworzyć. Przekłada się to nie bezpośrednio na ilość klatek na sekundą jakie wyciaga serwer.
• Domyslnie jest 100, maksymalnie 10 000.

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.

Jak nikogo na serwerze nie ma to powinenes mieć koloło 100 albo 60 fps - serwer po prsotu nic nie robi jak nikogo na serwerze nie ma, i dopiero zaczyna się grzać jak wejdzie ktoś na serwer. Więc zawsze sprawdzaj fps z graczami na serwerze.

• Czasem ta komenda nie dziala na niektorych platformach.
• Im wiekszy ticrate tym wieksze uzycie procesora.

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 stats i twoj serwer ma powyzej 100fps to znaczy ze boosting dziala i sie ciesz, inaczej szukaj innych metod poprawy dzialania sprzetu

• Zawsze sprawdz statsy kilka razy.

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.

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.

Rekomendujemy sys_ticrate 125, ale lepiej nie przekraczac 200.

fps_max

• ustawia maksymalna ilość FPS jakie ma serwer wyciągać, ale działa także u gracza, tzn jest to zarowno zmienna klienta jak i serwera. Zależy ona od sys_ticrate -im większe sys_ticrate tym większe fps_max można wycisnąć. Domyślnie serwera stara się wycisnąć 100fps przy pełnym obciążeniu. Jednakże nieraz ta wartośc spada jak serwer nie wyrabia.
• ustawiamy pewna wartość jak poniżej ( wartośc 100 jest wartością domyślną na serwerach) w server.cfg

fps_max 100

• nie opłaca się ustawiać raczej fps więcej niż 200, w rzeczywistości aktualnie zoptymalizowane binarki HLDS spokojnie wyciągają i działają ładnie na fps_max 125
• ilość fps na serwerze zależy od ilości graczy, i mozna ją sprawdzić komendą stats
• pamiętaj, że jak nikogo na serwerze nie ma albo jest jeden gracz to ilość fps będzie różnie skakać i nie osiągnie wartości 100 - dlatego ilość fps sprawdzaj najlepiej przy pełnym obciążeniu serwera.

ex_interp

• interpolacja czyli przyblizenie wartosci korzystajac z co najmniej 2 wartosci granicznych

np. srednia ocen w szkole to interpolacja .... :D

• często blokowany prze HLGuard w celu zapobieganiu nadużyciom (dośc często niesłusznie blokowany).

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
• 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!!!

Rekomendacja ostateczna ex_interp 0.1 czyli nie dotykać - wtedy HLGuard i hego blokowanie zmiennych nie będzie tak uciążliwe.

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, ew jeśli masz słabe łącze to nie więcej niż 80% twojego uploadu.

sv_maxrate

Domyslnie jest rowne 0 co nie oznacza ze jest najlepiej.

Dlaczego? sv_maxrate 0 wykryje rate kazdego gracza i bedzie sie staralo spełnic 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.

• Dodatkowo, dzięki ustawieniu wartośći sv_maxrate możemy przewidywać maksymalne uzycie łącza na miesiąc - jesli płacimy z atransfer w GB.

Rekomendujemy dlatego ustawiac sv_maxrate na 20000.

LAN

No a jak grac na LAN'ie?

organizacje typu CPL uzywaja cl_updaterate 101 gdyz to sie wiąze z jakoscia posiadanych przez nich serwerów - silne maszyny z booster'ami na bardzo dobrych łączach.

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.
• jak serwer ma wiecej fps ( np ma booster'a) to pingi sa o wiele mniejsze - przewaznie w granicy 5ms.

Wiadomo ze CPL, ESWC i WCG uzywaja serwerow z booster'ami bo ich na to stać.

Podziękowania

Podziękowania dla:

• Alfred Reynolds, Valve Software
• Yahn Bernier, Valve Software
• Zibbo, UDPSoft
• The HLDS Mailing Lists
• The http://server.counter-strike.net forums

translated from english by _KaszpiR_

9 May 2004