HLDS.pl - Wkład użytkownika [pl]

Rcon

2008-05-19T13:06:21Z

D4rk:

== Opis ==
{{stub}}

===Co to jest rcon?===
Nazwa '''rcon''' jest skrótem słów '''r'''emote '''con'''sole i oznacza [[konsola|konsolę]] zdalną,
podobną do takiej jaką masz w grze [[Half-Life]], jednakże bez auto uzupełnienia (jak naciśniesz tab to ci nie uzupełni początku komendy do rozpoznawalnej nazwy, przynajmniej tka było w [[Counter-Strike 1.6]]

===Do czego służy rcon?===
Rcon służy do zdalnej administracji serwerem gry, np [[Half-Life]], czyli [[HLDS]], albo gry [[Source]] czyli [[SRCDS]], ale jest też spotykany w większości gier FPP, takich jak [[Quake 3]], [[Unreal Tournament]] itd. Moze to byc serwer na lanie (tzn [[Klient - Serwer#listen|Listen Server]]) czy też najczęściej serwer dedykowany [[Klient - Serwer#dedicated|Dedicated Server]] albo serwer [[HLTV]], czy innej, podobnej usługi, np w [[QuakeWorld|QW]] serwer [[Proxy]].

===Jak to skonfigurowac na serwerze?===
<div id="konfiguracja"></div>
Aby dostęp do rcon'a był mozliwy serwer musi miec zdefiniowana zmienna, najczęściej rcon_password
np dla serwerów [[HLDS]] mamay
rcon_password "TwojeUlubioneHalso"

Najlepiej w linii startowej hlds jest umieścić rcon_password np
hlds_run -ip 123.45.67.89 -port 27015 +exec server.cfg +map de_dust +rcon_password "zupa_jarzynowa"

Mozna takze w pliku konfiguracyjnym takim jak [[HLDS server.cfg|server.cfg]] (czy [[HLDS server.cfg|listenserver.cfg]]) - tam po prostu dodajemy kolejną linijke typu:
rcon_password "zupa_jarzynowa"
ale odradzamy to rozwiązanie z przyczyn bezpieczeństwa.

Rcon moze byc takze ładowany z [[SQL|bazy danych SQL]] jeśli mamy odpowiedni plugin do [[AMX Mod]]a (''czy inne narzędzie do komuniakcji z bazą danych pod serwer gry'').

Haslo może byc dowolne ale radze ustawiac w miarę długie, nie moze zawierac znakow zakazanych przez slinik gry - czyli żadnych polskich itp, najlepiej pisac prostymi literkami.

Najlepiej aby rcon_password byl unikalny na serwer, szczegolnie jak jest kilka serwerow na tym
samym numerze ip ale na różnych portach.

Rcon jest bardzo potężną komendą - mozna nia zdziałać bardzo wiele.
Osoby, ktore nie znają sie na serwerze gry mogą tylko zaszkodzić na serwerze, jesli będą bezmyślnie
korzystać z komend i przestawiać zmienne. Jedynie wybrane zaufane osoby powinny mieć dostęp do rcon'a. Co więcej istnaieją przypadki gdzie rcon nie powinen byc kompletnie znany jednye przez Head Admina w związku z innymi działającymi programamy na serwerze rgy (korzystającymi z rcon;a do komunikacji z serwerem, jego mziana może spowodować, ze te aplikacje przestaną działać).

Wiele pluginów daje mozliwosc nadawania adminom prawa dostepu do rcon'a ale bez znajomosci
hasła rcon_password - np cm_rcon, amx_rcon, admin_rcon. Jednakze ma to swoje ograniczenia
np dziala to w jedym kierunku - serwer moze otrzymac komende od admina, ale czasem serwer nie zwraca nic do admina - np z potwierdzeniem o ustawieniu zmiennej itp.

===Jak tego uzywac bedac w grze?===
Musisz najpierw znać kilka rzeczy:
*rcon_address - ip serwera do ktorego chcesz sie podlaczyc rcon'em,
jesli puste - domyslnie numer ip do ktorego jestes podlaczony aktualnie w czasie gry, inaczej trza podac
*rcon_port - port serwera do ktorego sie chcesz podlaczyc rconem,
jesli puste domyslnie port na ktorym jestes podlaczony do serwera gry, inaczej trza wpisac.
trzeba uwazac jak jest klika serwerow na tym samym numerze ip ale na roznych portach - lepiej precyzowac port
czesto wtedy servery sa na tym samym ip ale ronych portach i majak rozne hasla na serwery
* rcon_password - haslo do rcona, takie jakie jest na serwerze (patrz punkt 4.)

Przewaznie starczy, ze podczas gry znasz tylko rcon_password - bo reszta bedzie uznawana za domyslna
i bedzie przypisana do aktualnie podlaczanego serwera.

Podczas gry na danym serwerze do ktorego mamy rcon_password,
w konsoli gracza (przewaznie u siebie) wpisujemy
rcon_password "zupa_jarzynowa"

Nastepnie nalezy sie upewnic ze podane haslo jest prawidlowe - przeprowadzamy maly test
rcon say Test raz dwa trzy
powinien sie pojawic w czesci chat na ekranie tekst wypowiedziany prez serwer (jako imie gracza bedzie nazwa hostname serwera)

Jesli to dziala mozemy smialo operowac rconem dalej. Jesli nie to '''nie''' probujmy na sile bo zostaniemy zbanowani z serwera! Trzeba sie upewnic, ze mamy poprawny host, port, no i oczywiscie haslo :D

Komendy wstukiwane przy uzyciu rcon'a sa dokladnie takie same jabysmy je wstukiwali bezposrednio do
konsoli serwera gry - jedyna roznica polega na tym ze trzeba dodac magiczne slowo '''rcon''' na poczatku.
Jednakże nie wszystkie komendy w serwerze hlds sa dostepne w serwerach listen albo z komend u klienta.
== Komendy ==
Najczesciej uzywane komendy poprzez rcon dla serwera [[HLDS]]
*lista graczy (''zobacz także [[SteamID]]'')
rcon status
rcon users
(users powinien chyba dzialc nawet bez rcon'a)

*restart rundy
rcon sv_restartround 1

*zmiana mapy
rcon changelevel de_dust

*zmiana mapy z wykopaniem graczy
rcon map de_dust

*zmiana zmiennych (przyklad trzech)
<pre>
rcon mp_timelimit 0
rcon mp_winlimit 12
rcon hostname "Serwer zajety!"
rcon sv_lan 1
</pre>

*zmian hasla na serwerze np na mecz
rcon sv_password "haslo_na_cw"
*czyszczenie hasla na serwerze po meczu
rcon sv_password ""
<div id="banowanie"></div>
*kopanie/banowanie (''zobacz także [[SteamID]]'')
wpisujemy
status
(albo users, zalezy od przyzwyczajenia)
patrzymy na liste jaka sie pojawi w konsoli
patrzymy na uid (unique id gracza) i steamid (ew zastap steamnid wonid'em)

i piszemy
rcon banid 1440 # uniqueid kick //ban z wykopem
rcon writeid //zapisanie banow
rcon writeip //zapisanie banow na ip

rcon banid 0.0 # uniqueid //permanent ban
rcon kick # uid //wykopanie gracza

*gadanie
rcon say Nie biegac!!

Oczywiscie mozemy wykonac inne komendy dostepne, np z pluginow
rcon cm_say @g "Muahaha Wasz Pan Wrocil!"
rcon amx_nextmap de_dust

Radze korzystac z programow typu HLSW ktore lepiej sie nadaja do zdalenej administracji serwerem via rcon

==FAQ==
===Nie chce mi się pisać w konsoli, można podpisać pod klawisz komendy ?===
A: Tak, tylko zanim naciśniesz klawisz upewnij się, że masz poprawnie wpisane '''rcon_password'''

przyklad
bind "[" "rcon say Restart !;rcon sv_restartround 3"
bind "'" "rcon say GL & HF !;"
bind "]" "rcon mp_timelimit 0;rcon mp_winlimit 12;rcon servercfgfile 'clanbase.cfg';rcon mapcyclefile '';rcon sv_password clanwar;rcon Ustawienia na mecz zaladowane;rcon exec clanbase.cfg;"
bind "/" "rcon mp_winlimit 0;rcon servercfgfile 'server.cfg';rcon mapcyclefile 'mapcycle.txt';rcon sv_password '';rcon say Ustawienia normalne zaladowane;rcon exec server.cfg"

===Ban===
<div id="ban"></div>
'''Mialem zbindowany klawisz na restart, pare razy wcisnalem a zapomnialem ze nie wpisalem hasla!
Zbanowalo mnie i nie moge wejsc na serwer!! '''

A: Musisz sprawdzic swoje ip z którego grałeś albo łączyłeś sie rconem do serwera.
Następnie musisz wykonac komendę
removeip
writeip
Na przykład łączyłeś się z 192.169.10.2 to z innego numeru ip przez rcon albo bezpośrednio w konsoli serwera (na screenie)
musisz wpisać
removeip 192.169.10.2
writeip

Ewentualnie jak to nie wchodzi w grę to wyłącz serwer i uruchom ponownie.

Zobacz także [[#banowanie|kopanie i banowanie]].

===Jak się zabezpieczyć przed przejęciem hasła do rcon'a?===
A: Kilka metod:
*CS 1.5 - Zainstaluj update x.1.1.1e, natomiast na serwery typu listen nie ma i nie będzie łatki
*Steam - Do tej pory expolity istnieją na stare wersje (te sprzed 2006 roku)

Nie trzymaj '''rcon_password''' w pliku '''server.cfg''' (''bo plik może być ściągnięty'')
* '''sv_allowdownload 0'''
Jak używasz '''sv_downloadurl''' nie zamieszczaj tam plików konfiguracyjnych z aktualnie chodzącego serwera bez przejrzenia i wycięcia ważnych informacji.

Sposób, który nie zabezpiecza do końca możliwości ściągnięcia rcona, ale generalnie na kid-hackierów wystarczy:
* Haslo rcon'a trzymajcie w jakimś dziwnym pliku, typu: mam2leweN0gi.cfg
Niestety, pozostają jeszcze hasła adminów w plikach, których nazwy są ogólnie znane, ale to też można zmienić.

Kolejnym sposobem zabezpieczenia jest dodanie zmiennej '''rcon_password''' do linii poleceń odpalanego serwera.

===Jak się zabezpieczyć przed złamaniem hasła do rcon'a ?===
Na serwerze [[HLDS]] albo [[SRCDS]] w '''server.cfg''' wpisz:
<pre>
sv_rcon_minfailures 2
// # of failures needed before ban
// Liczba nie udanych prob potrzebnych do zbanowania
sv_rcon_minfailuretime 600
// amount of time (seconds) failed rcon attempts must occur within for the ban to be applied
sv_rcon_banpenalty 300
// minutes to ban. 300 = 5 hours.
// Ile ma trwac czasu ban. 300 minut = 5 godzin.
sv_rcon_maxfailures 3
// similar to sv_rcon_minfailures, except this setting doesn't rely on sv_rcon_minfailuretime.
// Any IP address that fails 3 rcon authentications (during a server uptime session) will be banned for the banpenalty.
</pre>

Dodatkowo odradzamy dawanie rcon'a osobom do których nie mamy pełnego zaufania, albo jeśli nie mamy możliwości wyłączenia serwera czy innego rodzaju kontroli nad nim.

Informacja pochodzi z Forum UnitedAdmins z sekcji Half-Life Support / HLDS.

==Podziękowania==
*Pawels
*vib

=Zobacz także=
*[[Konfigi meczowe]]
*[[HLTV]]
*[[SteamID]]
* [[Prosze o odbanowanie]]
[[kategoria:gry]]
[[kategoria:serwery gier]]

Insurgency (mod)

2007-07-17T09:34:51Z

D4rk:

=Opis=
Insurgency to [[mod]] na silniku [[Source]]. Realistyczny Counter-Strike w Iraku. :)

Aktualnie wersja beta! Czekamy na najbliższego patcha, który ma się pojawić w połowie lipca.
[[kategoria:gry]]

=Linki=
*[http://www.insmod.net Oficjalna strona] po angielsku.
*[http://www.insmod.net/manual Instrukcja obsługi] po angielsku.

=Wymagania=
*[[Steam]]
* Zainstalowana gra na silniku [[Source]], np. Half-Life 2, Counter-Strike: Source albo Day of Defeat: Source.
*Sprzęt który udźwignie Source powinien i to pociągnąć, aczkolwiek gra potrafi zżerać [[FPS]].
*1.4 GB miejsca na dysku

=Instalacja=
*Pobieramy plik [http://www.insmod.net/downloads jeden z tej listy], czekamy aż zassiemy 700MB.
*Wyłączamy Steam
*Uruchamiamy instalatora, wybieramy katalog docelowy - powinien automatycznie to wykryć.
*Włączamy Steam
* Steam każe sobie dossać z netu Source SDK Base - jakieś 60MB, trochę poczekamy.
*W liście gier widzimy nowy mod Insurgency - odpalamy i konfigurujemy grę jak klawisze, grafikę itp.

=Cechy charakterystyczne=
Do gry trzeba sie przyzwyczaić, poniżej lista charakterystycznych rzeczy:

* brak celownika, jest walenie z biodra i iron sights
* jak robimy sprint to nie można strafeować na boki oraz czułość myszki sie zmniejsza, wiec trzeba większe wymachy zrobić aby zakręcić, co więcej opuszczamy bron i nie można strzelać.
* gra zespołowa
* przeważnie 1 kula i jesteś trupem
* wychylanie sie na boki
* kilka trybów rozgrywki, ogólnie trzeba przejąć punkty na mapie aby zwiększyć swoją ilość kolejnych respawnów, przejmowanie w zależności od ilości graczy na serwerze - czyli przy malej ilości osób sami przejmiemy, a jak jest bardzo dużo to trzeba np. we 3 osoby.
* moim zdaniem gra wygląda naprawdę rewelacyjnie, nie umywa się do CS:S - te modele biegają naturalnie, a nie jak geje-baletnice w CS:S, animacje są płynniejsze, mniej drętwe niż w RO.
* duże wymagania sprzętowe, większe niż RO, ale następny patch ma poprawić ilość FPS.
* przebijane ściany i obiekty oraz rykoszety

=Błędy=
Bugi jakie znalazłem jak dotąd:
*<s>sprint przy rzucie granatem = nie masz szansy na zmianie broni ani rzut granatem, wiec tylko sie idzie zabić</s>
*wychylanie sie na boki niestety nie działa podczas strafe - prostuje do pionu, poza tym uważam ze jest za słabe.
*granaty trzeba rzucać bardzo wysoko - wtedy lecą daleko, są dymne i odłamkowe
*śmieszne dźwięki Irakijczyków, "frrrraaaaag auuut" ;)
*dziwny efekt rozmycia po wybuchu granatu, szczerze, powinien być jak w RO, ale jest nałożenie sie kilku obrazów jeden na drugim - trochę brakuje tu do efektu z CSS:S
*można sie zaciąć na mapie, na respie czasem ludzie włażą jeden na drugiego
*koszmarny spawn raping (czyli idziesz na respa wroga i masakrujesz jak się pojawia) oraz spawn killing - czyli byle buc z naszego teamu pociągnie seria i cały team leży
*czasem jest bug ze scope - wygięcie obrazu
*<s>bugi na mapach, np. czasem jest przenikalna skrzynia i można w nią wleźć, czyli taki noclip</s> powoli usuwają błędy map
*<s>ubogie radio menu<s> - można wreszcie trochę lepiej pogadać
*<s>brak opisów klas przy wyborze</s> jest teraz więcej info
*serwery '''linuksowe''' są '''niekompatybilne''' z klientami = wszystkie są puste bo nie można na nie wejść, wywala komunikat ''Different class'', czekamy na najbliższego patcha, co ma się pojawić w połowie lipca.
*serwery na Windows często zdychają, np. czasem raz na 10 min, ale czasem i parę godzin działa bez problemu

=Obrazki=
==Z gry==
*http://forums.insmod.net/index.php?showtopic=5375
==Mapy==
<gallery>
Grafika:Ins almaden.jpg
Grafika:Ins baghdad.jpg
Grafika:Ins haditha.jpg
Grafika:Ins hillah.jpg
Grafika:Ins karkar.jpg
Grafika:Ins ramadi.jpg
Grafika:Ins sinjar.jpg
</gallery>
==Tapeta==
... czyli wallpaper ;)
[[Grafika:Insurgency wallpaper 1280x1024.jpg|thumb|left]]
{{clr}}

=Filmy=
* [http://www.red.orchestra.pl/datas/kaszpir/insmod_1024.avi Film] 246MB - 1024x768, XviD, 8000kbps, 25fps, full quality in Source game.

CS 1.6 Netcode Po Polsku

2007-07-06T12:25:45Z

D4rk:

[[kategoria:HLDS]]
[[kategoria:E-Sport]]
[[Kategoria:Netcode]]
=Wstęp=
Trochę stary artykuł, będę musiał go odkurzyć z debilizmów, więc się będzie zmieniał co jakiś czas.

--[[Użytkownik:KaszpiR|KaszpiR]] 15:52, 9 sie 2006 (CEST)

{{stub}}
=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.

<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
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.

<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
*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

CS 1.6 Netcode Po Polsku

2007-07-06T12:20:53Z

D4rk:

[[kategoria:HLDS]]
[[kategoria:E-Sport]]
[[Kategoria:Netcode]]
=Wstęp=
Trochę stary artykuł, będę musiał go odkurzyć z debilizmów, więc się będzie zmieniał co jakiś czas.

--[[Użytkownik:KaszpiR|KaszpiR]] 15:52, 9 sie 2006 (CEST)

{{stub}}
=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 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.

<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
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.

<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
*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

CS 1.6 Netcode Po Polsku

2007-07-06T12:14:10Z

D4rk:

[[kategoria:HLDS]]
[[kategoria:E-Sport]]
[[Kategoria:Netcode]]
=Wstęp=
Trochę stary artykuł, będę musiał go odkurzyć z debilizmów, więc się będzie zmieniał co jakiś czas.

--[[Użytkownik:KaszpiR|KaszpiR]] 15:52, 9 sie 2006 (CEST)

{{stub}}
=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 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 dziala 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 200fps).
Więcej i tak ci nic nie da bo nie zauważysz.

<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 sa
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ź statsy 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
*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 ponizej 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 hedow 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 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 więcej 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

CS 1.6 Netcode Po Polsku

2007-07-06T11:57:52Z

D4rk:

[[kategoria:HLDS]]
[[kategoria:E-Sport]]
[[Kategoria:Netcode]]
=Wstęp=
Trochę stary artykuł, będę musiał go odkurzyć z debilizmów, więc się będzie zmieniał co jakiś czas.

--[[Użytkownik:KaszpiR|KaszpiR]] 15:52, 9 sie 2006 (CEST)

{{stub}}
=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.

<span style="color:red">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.</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 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.

<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 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
#jak zmieniasz jakkolwiek cl_updaterate to potem musisz wywolac ex_interp 0 aby to obliczyl
#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

CS 1.6 Netcode Po Polsku

2007-07-06T11:47:31Z

D4rk:

[[kategoria:HLDS]]
[[kategoria:E-Sport]]
[[Kategoria:Netcode]]
=Wstęp=
Trochę stary artykuł, będę musiał go odkurzyć z debilizmów, więc się będzie zmieniał co jakiś czas.

--[[Użytkownik:KaszpiR|KaszpiR]] 15:52, 9 sie 2006 (CEST)

{{stub}}
=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 - 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 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, wiec 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 wiec 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 wiec 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 bedzie cacy.
Jednakże serwer ma 50 fps czyli maksymalnie puści 50 pakietów!!! tak więc 2 razy mniej.
Co się stanie?
Pakiety przychodza za rzadko i gra nie ma z czego interpolowac polozenia graczy - masz efekt skaczacych modeli.
No dobra. dajmy na to że 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 że 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 że kazdy serwer bedzie mial swoje wlasne ustawienia cl_updaterate zalezne od ilosci graczy/lacza/fps - po prosu ile w danej chwili serwer może z siebie wycisnac.
Nie bojmy się 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 że 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 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.

<span style="color:red">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.</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 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.

<span style="color:red;">Pamietaj że podnoszenie fps powyzej 200 jest zbyteczne że wzgledow mozliwosci samej gry i laczy internetowych.
</span>

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 że czesto na serwerach dziala 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 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 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 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 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
#jak zmieniasz jakkolwiek cl_updaterate to potem musisz wywolac ex_interp 0 aby to obliczyl
#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

CS 1.6 Netcode Po Polsku

2007-07-06T11:37:26Z

D4rk:

[[kategoria:HLDS]]
[[kategoria:E-Sport]]
[[Kategoria:Netcode]]
=Wstęp=
Trochę stary artykuł, będę musiał go odkurzyć z debilizmów, więc się będzie zmieniał co jakiś czas.

--[[Użytkownik:KaszpiR|KaszpiR]] 15:52, 9 sie 2006 (CEST)

{{stub}}
=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 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 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 - coś 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 pakietów może wysłać klient (tzn. ty, graczu ze 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 sie 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 wiec 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 sie 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 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.

<span style="color:red">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.</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 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 ze boosting działa i sie 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.

<span style="color:red;">Pamietaj ze podnoszenie fps powyzej 200 jest zbyteczne ze wzgledow mozliwosci samej gry i laczy internetowych.
</span>

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 też 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
#jak zmieniasz jakkolwiek cl_updaterate to potem musisz wywolac ex_interp 0 aby to obliczyl
#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

CS 1.6 Netcode Po Polsku

2007-07-06T11:31:41Z

D4rk: status -> stats

[[kategoria:HLDS]]
[[kategoria:E-Sport]]
[[Kategoria:Netcode]]
=Wstęp=
Trochę stary artykuł, będę musiał go odkurzyć z debilizmów, więc się będzie zmieniał co jakiś czas.

--[[Użytkownik:KaszpiR|KaszpiR]] 15:52, 9 sie 2006 (CEST)

{{stub}}
=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.

<span style="color:red">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.</span>

*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.

<span style="color:red;">Pamietaj ze podnoszenie fps powyzej 200 jest zbyteczne ze wzgledow mozliwosci samej gry i laczy internetowych.
</span>

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
#jak zmieniasz jakkolwiek cl_updaterate to potem musisz wywolac ex_interp 0 aby to obliczyl
#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