CS 1.6 Netcode Po Polsku

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)

Ten artykuł jest niepełny i wymaga uzupełnienia. Jeżeli jesteś w stanie - postaraj się go uzupełnić.. Pamiętaj, że nawet najmniejsza zmiana jest cenna i pomocna :)

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 się 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 się 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 - więc 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 się z tzw. netkodem gry Half-Life, czyli ta częścią gry która odpowiada za protokół sieciowy itp.

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

• Notka: Komendy/zmienne zaczynające się od sv_ czy też 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 też 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ć też info o drugiej komendzie. Ogólnie przeczytaj wszystko aby mieć ogólny zarys tego, co się dzieje jak się bawimy kilkoma komendami na raz.

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

• Najpierw ogólny opis komend/zmiennych a potem szczegóły, więc się nie wkurzać że 2x to samo czytacie - oryginalny artykuł był bardziej poszatkowany.

Ogólnie o zmiennych

cl_cmdrate

• definiuje ile maksymalnie pakietów może wysłać klient (tzn. ty, graczu że swojej maszyny) do serwera.
• numer oznacza liczbę pakietów na sekundę

Oczywiście więcej znaczy lepiej - szybciej serwer zareaguje na twoje reakcje. Traktuj to mniej więcej tak - im większa wartość tym mniejszy poślizg pomiędzy naciśnięciem fire a wysłaniem pakietu.

Jak masz dobre łącze i siedzisz na łączu sam to spoko możesz zwiększyć. Jak współdzielisz z kimś łącze (np. neo na 2 osoby) to zbyt wysokie wartości u obu graczy będą powodować nagle lagi i ping spike. Wartość maksymalna zależy tu od tego jaki masz upstream do provider'a - czyli ile możesz wysłać w internet.

W idealnym przypadku ta komenda powinna się równać liczbie fps serwera!!! a nie klienta. Jak wyślesz więcej pakietów to serwer je po prostu zignoruje bo nie będzie wyrabiać. Tak więc za wysokie wartości nie zaszkodzą ale tylko będą marnować twoje łącze :D Rekomendujemy cl_cmdrate równe fps serwera lub trochę większe.

Dlatego na serwerach linuksowych często jest 50 a na widowsowych 70 oczywiście jak serwer ma więcej fps to walimy 100 i się cieszymy

cl_updaterate

• podobna do poprzedniej komendy ale działa w odwrotnym kierunku.
• numer definiuje maksymalna liczbę pakietów na sekundę jaka ty możesz otrzymać od serwera.
• więcej znaczy lepiej ale też zwiększa użycie łącza.

traktuj to jak efekt błyskawicy - ktoś strzela to następuje błysk (widoczny dla serwera natychmiast), jednakże ty jesteś nastawiony na grzmot. im większa wartość tym szybciej do ciebie grzmot dojdzie (wiem wiem, łopatologicznie...)

• Po prostu szybciej będziesz mógł zareagować.
• Dodatkowo daje to dokładniejsze informacje o rzeczywistym położeniu przeciwników, trafień po kulach itp.

• Wartość maksymalna zależy od twojego downstream'u czyli jak szybko możesz zasysać od provider'a.

Przeważnie ta wartość (mam na myśli downstream) jest 4x większa od twojego upstream'u Dlatego czasem cl_updaterate jest większy 4 razy od cmdate

• Minimalna wartość jest 10 (dlatego ex_interp ma 0.1, patrz niżej)

Kiedyś myślano że cl_updaterate trza walnąć na 101 i zjeżdżać w dół z wartościami aż będziemy mieli w miarę niski i zadowalający choke (prawie zero ale może być 2...3) choke widać na net_graph 3

Jednak cały system cl_updaterate jest bardziej złożony. np. serwery CAL dają sv_maxupdaterate 101 więc normalnie każdy by se tyle dal na kliencie. w teorii jest to poprawne jednak praktyka się tu rozmija.

Większość serwerów nie wyciąga 100fps aby obliczyć te właśnie 100 updaterate na sekundę. oznacza to że nie ma szans aby serwer tyle wysłał w rzeczywistości.

Pomyślisz - walnę se 101 updaterate i tak czy siak tyle max pakietów dostanę.

Jak u siebie dasz cl_updaterate 101 to ex_interp będzie 0.009ms - spodziewa się gra że będziesz miał pakiety co 9ms i wszystko będzie cacy. Jednakże serwer ma 50 fps czyli maksymalnie puści 50 pakietów!!! tak więc 2 razy mniej. Co się stanie? Pakiety przychodzą za rzadko i gra nie ma z czego interpolować położenia graczy - masz efekt skaczących modeli. No dobra. dajmy na to że zjadę na 70 - efekt skaczących modeli spadnie. Oczywiście idealnie jak będziemy mieli cl_updaterate 50 - wtedy interp będzie 0.02 i modele nie powinny aż tak skakać (tylko z rzadka z powodu lagów)

• Ponieważ klient bez rcon'a nie ma jak sprawdzić ile serwer ma fps i se dobrze dobrać tę zmienną, trzeba zgadywać.

Na szczęście można to zrobić doświadczalnie w prosty sposób. 1. zacznij z cl_updaterate 101, ex_interp 0 2. zjeżdżaj z cl_updaterate w dol. (mniej więcej o 10 ) aż zauważysz że modele aż tak bardzo nie skaczą. (tylko z rzadka z powodu zmiany pinga, lagów itp.)

Oczywiście "bardzo nie skaczą" to kwestia gustu. Dopóki ex_interp = 1/cl_updaterate modele będą na swioch rzeczywistych miejscach.

Oznacza to że każdy serwer będzie miał swoje własne ustawienia cl_updaterate zależne od ilości graczy/łącza/fps - po prostu ile w danej chwili serwer może z siebie wycisnąć. Nie bójmy się zejść z wartościami poniżej updaterate 50 bo tak czy siak interpolacja będzie działać.

No dobra, ktoś pomyśli, ale ja wezmę updaterate 20 i będę szedł w gore. No to nie jest dobry pomysł 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 domyślnie nie zmniejsza sam z siebie interna. wtedy musisz wystukać za kadmy razem ex_interp 0 recznie aby obliczyć go.

tak więc widać że istnieje zależność pomiędzy serwer fps, cl_udpaterate i ex_interp 0 razem. najlepiej mieć updaterate równy fps serwera a ex_interp 0

Rekomendacja: cl_updaterate równy fps serwera i nie większy od sv_maxupdaterate.

Końcowa notka: wiele serwerów używa sv_maxupdaterate 30 tak więc cl_updaterate 30 będzie wtedy wartością najlepszą 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 się 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 się 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 działa na niektórych platformach.
• Im większy ticrate tym większe użycie procesora.

Czasem na mapach de_inferno i de_aztec użycie procka skacze czasem do szalonych wartosci - ale to mowie - czasem. Oczywiście najlepiej aby mieć w miarę stabilny poziom fps - bo skoki z 100 do 500 i po chwili znowu na 100 nie sa przyjemne i wszystko raczej działa gorzej - to zależy od hardware'u Wiec lepiej aby miec mniej ale z mniejszymi fluktuacjami.

• Jak masz dostęp do rcon to możesz sprawdzić aktualne fps na serwerze wpisując

rcon stats

Aby sprawdzić jakiego kopa dostanie serwer na chwile włącz

rcon sys_ticrate 10000

Jest teraz sprawdzisz rcon stats i twój serwer ma powyżej 100fps to znaczy że boosting działa i się ciesz, inaczej szukaj innych metod poprawy działania sprzętu

• Zawsze sprawdź statsy kilka razy.

Znajdowanie optymalnej wartosci wymaga troche eksperymentow. Najpierw sprawdz czy serwer jest boots'owany, bo inaczej nic ci to nie da.

Pamiętaj że podnoszenie fps powyżej 200 jest zbyteczne ze względów możliwości samej gry i łączy internetowych.

Dodatkowo wyciskanie za dużo fps na maszynie która ma kilka serwerów hlds na sobie jest niekorzystne dla innych serwerów - spowoduje to tylko pogorszenie gry na obu serwerach bo procesor nie bedzie wyrabial. Nie zapominaj że często na serwerach działa też www , mail i ftp.

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

Wiec jak damy w tym przypadku sys_ticrate 100 to serwer będzie działał na prędkości niższej ni zapodana w typ wypadu będzie to 85 fps

Dlatego lepiej jest dawać sys_ticrate zwiększone o 20 do 50 fps niz. te ktora chcesz osiągnąć np. moze się zdarzyc że 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 się posłużyć interpolacją koła. Masz kolo - idealny ksztalt rzeczywisty. Ale ty masz skonczona liczbe kresek do wykorzystania. tak więc 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 się kapniesz :D Przewaznie w CS mamy wielokat o 20 bokach no i tu widac że nie zawsze pozycja gracza jest pozycja realna gracza.

Na szczescie do gry to starcza gdyz dziala interpolacja - wszelkie pozycje gdzie nie masz informacji gdzie się znajduje gracz sa interpolowane. Po prostu modele na ekranie nie skacza, tylko poruszaja się 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 że jesli nie dostaniesz pakietu o polozeniu gracza w ciagu 100ms to H-L bedzie Obliczal gdzie on się 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 że "ex_interp forced to msec" tylko że 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 się 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 się kalkulowal... no ale jestesmy na polskich laczach...

• Czasem wartosci ex_interp ponizej 1/cl_updaterate nie da się 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 że lagi :D. Natomiast modele nie biegaja na tyle wczesnie aby inni uwazali że oszukujesz. Ja uwazam że 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 że jest najlepiej.

Dlaczego? sv_maxrate 0 wykryje rate kazdego gracza i bedzie się staralo spełnic wymogi gracza.

Teraz zalozmy że 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 się wiąze z jakoscia posiadanych przez nich serwerów - silne maszyny z booster'ami na bardzo dobrych łączach.

Aby latwo się 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 że 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 że 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