CS 1.6 Netcode Po Polsku
(→Historia) |
|||
| (Nie pokazano 32 wersji utworzonych przez 3 użytkowników) | |||
| Linia 1: | Linia 1: | ||
| − | |||
| − | |||
[[kategoria:HLDS]] | [[kategoria:HLDS]] | ||
| − | |||
[[kategoria:E-Sport]] | [[kategoria:E-Sport]] | ||
[[Kategoria:Netcode]] | [[Kategoria:Netcode]] | ||
| Linia 10: | Linia 7: | ||
--[[Użytkownik:KaszpiR|KaszpiR]] 15:52, 9 sie 2006 (CEST) | --[[Użytkownik:KaszpiR|KaszpiR]] 15:52, 9 sie 2006 (CEST) | ||
| + | {{stub}} | ||
=Historia= | =Historia= | ||
CS 1.6 Netcode Explained po Polsku (tłumaczenie by _KaszpiR_ http://nvt.prv.pl ) | CS 1.6 Netcode Explained po Polsku (tłumaczenie by _KaszpiR_ http://nvt.prv.pl ) | ||
Artykuł był najpierw dostępny ogólnie na Gotfrag. | Artykuł był najpierw dostępny ogólnie na Gotfrag. | ||
| − | Następnie | + | Następnie stał 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 | + | 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 - | + | 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 | *''Originally by:''' Jon MellinBy, Submitted by: Jason, last updated April 7 2004 at 4:34 PM EDT Gotfrag http://www.gotfrag.net | ||
| Linia 23: | Linia 21: | ||
=Opis= | =Opis= | ||
| − | W artykule zapoznasz | + | *W artykule zapoznasz się z tzw. netkodem gry [[Half-Life]], czyli ta częścią gry która odpowiada za protokół sieciowy itp. |
| − | Mam nadzieje, | + | Mam nadzieje, że pomoże ci on lepiej ustawić wartości aby osiągnąć lepsze wyniki w grze, jak i usprawnić serwer. |
| − | '''Notka:''' | + | *'''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. | |
| − | + | ||
| − | + | ||
| − | Najpierw | + | |
=Ogólnie o zmiennych= | =Ogólnie o zmiennych= | ||
==cl_cmdrate== | ==cl_cmdrate== | ||
| − | *definiuje ile maksymalnie | + | *definiuje ile maksymalnie pakietów może wysłać klient (tzn. ty, graczu że swojej maszyny) do serwera. |
| − | *numer oznacza | + | *numer oznacza liczbę pakietów na sekundę |
| − | + | Oczywiście więcej znaczy lepiej - szybciej serwer zareaguje na twoje reakcje. | |
| − | Traktuj to mniej | + | 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 | + | Jak masz dobre łącze i siedzisz na łączu sam to spoko możesz zwiększyć. |
| − | Jak | + | 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 | + | W idealnym przypadku ta komenda powinna się równać liczbie fps serwera!!! a nie klienta. |
| − | Jak | + | Jak wyślesz więcej pakietów to serwer je po prostu zignoruje bo nie będzie wyrabiać. |
| − | Tak | + | Tak więc za wysokie wartości nie zaszkodzą ale tylko będą marnować twoje łącze :D |
| − | '''Rekomendujemy''' cl_cmdrate | + | '''Rekomendujemy''' cl_cmdrate równe fps serwera lub trochę większe. |
| − | Dlatego na serwerach linuksowych | + | Dlatego na serwerach linuksowych często jest 50 a na windowsowych 70 |
| − | + | oczywiście jak serwer ma więcej fps to walimy 100 i się cieszymy | |
==cl_updaterate== | ==cl_updaterate== | ||
| − | *podobna do poprzedniej komendy ale | + | *podobna do poprzedniej komendy ale działa w odwrotnym kierunku. |
| − | *numer definiuje maksymalna | + | *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 | + | 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 | + | im większa wartość tym szybciej do ciebie grzmot dojdzie (wiem wiem, łopatologicznie...) |
| − | *Po prostu szybciej | + | *Po prostu szybciej będziesz mógł zareagować. |
| − | *Dodatkowo daje to | + | *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 | + | Dlatego czasem cl_updaterate jest większy 4 razy od cmdate |
| − | *Minimalna | + | *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 | + | i zadowalający choke (prawie zero ale może być 2...3) |
| − | choke | + | choke widać na net_graph 3 |
| − | Jednak | + | Jednak cały system cl_updaterate jest bardziej złożony. |
| − | np. serwery CAL | + | 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 | + | 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 | + | 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 | + | 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 | + | 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 | + | Co się stanie? |
| − | Pakiety | + | 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 | + | 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 | + | Na szczęście można to zrobić doświadczalnie w prosty sposób. |
1. zacznij z cl_updaterate 101, ex_interp 0 | 1. zacznij z cl_updaterate 101, ex_interp 0 | ||
| − | 2. | + | 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 swoich rzeczywistych miejscach. | |
| − | Oznacza to | + | 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 | + | Nie bójmy się zejść z wartościami poniżej updaterate 50 bo tak czy siak interpolacja będzie działać. |
| − | No dobra, | + | No dobra, ktoś pomyśli, ale ja wezmę updaterate 20 i będę szedł w gore. |
| − | No to nie jest dobry | + | No to nie jest dobry pomysł bo ex_interp = 1/cl_updaterate. |
Jak mamy 20 to ex_interp = 1/20 = 0.05 | Jak mamy 20 to ex_interp = 1/20 = 0.05 | ||
a jak zwierzymy na 50 to mamy ex_interp = 1/50 = 0.02 | a jak zwierzymy na 50 to mamy ex_interp = 1/50 = 0.02 | ||
| − | a ex intern 0.05 > 0.02 a H-L | + | a ex intern 0.05 > 0.02 a H-L domyślnie nie zmniejsza sam z siebie interna. |
| − | wtedy musisz | + | wtedy musisz wystukać za kadmy razem ex_interp 0 ręcznie aby obliczyć go. |
| − | tak | + | tak więc widać że istnieje zależność pomiędzy serwer fps, cl_udpaterate i ex_interp 0 razem. |
| − | najlepiej | + | najlepiej mieć updaterate równy fps serwera a ex_interp 0 |
'''Rekomendacja:''' | '''Rekomendacja:''' | ||
| − | cl_updaterate | + | 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. | takiej sytuacji. | ||
==sv_maxupdaterate== | ==sv_maxupdaterate== | ||
| − | Jak cl_maxupdaterate ale | + | *Jak cl_maxupdaterate ale działa na serwer - ile klient maksymalnie może przyjąć od serwera. |
| − | + | *Szczególnie użyteczna jak serwer nie ma za dobrego łącza. | |
| − | Numer | + | *Numer oznacza liczbę pakietów na sekundę jaką serwer może wysłać na sekundę do klienta. |
| − | sv_maxupdaterate | + | * przeważnie daje się sv_maxupdaterate 101. |
| − | Dlatego | + | Dlatego jeśli klient ma cl_updaterate 100, a serwer ma sv_maxupdaterate 50, |
| − | to ten klient i tak nie dostanie | + | to ten klient i tak nie dostanie więcej niż. te 50. |
| + | |||
| + | ''Rekomendujemy'' zmieniać jeśli pozwana na to łącze serwera i jego moc procesora. | ||
==sys_ticrate== | ==sys_ticrate== | ||
| − | Definiuje ile maksymalnie klatek na | + | *Definiuje ile maksymalnie tików na sekundę serwer może przetworzyć. Przekłada się to nie bezpośrednio na ilość klatek na sekundą jakie wyciąga serwer. |
| − | + | *Domyślnie jest 100, maksymalnie 10 000. | |
| + | |||
Po co to komu? | Po co to komu? | ||
| − | |||
| − | |||
| − | |||
| − | |||
| − | + | Miedzy innymi więcej fps daje ci lepsze poczucie gry. | |
| − | + | Serwery normalnie maja około 50fps na linuksie i 64 na windowsach - ale czasem spada to do 20-30 to już słabo. | |
| − | + | Dobre serwery maja tak ustawione ten ticrate aby fps się wahało w granicy 150-180 fps (tzn. ogólnie do 200 fps). | |
| − | + | Więcej i tak ci nic nie da bo nie zauważysz. | |
| − | + | ||
| − | + | ||
| − | Jak masz | + | <span style="color:red">Jak nikogo na serwerze nie ma to powinieneś mieć około 100 albo 60 fps - serwer po prostu 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.</span> |
| + | |||
| + | *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 wartości - 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 są | ||
| + | przyjemne i wszystko raczej działa gorzej - to zależy od hardware'u | ||
| + | Więc lepiej aby mieć mniej ale z mniejszymi fluktuacjami. | ||
| + | |||
| + | *Jak masz dostęp do rcon to możesz sprawdzić aktualne fps na serwerze wpisując | ||
rcon stats | rcon stats | ||
| − | Aby | + | Aby sprawdzić jakiego kopa dostanie serwer na chwile włącz |
| − | rcon sys_ticrate 10000 | + | rcon sys_ticrate 10000 |
| − | Jest teraz sprawdzisz rcon | + | 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 |
| − | inaczej szukaj innych metod poprawy | + | |
| − | Zawsze | + | *Zawsze sprawdź stats kilka razy. |
| − | + | Znajdowanie optymalnej wartości wymaga trochę eksperymentów. | |
| − | + | Najpierw sprawdź czy serwer jest boots'owany, bo inaczej nic ci to nie da. | |
| − | + | ||
| − | + | <span style="color:red;">Pamiętaj że podnoszenie fps powyżej 200 jest zbyteczne ze względów możliwości samej gry i łączy internetowych. | |
| − | + | </span> | |
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | 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 będzie wyrabiał. Nie zapominaj że często na serwerach działa też www , mail i ftp. | |
| − | + | ||
| − | + | Nie każdy wie że czasem serwer fps wskazuje na niektóre tylko wartości albo po prostu działa na innych | |
| − | + | np. na jednej z maszyn zaobserwowano że fps układają się tak: 85, 102, 128, 170, 256 ... | |
| − | + | i żadnych fps (liczb) miedzy nimi. | |
| − | + | Więc jak damy w tym przypadku sys_ticrate 100 to serwer będzie działał na prędkości niższej niż zapodana | |
| + | w tym wypadku będzie to 85 fps | ||
| − | + | Dlatego lepiej jest dawać sys_ticrate zwiększone o 20 do 50 fps niż. tę którą chcesz osiągnąć | |
| − | + | np. może się zdarzyć że masz sys_ticrate 150 a serwer będzie wyciągał tylko 128 fps. | |
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | rekomendowane: | |
| − | + | sys_ticrate 110 - 180 w zależności od możliwości twojego sprzętu. | |
| − | + | ||
| − | |||
| − | + | '''Rekomendujemy''' sys_ticrate 125, ale lepiej nie przekraczać 200. | |
| − | + | ||
| − | + | ==fps_max== | |
| + | *ustawia maksymalna ilość FPS jakie ma serwer wyciągać, ale działa także u gracza, tzn jest to zarówno 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ść 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 można 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 przybliżenie wartości korzystając z co najmniej 2 wartości granicznych | ||
| + | np. średnia ocen w szkole to interpolacja .... :D | ||
| + | * często blokowany prze [[HLGuard]] w celu zapobieganiu nadużyciom (dość często niesłusznie blokowany). | ||
| + | Czemu to służy? | ||
| + | W idealnym ustawieniu miałbyś nieskończoną liczbę synchronizacji i byś wiedział gdzie jest przeciwnik. | ||
| + | Oczywiste internet na to ci nie pozwoli i dostaniesz tylko skończoną liczbę pakietów. | ||
| + | Najłatwiej tu jest się posłużyć interpolacją koła. | ||
| + | Masz kolo - idealny kształt rzeczywisty. Ale ty masz skończoną liczbę kresek do wykorzystania. | ||
| + | tak więc wpisujesz wielokąt foremny aby jak najbardziej upodobnić go do kola | ||
| + | Z daleka patrząc nie zauważysz różnicy czy masz wielokąt o 100 bokach czy kolo no ale jak usiądziesz z lupa to się kapniesz :D | ||
| + | Przeważnie w CS mamy wielokąt o 20 bokach no i tu widać że nie zawsze pozycja gracza jest pozycja realna gracza. | ||
| − | + | Na szczęście do gry to starcza gdyż działa interpolacja - wszelkie pozycje gdzie nie masz informacji gdzie się znajduje gracz sa interpolowane. | |
| − | + | Po prostu modele na ekranie nie skaczą, tylko poruszają się płynnie bo są interpolowane bazując na pakietach jakie otrzymujesz od serwera. | |
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | *Oznacza to przedział czasowy do wykorzystania przez grę - jako ułamek sekundy. | |
| + | Domyślnie jest to maksymalnie 0.1 Czyli 100 ms - oznacza to że jeśli nie dostaniesz pakietu o położeniu gracza w ciągu 100ms to H-L będzie | ||
| + | Obliczał gdzie on się znajduje. | ||
| − | + | *Normalnie ex_interp powinien być równy lub troszkę większy od 1/cl_updaterate | |
| − | ex_interp 0 | + | *Niektórzy rekomendują ex_interp 0 |
| + | wtedy H-L sam obliczy tę wartość i ci powie że "ex_interp forced to msec" | ||
| + | tylko że jest problem | ||
| + | #jak zmieniasz jakkolwiek cl_updaterate to potem musisz wywołać ex_interp 0 aby to obliczył | ||
| + | #jak masz ex_interp 0 to modela mogą zacząć skakać - bo pakiety się spóźniają, to normalne. | ||
| + | Maksymalnie ex_interp ma 0.1 czyli 100 milisekund - to jest dużo. | ||
| + | Najczęściej jak masz cl_updaterate 20 to masz ex_interp 0.05 - oczywiście im większy update tym mniejsza liczba | ||
| + | Niektórzy tylko rekomendują operowanie cl_updaterate i zostawianie ex_interp'a w spokoju aby sam się kalkulował... no ale jesteśmy na polskich łączach... | ||
| + | *Czasem wartości ex_interp poniżej 1/cl_updaterate nie da się ustawić. | ||
| + | Czasem wartości powyżej 1/cl_updaterate są uważane za exploit gdyż powoduje to, że musisz strzelać za rzeczywistym modelem - dlatego jest efekt spóźniony headshot'ów - koleś przebiegł, ty strzeliłeś gdzie on "był" i dostał heda, a krew sika z pustki | ||
| + | Ja sugeruje popatrzeć ile ex_interp 0 wyliczy i potem dodać ręcznie +0.01, | ||
| + | np. cl_updatertae 20 => ex_interp 0.05, | ||
| + | dodajemy i mamy ex_interp 0.06 | ||
| + | efektu spóźnionych hedów nie powinno być tak wiele i modele nie powinny aż tak bardzo skakać - no chyba że lagi :D. | ||
| + | Natomiast modele nie biegają na tyle wcześnie aby inni uważali że oszukujesz. | ||
| + | Ja uważam że dodanie 0.01 to nie jest expliotem bo netcode nie jest idealny, szczególnie jak na polskie warunki | ||
| − | + | Moim zdaniem exploitem jest jak gracz ma cl_updaterate 101 i wtedy powinien mieć ex_interp 0.009 (no powiedzmy 0.01) a w rzeczywistości używa ex_interp 0.1 czyli 10x większego!!! | |
| − | jest | + | |
| − | + | ||
| − | + | ||
| − | + | ||
| + | '''Rekomendacja''' ostateczna | ||
| + | ex_interp 0.1 czyli nie dotykać - wtedy HLGuard i jego blokowanie zmiennych nie będzie tak uciążliwe. | ||
| + | ==rate== | ||
| + | Jest to ile bajtów możesz przesłać do serwera. maksymalnie jest 20000, bo wyżej H-L nie wyciągnie. | ||
| + | standardowo jest chyba 5000 albo i mniej ale np. clanbase używa 9999. | ||
| + | '''Rekomendujemy''' zatem albo 9999 albo 20000 jeśli serwer pozwala, ew jeśli masz słabe łącze to nie więcej niż 80% twojego uploadu. | ||
==sv_maxrate== | ==sv_maxrate== | ||
| − | + | Domyślnie jest równe 0 co nie oznacza że jest najlepiej. | |
| + | |||
Dlaczego? | Dlaczego? | ||
| − | + | sv_maxrate 0 wykryje rate każdego gracza i będzie się starało spełnić wymogi gracza. | |
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| + | Teraz załóżmy że H-L daje możliwość dania rate powyżej 20 kafli, a jakiś gracz ma fantazję i walnie ostrą wartość np. 9999999999 (kosmiczna liczba). | ||
| + | Serwer w tym przypadku próbowałby wypchać tę kosmiczną ilość danych do tego gracza i tylko by marnował łącze do tej osoby bo i tak tyle nie wyśle, a reszta będzie lagowana bo nie dostanie nic. | ||
| + | *Dodatkowo, dzięki ustawieniu wartości sv_maxrate możemy przewidywać maksymalne użycie łącza na miesiąc - jeśli płacimy za transfer w GB. | ||
| − | + | '''Rekomendujemy''' dlatego ustawiać sv_maxrate na 20000. | |
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
=LAN= | =LAN= | ||
| + | No a jak grac na LAN'ie? | ||
| + | organizacje typu [[CPL]] używają cl_updaterate 101 gdyż to się wiąże z jakością posiadanych przez nich serwerów - silne maszyny z booster'ami na bardzo dobrych łączach. | ||
| − | + | Aby łatwo się przekonać 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 powyżej 15ms. | |
| − | + | *jak serwer ma więcej fps ( np ma booster'a) to pingi są o wiele mniejsze - przeważnie w granicy 5ms. | |
| − | normalny serwer bez booster'a na 60-65 fps powoduje | + | |
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| + | Wiadomo że CPL, ESWC i WCG używają serwerów z booster'ami bo ich na to stać. | ||
=Podziękowania= | =Podziękowania= | ||
| − | + | Podziękowania dla: | |
| − | Alfred Reynolds, Valve Software | + | *Alfred Reynolds, Valve Software |
| − | Yahn Bernier, Valve Software | + | *Yahn Bernier, Valve Software |
| − | Zibbo, UDPSoft | + | *Zibbo, UDPSoft |
| − | The HLDS Mailing Lists | + | *The HLDS Mailing Lists |
| − | The server.counter-strike.net forums | + | *The http://server.counter-strike.net forums |
translated from english by _KaszpiR_ | translated from english by _KaszpiR_ | ||
| + | |||
9 May 2004 | 9 May 2004 | ||
Aktualna wersja na dzień 14:25, 6 lip 2007
Spis treści |
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 stał 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 windowsowych 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 swoich 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 ręcznie 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 działa na serwer - ile klient maksymalnie może przyjąć od serwera.
- Szczególnie użyteczna jak serwer nie ma za dobrego łącza.
- Numer oznacza liczbę pakietów na sekundę jaką serwer może wysłać na sekundę do klienta.
- przeważnie daje się sv_maxupdaterate 101.
Dlatego jeśli klient ma cl_updaterate 100, a serwer ma sv_maxupdaterate 50, to ten klient i tak nie dostanie więcej niż. te 50.
Rekomendujemy zmieniać jeś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 wyciąga serwer.
- Domyślnie jest 100, maksymalnie 10 000.
Po co to komu?
Miedzy innymi więcej fps daje ci lepsze poczucie gry. Serwery normalnie maja około 50fps na linuksie i 64 na windowsach - ale czasem spada to do 20-30 to już słabo. Dobre serwery maja tak ustawione ten ticrate aby fps się wahało w granicy 150-180 fps (tzn. ogólnie do 200 fps). Więcej i tak ci nic nie da bo nie zauważysz.
Jak nikogo na serwerze nie ma to powinieneś mieć około 100 albo 60 fps - serwer po prostu 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 wartości - 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 są przyjemne i wszystko raczej działa gorzej - to zależy od hardware'u Więc lepiej aby mieć 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ź stats kilka razy.
Znajdowanie optymalnej wartości wymaga trochę eksperymentów. Najpierw sprawdź 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 będzie wyrabiał. Nie zapominaj że często na serwerach działa też www , mail i ftp.
Nie każdy wie że czasem serwer fps wskazuje na niektóre tylko wartości albo po prostu działa na innych np. na jednej z maszyn zaobserwowano że fps układają się tak: 85, 102, 128, 170, 256 ... i żadnych fps (liczb) miedzy nimi.
Więc jak damy w tym przypadku sys_ticrate 100 to serwer będzie działał na prędkości niższej niż zapodana w tym wypadku będzie to 85 fps
Dlatego lepiej jest dawać sys_ticrate zwiększone o 20 do 50 fps niż. tę którą chcesz osiągnąć np. może się zdarzyć że masz sys_ticrate 150 a serwer będzie wyciągał tylko 128 fps.
rekomendowane: sys_ticrate 110 - 180 w zależności od możliwości twojego sprzętu.
Rekomendujemy sys_ticrate 125, ale lepiej nie przekraczać 200.
fps_max
- ustawia maksymalna ilość FPS jakie ma serwer wyciągać, ale działa także u gracza, tzn jest to zarówno 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ść 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 można 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 przybliżenie wartości korzystając z co najmniej 2 wartości granicznych
np. średnia ocen w szkole to interpolacja .... :D
- często blokowany prze HLGuard w celu zapobieganiu nadużyciom (dość często niesłusznie blokowany).
Czemu to służy? W idealnym ustawieniu miałbyś nieskończoną liczbę synchronizacji i byś wiedział gdzie jest przeciwnik. Oczywiste internet na to ci nie pozwoli i dostaniesz tylko skończoną liczbę pakietów. Najłatwiej tu jest się posłużyć interpolacją koła. Masz kolo - idealny kształt rzeczywisty. Ale ty masz skończoną liczbę kresek do wykorzystania. tak więc wpisujesz wielokąt foremny aby jak najbardziej upodobnić go do kola Z daleka patrząc nie zauważysz różnicy czy masz wielokąt o 100 bokach czy kolo no ale jak usiądziesz z lupa to się kapniesz :D Przeważnie w CS mamy wielokąt o 20 bokach no i tu widać że nie zawsze pozycja gracza jest pozycja realna gracza.
Na szczęście do gry to starcza gdyż działa interpolacja - wszelkie pozycje gdzie nie masz informacji gdzie się znajduje gracz sa interpolowane. Po prostu modele na ekranie nie skaczą, tylko poruszają się płynnie bo są interpolowane bazując na pakietach jakie otrzymujesz od serwera.
- Oznacza to przedział czasowy do wykorzystania przez grę - jako ułamek sekundy.
Domyślnie jest to maksymalnie 0.1 Czyli 100 ms - oznacza to że jeśli nie dostaniesz pakietu o położeniu gracza w ciągu 100ms to H-L będzie Obliczał gdzie on się znajduje.
- Normalnie ex_interp powinien być równy lub troszkę większy od 1/cl_updaterate
- Niektórzy rekomendują ex_interp 0
wtedy H-L sam obliczy tę wartość i ci powie że "ex_interp forced to msec" tylko że jest problem
- jak zmieniasz jakkolwiek cl_updaterate to potem musisz wywołać ex_interp 0 aby to obliczył
- jak masz ex_interp 0 to modela mogą zacząć skakać - bo pakiety się spóźniają, to normalne.
Maksymalnie ex_interp ma 0.1 czyli 100 milisekund - to jest dużo. Najczęściej jak masz cl_updaterate 20 to masz ex_interp 0.05 - oczywiście im większy update tym mniejsza liczba
Niektórzy tylko rekomendują operowanie cl_updaterate i zostawianie ex_interp'a w spokoju aby sam się kalkulował... no ale jesteśmy na polskich łączach...
- Czasem wartości ex_interp poniżej 1/cl_updaterate nie da się ustawić.
Czasem wartości powyżej 1/cl_updaterate są uważane za exploit gdyż powoduje to, że musisz strzelać za rzeczywistym modelem - dlatego jest efekt spóźniony headshot'ów - koleś przebiegł, ty strzeliłeś gdzie on "był" i dostał heda, a krew sika z pustki
Ja sugeruje popatrzeć ile ex_interp 0 wyliczy i potem dodać ręcznie +0.01, np. cl_updatertae 20 => ex_interp 0.05, dodajemy i mamy ex_interp 0.06 efektu spóźnionych hedów nie powinno być tak wiele i modele nie powinny aż tak bardzo skakać - no chyba że lagi :D. Natomiast modele nie biegają na tyle wcześnie aby inni uważali że oszukujesz. Ja uważam że dodanie 0.01 to nie jest expliotem bo netcode nie jest idealny, szczególnie jak na polskie warunki
Moim zdaniem exploitem jest jak gracz ma cl_updaterate 101 i wtedy powinien mieć ex_interp 0.009 (no powiedzmy 0.01) a w rzeczywistości używa ex_interp 0.1 czyli 10x większego!!!
Rekomendacja ostateczna ex_interp 0.1 czyli nie dotykać - wtedy HLGuard i jego blokowanie zmiennych nie będzie tak uciążliwe.
rate
Jest to ile bajtów możesz przesłać do serwera. maksymalnie jest 20000, bo wyżej H-L nie wyciągnie. standardowo jest chyba 5000 albo i mniej ale np. clanbase używa 9999.
Rekomendujemy zatem albo 9999 albo 20000 jeśli serwer pozwala, ew jeśli masz słabe łącze to nie więcej niż 80% twojego uploadu.
sv_maxrate
Domyślnie jest równe 0 co nie oznacza że jest najlepiej.
Dlaczego? sv_maxrate 0 wykryje rate każdego gracza i będzie się starało spełnić wymogi gracza.
Teraz załóżmy że H-L daje możliwość dania rate powyżej 20 kafli, a jakiś gracz ma fantazję i walnie ostrą wartość np. 9999999999 (kosmiczna liczba). Serwer w tym przypadku próbowałby wypchać tę kosmiczną ilość danych do tego gracza i tylko by marnował łącze do tej osoby bo i tak tyle nie wyśle, a reszta będzie lagowana bo nie dostanie nic.
- Dodatkowo, dzięki ustawieniu wartości sv_maxrate możemy przewidywać maksymalne użycie łącza na miesiąc - jeśli płacimy za transfer w GB.
Rekomendujemy dlatego ustawiać sv_maxrate na 20000.
LAN
No a jak grac na LAN'ie?
organizacje typu CPL używają cl_updaterate 101 gdyż to się wiąże z jakością posiadanych przez nich serwerów - silne maszyny z booster'ami na bardzo dobrych łączach.
Aby łatwo się przekonać 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 powyżej 15ms.
- jak serwer ma więcej fps ( np ma booster'a) to pingi są o wiele mniejsze - przeważnie w granicy 5ms.
Wiadomo że CPL, ESWC i WCG używają serwerów 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
