Klan: oglądam w TV
Dodatkowy Nick: DzejmsBlond
Dołączył: 16 Wrz 2005 Posty: 566 Skąd: Bydgoszcz
Wysłany: Wto 22 Sie, 2006 11:21 Ustawienia sieciowe do CS-a
Wklejam cały tekst bo czasami takie stare stronki znikają z neta:
Cytat:
jak co ustawic aby wycisnac max z łącza
Author : _KaszpiR_
Poster : _KaszpiR_ Date : 2005-04-25 18:28
Comments : (0) Rating :
Bookmark page Articles
Ustawienia sieciowe graczy CS
Turorial przyblizy wam jak lepiej ustawic wartosci takie jak cl_cmdbackup
cl_rate, cl_updaterate , cl_cmdrate oraz rate aby lepiej wam sie gralo na serwerze
1. Opis zmiennych
2. Zakresy wartosci
3. Nasze łącze
4. Jak obliczac wartosci
5. Choke i Loss
6. Ex_Interp
7. Serwer
8. Zakonczenie
---------------------------------------------------------------------------------------------------
1. Opis zmiennych
---------------------------------------------------------------------------------------------------
Ramka oznacza 1 fragment informacji przeslany miedzy klientem a serwerem (niezaleznie w ktora strone).
Ilosc ramek z serwra do klienta kontroluje cl_updaterate oraz rate.
Ilosc ramek od gracza do serwera kontroluje cl_cmdrate i cl_rate.
cl_cmdrate - jest to liczba ile razy na sekunde gracz informuje serwer o swoich
poczynaniach, to jest - ruchach na mapie, strzelaniu, ruchach myszy
im wiecej robisz (im bardziej ostra akcja) tym wiecej danych wysylasz
cl_updaterate - jest to liczba ile razy na sekunde gracz otrzymuje z serwera dane o tym
co sie dooko³a niego dzieje - oznacza to ze dostajesz info jak leca granaty, kto gdzie strzela,
bryzgi krwi , dzwieki audio, efekty hud, latajace posicki, rykoszety itp.
jak jestes w miejscu gdzie ma³o sie dzieje (np nie ma graczy albo niewiele robia)
to otrzymujesz malo informacji
ale jak wbiegniesz w miejsce gdzie sie strzelaja 4 osoby i lataja granaty to dostajesz tych
informacji o wiele wiecej
cl_rate - ustawia maksymalny limit bajtow wyslanych od ciebie do serwera na temat twoich
poczynan i powinna byc ustawiona na maksymalna wartosc uploadu jaka mozesz wycisnac z łącza
rate - ustawia maksymalny limit bajtów odebranych przez ciebie jaie przychodza do serwera
powinna byc ustawiona na maksymalna wartosc download jaki mozesz wycisnac ze swojego ³±cza
cl_cmdbackup - ustawia ile ramek mozna przesylac ponownie jesli nam lacze nie wyrabia
np jak ma sie wysokie lossy albo choke
Dla nie kumatych:
cl_rate, cl_cmdrate
Gracz -------------->-->--> Server
rate, cl_updaterate
Gracz <--<--<---------------- Server
Ilosc danych od gracza przewaznie jest mala, mniej wiecej 25 bajtow na ramke.
natomiast serwer wysyla znacznie wiecej, jak sie nic nie dzieje jest to okolo 35bajtow na ramke,
a jak jest ostra akcja to dochodzi nawet do 176 bajtow na ramke albo i wiecej.
Dosc latwo sie przekonac ile danych wchodzi i wychodzi patrzac na net_graph
przyklad (oczywiscie u was moga byc inne wartosci)
Code:
77 fps 5ms
in: 34 1.48 k/s
out: 25 1.35 k/s
loss: 0 choke: 0
Pierwsza linia:
pierwsza liczba reprezentuje ilosc wyswietlanych FPS
druga liczba oznacza czas jakim sie rozni to co widzimy od tego co dostajemy od serwera
i co wysylamy do sewera (o tym nizej)
Druga linia:
reprezentuje dane wejsciowe jakie otrzymujesz z serwera.
Tu mamy wielkosc ramki 34 bajty, co przy danym cl_updaterate przelicza sie na 1.48 k/s downloadu.
Trzecia linia:
reprezentuje dane wyjsciowe jakie wysylamy do serwera.
Tutaj mamy rozmiar ramki 25 bajtow, a to sie przelicza przy tym cl_cmrdate na 1.35 k/s uploadu.
Najcze¶ciej informacje o naszym ³±czu mamy podane w kilobitach.
Najczêciej tak¿e podawane s± nam informacje o naszym maksymalnym downloadzie,a rzadziej o naszym
uploadzie, ktory czesto tez jest wazny.
Przewa¿nie upload mamy 4 albo 8 razy mniejszy niz download przy ³±czach ADSL (asynchroniczne)
ADSL to na przyk³ad sdi, neostrada, astercity, chello.. wiêkszosæ dostêpnych teraz ³±czy.
Takie ³±cze jest przeznaczone w³a¶nie dla graczy.
£±cza które maj± taki sam upload jak download s± to przewa¿nie SDSL (synchroniczne)
i s± znaczie dro¿sze niz asynchroniczne, ale takie ³±cze powinien w³a¶nie posiadaæ serwer.
Pamietajmy ze 8kb = 1B (8 kilobitów równa sie 1 bajt)
Powiedzmy ze masz modem 56k, weg specyfikaji oznacza to ze masz 56kbit downloadu i 33kbit uploadu.
Oznacza to stan idealny gdy nic nie zakloca linii.
W rzeczywistosci jakies 10% ³±cza idzie na dane dodatkowe - korekcja b³êdów, kontrola po³±czenia
wiêc warto¶ci jakie masz podane nie s± warto¶ciami realnymi tylko warto¶ciami teoretycznymi jakie
mozesz osi±gn±c - w rzeczywistosci osi±gasz mniej bo wp³ywa na to sam ruch sieci, jako¶æ kabli
pogoda, zak³ócenia elektromagnetyczne (komorki, radio) i wiele innych czynnikow.
Czyli mamy w rzeczywistosci 56/8 = 7kbajtow/s downloadu i 33/8 = niecale 5k/s downloadu.
Neostrada
jakies 768kbit downloadu i 128 kbit uploadu
Po przeliczeniu wychodzi jakies 96k/s downloadu oraz 16k/s uploadu
1mbit
1024/8 = 128k/s downloadu
2mbit
2048/8 = 256k/s downloadu
Reszte sobie sami przeliczcie.
---------------------------------------------------------------------------------------------------
4. Jak obliczyc wartosci
---------------------------------------------------------------------------------------------------
Najpierw sie zajmiemy wartosciami cl_rate i rate.
cl_rate:
Bierzemy nasz upload w bitach, mno¿ymy razy 0.9 a nastêpnie dzielimy przez 8.
Wynik powinien byc wartoscia jaka powinnismy usawic sobie w cl_rate.
Jak wychodzi liczba po przecinku to j± zaokr±glamy w dó³.
Jednak¿e warto¶ci± maksymaln± jak± mozemy wstawiæ jest 20 000, dlatego przy
³±czach które maj± lepszy upload ni¿ Neostrada (128kbit czyli 16k/s) powinnismy ustawic 20000
Przyklady
rate
Bierzemy nasz download maksymalny w bitach, mno¿ymy razy 0.9 a nastepnie dzielimy przez 8.
Czyli analogicznie jak przy cl_rate.
Wynik powinien byc wartoscia jaka powinnismy usawic sobie w rate.
Jak wychodzi liczba po przecinku to j± zaokr±glamy w dó³.
Jednak¿e warto¶ci± maksymaln± jak± mozemy wstawiæ jest 20 000, dlatego przy
³±czach które maj± lepszy download ni¿ Neostrada (768kbit czyli 16k/s) powinnismy ustawic 20000.
Przy Neostradzie poda³em gwiazdki - powinno sie wec ustawic 20000.
Teraz zajmiemy sie ustawieniem cl_cmdrate i cl_updaterate.
cl_cmdrate
Najlepiej gdy wezmiemy nasz cl_rate i podzielimy przez 25 (bo przewaznie tyle bajtow ma ramka).
Wtedy np dla Neostrady mamy:
14400 / 25 = 576 ale wartoscia maksymalna dla cmdrate jest 400
(wyzej nie ma co ustawiac, nie widac roznicy)
wiec ustawiamy cl_cmdrate 400
W rzeczywistosci najlepiej ustawic cl_updaterate rowny sredniej liczbie naszych fps w grze.
Jakustawimy wiecej to mozliwe ze serwer bedzie dropowal pewne dane ale ni powinnismy sie tym
przejmowac bo zostaja one wyslane kolejny raz.
cl_updaterate
Najlepiej gdy wezmiemy nasze rate i podzielimy przez 175 (bo tyle bajtow srednio ma ramka).
Np dla Neostrady mamy
20000 / 175 = 114 ale wartoscia maksymalna jest 100 wiec mozna spokojnie ustawic 100
uwaga, teraz warto popatrzyc na net graph
w pierwszej linii mamy dwie liczby
jesli widzimy tylko pierwsza (tzn fps) to jest ok
jesli widzimy druga takze to znaczy ze mamy pewne opoznienia w grze
maga byc one zwiazane z kilkoma rzeczami - m in. wydajnosci± naszego sprzêtu
liczba ta sie zwieksz ajak mamy np cl_updaterate i cl_cmdrate zbyt ekstremalne
(zarowno za male jak i za duze)
najlepieje tak zmieniac cl_updaterate i cl_cmdrate aby ta liczba
byla jak najmiejsza (1 cyfrowa) i pokazywala sie bardzo rzadko.
ta liczba oznaczac moze tez ze na serwerze moze byc ustawione sv_maxupdaterate
wtedy musimy u nas takze zmiejszac cl_updaterate i cl_cmdrate.
cl_cmdbdackup
Czasami ustawianie wartosci zmiennych cl_cmdrate i cl_updaterate powyzej ilosci fps serwera
moze okazac sie zbyteczne bo serwer ich nie przyjmie bo nie wyrobi.
Serwer srednio powinien miec 60-70 fps, dobre serwery maja powyzej 100.
najlepiej jest ustawic cl_cmdbackup jako cl_cmdrate / fps serwera
Serwery na LAN na mecze np ESL maja wysokie ustawienia (okolo 200fps) i dlatego daje sie
cl_cmdrate 400 a cl_cmdbackup 2
Na necie cl_cmdbackup jest standardowo 6 i jest parametrem wystarczajacym.
Jak ustawisz powyzej 60 to jest to bardzo duzo i prawdopodobnie mozesz zapchac sobie niepotrzebnie
lacze rzeczami czasem juz nieaktualnymi (jak serwer ma 60 fps a probujesz przepchnac 60 ramek to
znaczy ze chcesz czasem miec dane z calej osatniej sekundy)
Kiedys tlumaczylem ze cmdrate powinen byc 4x miejszy od updatrate - autor tekstu byl w bledzie
bo nie wzial pod uwage faktu ze ramka jest mniejsza w cmdrate
dlatego mzoa ustawic cmdrate 4 albo i wiecej razy wieksze niz updaterate
---------------------------------------------------------------------------------------------------
5. Choke i Loss
---------------------------------------------------------------------------------------------------
Choke
Choke procent danych jakie serwer albo klient powtrzymuje przed wyslaniem bo nie pozwalaja mu na
to ustawione parametry.
Po prostu przekroczone zostaly mozliwosci ³±cza na przesy³ danych.
Choke do wartosci 10 jest akceptowalny.
Najczesciej pojawia sie jak nasze rate jest zbyt niskie do podanego cl_updaterate.
Podobnie jesli mamy zbyt male cl_rate do zadeklarowanego cl_cmdrate.
W tym przypdaku powiniesmy najpierw sprawdzic czy nie przesadzilismy z cl_updaterate i cl_cmdrate
i je sukcesywnie zmiejszac podczas gry az choke zniknie podczas ostrych akcji.
Jesli to nie pomaga zmnijeszamy wartosci rate i cl_rate.
Na net graphie choke jest wyswietlany jako kolor ¿ó³ty w zielonym grafie (ten górny).
Loss
Loss wskazuje ile procent danych nie dotarlo do celu - oznacza ze cos jest zle z naszym ³±czem pod
wzglêdem technicznym.
Powinnismy takze wpierw obnizyc parametry opisywane w tym artykule.
Loss do wartosci 10 jest akceptowalny.
Na net graphie los jest wyswietlany jako kolor czerwony w zielonym grafie (ten górny).
ex_interp domyslnie ma wartosc 0.1 , i jego zmiana jest czesto blokowana przez takie
dodatki jak wwcl albo hlguard
wartosci powyzej 0.1 sa blokowane przez sama gre half-life
jak wpiszemu ex_interp 0 to powinno sie ex_interp saamo automatycznie obliczyc jako 1/cl_updaterate
ale w rzeczywistosci modele beda wtedy skakac i lepiej obliczyc to samemu wg ponizszego wzoru
ex_interp = (1/ cl_updaterate) +0.02
przy cl_updaterate 50, ex_interp powinien wiec wynosic jakies 0.04
patrz±c na net_graph widzimy dolny pasek (niebiesko ¿ó³ty)
najepiej tak ustawic ex_interp az nam sie nie pokazuj± ¿ó³to-czerwone fragmentu w graphie
i wtedy mamy tylko fioletowo niebieski wykres.
Na serwerze admin moze ustawic zmienne aby forsowac pewne wartosci.
Dlaczego? Aby na przyklad nie placic za ³±cze wiêcej ni¿ go stac.
Ponizsze wartosci kontroluja wartosci jakie gracze moga u siebie maksymalnie ustawic.
Oznacza to ze jesli gracz ma wartosc wieksza niz ta ktora jest dana w parametrze sv_
to nie bedzie on z niej korzystal, bo serwer bedzie wywyslal wartosci ze swoich usatwien.
Przyklad:
cl_updaterate 100
sv_maxupdaterate 50
w efekcie gracz bedzie dostawal 50 update na sekudne a nie 100 jak sobie zadeklarowal - oznacza to
ze serwer mu bedzie wysylal mniej danych niz on chcialby dostawac - co dla niego nie jest ustawieniem zadowalajacym.
Wiec klient recznie musi sobie ustawic cl_updaterate 50.
Przy wysokim cl_updaterate i innych parametrach mozna zauwazyc ze mozna miec upload do serwera
wiekszy lub rowny downloadowi z serwera.
Przwaznie nie trzeba sie tym przejmowac, ale nalezy miec na uwadze ze serwer otrzymuje od innych graczy
takze dane ale ³±cze na serwerze powinno dac sobie rade bo dla niego upload clientow jest
jego downloadem z netu. Ale trzeba pamietac ze serwer moze sam odrzucac zbyt czeste dane od klientow.
---------------------------------------------------------------------------------------------------
by _KaszpiR_ 20-04-2005 ver 0.7 http://nvt.prv.pl
---------------------------------------------------------------------------------------------------
Lub to:
Cytat:
CS 1.6 Netcode in Polish
same as the article with similiar title but on my native language.
Author :
Poster : _KaszpiR_ Date : 2004-05-12 09:28
Comments : (1) Rating :
Bookmark page Articles
1.6 Netcode Explained po Polsku (tlumaczenie by _KaszpiR_ http://nvt.prv.pl )
Artykul byl najpierw dostepny ogolnie na Gotfrag.
Nastepnie stal sie tzn Prime - czyli widocznym tylko dla zarejestrowanych.
Coz, ale google.com przeszlo przez niego i zrobilo cache - dlatego bez obrazka, ale liczy sie tresc.
A ja pozwolilem sobie to przetlumaczyc, ale bez zbytniego lania wody zostawiajac esencje. Dodatkowo troche zmienilem uklad aby tresc nie byla tak poszatkowana jak w oryginale - wiec opisy zmiennych/komend sa razem a nie osobno (co wprowadzalo w pewne zaklopotanie coponiektorych )
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
W artykule zapoznasz sie z tzw. netkodem gry Half-Life, czyli ta czescia gry ktora odpowiada za protokol sieciowy itp.
Mam nadzieje, ze pomoze ci on lepiej ustawic wartosci aby osiagnac lepsze wykini w grze, jak i usprawnc serwer.
Notka:
Komendy/zmienne zaczynajace sie od sv_ czy tez sys_ sa komendami/zmiennymi dzialajacymi tylko na serwerze - dedykowanym czy tzw listen.
Wykonanie powyzszych komend w konsoli u klienta zwroci ustawienia na lokalnym komputerze a nie na serwerze.
Dlatego tez trzeba te komendy wpisywac albo w konsoli hlds bezposrednio (jak jest na screen'ie itp., albo wraz z uzyciem komendy rcon,
albo z uzyciem rcon zastepczych komend/aplikacji dzialajacych na serwer - mam tu na mysli komendy typu amx_rcon czy cm_rcon.
Zaleznosc miedzy komenda ex_interp a cl_updaterate jest bardzo wazna i prosimy nie czytac tylko jednego opisu,
tylko przeczytac tez info o drugiej komendzie.
Ogolnie przeczytaj wszystko aby miec ogolny zarys tego, co sie dzieje jak sie bawimy kilkoma komendami na raz.
Artykul oryginalnie byl napisany dla osob o szerokopasmowym dostepie do internetu.
W naszych warunkach czytaj - cos lepszego niz SDI, najlepiej Neostrada i temu podobne.
Najpierw ogolny opis komend/zmiennych a potem szczegoly, wiec sie nie wkurzac ze 2x to samo czytacie - oryginalny artykul byl bardziej poszatkowany.
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
rekomendujemy cl_cmdrate rowne fps serwera lub troche wieksze
dlatego na serwerach linuksowych czesto jest 50 a na widowsowych 70
oczywiscie jak serwer ma wiecej fps to walimy 100 i sie cieszymy
cl_updaterate
podobna do poprzedniej komendy ale dziala w odwrotnym kierunku.
numer definiuje maksymalna liczbe pakietow na sekunde jaka ty mozesz otrzymac od serwera.
wiecej znaczy lepiej ale tez zwieksza uzycie lacza.
traktuj to jak efekt blyskawicy - ktos strzela to nastepuje blysk (widoczny dla serwera natychmiast),
jednakze ty jestes nastawiony na grzmot.
im wieksza wartosc tym szybciej do ciebie grzmot dojdzie (wiem wiem, lopatologicznie...)
Po prostu szybciej bedziesz mogl zareagowac.
Dodatkowo daje to dokladniejsze informacje o rzeczywistym polozeniu przeciwnikow, trafien po kulach itp.
Wartosc maksymalna zalezy od twojego downstream'u czyli jak szybko mozesz zasysac od provider'a.
Przewaznie ta wartosc (mam na mysli downstream) jest 4x wieksza od twojego upstream'u
Dlatego czasem cl_updaterate jest wiekszy 4 razy od cmdate
Minimalna wartosc jest 10 (dlatego ex_interp ma 0.1, patrz nizej)
kiedys myslano ze cl_updaterate trza walnac na 101 i zjezdzac w dol. z wartosciami az bedziemy mieli w miare niski
i zadowalajacy choke (prawie zero ale moze byc 2...3)
choke widac na net_graph 3
jednak caly system cl_updaterate jest bardziej zlozony.
np. serwery CAL daja sv_maxupdaterate 101 wiec normalnie kazdy by se tyle dal na kliencie.
w teorii jest to poprawne jednak praktyka sie tu rozmija.
wiekszosc serwerow nie wyciaga 100fps aby obliczyc te wlasnie 100 updaterate na sekunde.
oznacza to ze nie ma szans aby serwer tyle wyslal w rzeczywistosci.
Pomyslisz - walne se 101 updaterate i tak czy siak tyle max pakietow dostane.
Jak u siebie dasz cl_updaterate 101 to ex_interp bedzie 0.009ms - spodziewa sie gra ze bedziesz mial pakiety co 9ms
i wszystko bedzie cacy.
jednakze serwer ma 50 fps czyli maksymalnie pusci 50 pakietow!!! tak wiec 2 razy mniej.
co sie stanie?
pakiety przychodza za rzadko i gra nie ma z czego interpolowac polozenia graczy - masz efekt skaczacych modeli.
no dobra. dajmy na to ze zjade na 70 - efekt skaczacych modeli spadnie.
oczywiscie idealnie jak bedziemy mieli cl_updaterate 50 - wtedy iterp bedzie 0.02 i modele nie powinny az tak skakac (tylko z rzadka z powodu lagow)
poniewaz klient bez rcon'a nie ma jak sprawdzic ile serwer ma fps i se dobrze dobrac te zmienna, trzeba zgadywac.
na szczescie mozna to zrobic doswiadczalnie w prostu sposob.
1. zacznij z cl_updaterate 101, ex_interp 0
2. zjezdzaj z cl_updaterate w dol. (mniej wiecej o 10 ) az zauwazysz ze modele az tak bardzo nie skacza. (tylko z rzadka z powodu zmiany pinga, lagow itp.)
oczywiscie "bardzo nie skacza" to kwestia gustu.
dopoki ex_interp = 1/cl_updaterate modele beda na wioch rzeczywistych miejscach.
oznacza to ze kazdy serwer bedzie mial swoje wlasne ustawienia cl_updaterate zalezne od ilosci graczy/lacza/fps - po prosu ile w danej chwili serwer moze z siebie wycisnac.
nie bojmy sie zejsc z wartosciami ponizej updaterate 50 bo tak czy siak interpolacja bedzie dzialac.
no dobra, ktos pomysli, ale ja wezme updaterate 20 i bede szedl w gore.
no to nie jest dobry pomysl bo ex_interp = 1/cl_updaterate
jak mamy 20 to ex_interp = 1/20 = 0.05
a jak zwierzymy na 50 to mamy ex_interp = 1/50 = 0.02
a ex intern 0.05 > 0.02 a H-L domyslnie nie zmniejsza sam z siebie interna.
wtedy musisz wystukac za kadmy razem ex_interp 0 recznie aby obliczyc go.
tak wiec widac ze istnieje zaleznosc pomiedzy serwer fps, cl_udpaterate i ex_interp 0 razem.
najlepiej miec updaterate rowny fps serwera a ex_interp 0
Rekomendacja:
cl_updaterate rowny fps serwera i nie wiekszy od sv_maxupdaterate.
koncowa notka. wiele serwerow uzywa sv_maxupdaterate 30 tak wiec cl_updaterate 30 bedzie wtedy wartoscia najlepsza w
takiej sytuacji.
sv_maxupdaterate
Jak cl_maxupdaterate ale zdziala na serwer - ile klient maksymalnie moze przyjac od serwera.
Szczegolnie uzyteczna jak serwer nie ma za dobrego lacza.
Numer oznacz liczbe pakietow na sekunde jaka serwer moze wyslac.
sv_maxupdaterate specifies the maximum number of packets per second a server is allowed to send.
Dlatego jesli klient ma cl_updaterate 100, a serwer ma sv_maxupdaterate 50,
to ten klient i tak nie dostanie wiecej niz. te 50.
sys_ticrate
Definiuje ile maksymalnie klatek na sekunde moze wyciagnac serwer.
Domyslnie jest 100, maksymalnie 10 000
Po co to komu?
Miedzy innymi wiecej fps daje ci lepsze poczucie gry.
Serwery normalnie maja okolo 50fps na linuksie i 64 na widowsach - ale czasem spada to do 20-30 to juz slabo.
Dobre serwery maja tak ustawione ten ticrate aby fps sie wahalo w granicy 150-180 fps(tzn. ogolnie do 200fps)
Wiecej i tak ci nic nie da bo nie zauwazysz.
Czasem ta komenda nie dziala na nieskorych platformach.
dodatkowo im wiekszy ticrate tym wieksze uzycie procka.
Czasem na mapach de_inferno i de_aztec uzycie procka skacze czasem do szalonych wartosci - ale to mowie - czasem.
Oczywiscie najlepiej aby miec w miare stabilny poziom fps - bo skoki z 100 do 500 i po chwili znowu na 100 nie sa
przyjemne i wszystko raczej dziala gorzej - to zalezy od hardware'u
Wiec lepiej aby miec mniej ale z mniejszymi fluktuacjami.
Jak masz dostep do rcon to mozesz sprawdzic aktualne fps na serwerze wpisujac
rcon stats
Aby sprawdzic jakiego kopa dostanie serwer na chwile wlacz
rcon sys_ticrate 10000
Jest teraz sprawdzisz rcon status i twoj serwer ma powyzej 100fps to znaczy ze boosting dziala i sie ciesz,
inaczej szukaj innych metod poprawy dzialania sprzetu
Zawsze sprawdz statusy kilka razy
ex_interp
interpolacja czyli przyblizenie wartosci korzystajac z co najmniej 2 wartosci granicznych
np. srednia ocen w szkole to interpolacja ....
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
Przewaznie w CS mamy wielokat o 20 bokach no i tu widac ze nie zawsze pozycja gracza jest pozycja realna gracza.
Na szczescie do gry to starcza gdyz dziala interpolacja - wszelkie pozycje gdzie nie masz informacji gdzie sie znajduje gracz sa interpolowane.
Po prostu modele na ekranie nie skacza, tylko poruszaja sie plynnie bo sa interpolowane bazujac na pakietach jakie otrzymujesz od serwera.
oznacza tu przedzial czasowy do wykorzystania przez gre - jako ulamek sekundy.
Domyslnie jest to maksymalnie 0.1 Czyli 100 ms - oznacza to ze jesli nie dostaniesz pakietu o polozeniu gracza w ciagu 100ms to H-L bedzie
Obliczal gdzie on sie znajduje.
normalnie ex_interp powinien byc rowny lub troszke wiekszy od 1/cl_updaterate
natomiast niektorzy rekomenduja ex_interp 0
wtedy H-L sam obliczy te wartosc i ci powie ze "ex_interp forced to msec"
tylko ze jest problem
1. jak zmieniasz jakkolwiek cl_updaterate to potem musisz wywolac ex_interp 0 aby to obliczyl
2. jak masz ex_interp 0 to modela moga zaczac skakac - bo pakiety sie spozniaja, to normalne.
maksymalnie ex_interp ma 0.1 czyli 100 milisekund - to jest duzo
najczesciej jak masz cl_updaterate 20 to masz ex_interp 0.05
oczywiscie im wiekszy update tym mniejsza liczba
niektorzy tylko rekomenduja operowanie cl_updaterate i zostawianie ex_interp'a w spokoju aby sam sie kalkulowal... no ale jestesmy na polskich laczach...
czasem wartosci ex_interp ponizej 1/cl_updaterate nie da sie ustawic.
czasem wartosci powyzej 1/cl_updaterate sa uwazane za exploit gdyz powoduje z musisz strzelac za rzeczywistym modelem
dlatego jest efekt spozniony headshot'ow - koles przebiegl, ty strzeliles gdzie on "byl" i dostal heda, a krew sika z pustki
ja sugeruje popatrzec ile ex_interp 0 wyliczy i potem dodac recznie +0.01
np. cl_updatertae 20
ex_interp 0.05
dodajemy i mamy ex_interp 0.06
efektu spoznionych hedow nie powinno byc tak wiele i modele nie powinny az tak bardzo skakac - no chyba ze lagi
natomiast modele nie biegaja na tyle wczesnie aby inni uwazali ze oszukujesz.
ja uwazam ze dodanie 0.01 to nie jest expliotem bo netcode nie jest idealny, szczegolnie jak na polskie warunki
moim zdaniem exploitem jest jak gracz ma cl_updaterate 101 i wtedy powinien miec ex_interp 0.009 (no powiedzmy 0.01) a w rzeczywistosci uzywa ex_interp 0.1 czyli 10x wiekszego!!!
ostateczna rekomendacja
ex_interp 0
rate
jest to ile bajtow mozesz przeslac do serwera. maksymalnie jest 20000, bo wyzej H-L nie wyciagnie.
standardowo jest chyba 5000 albo i mniej ale np. clanbase uzywa 9999.
rekomendujemy zatem albo 9999 albo 20000 jesli serwer pozwala.
sv_maxrate
domyslnie jest rowne 0 co nie oznacza ze jest najlepiej.
Dlaczego?
sv_maxtrate 0 wykryje rate kazdego gracza i bedzie sie staralo spelnic wymogi gracza.
teraz zalozmy ze H-L daje mozliwosc dania rate powyzej 20 kafli, a jakis gracz ma fantazje
i walnie ostra wartosc np. 9999999999 (kosmiczna liczba)
serwer w tym przypadku probowalby wypchac te kosmiczna ilosc danych do tego gracza i tylko by marnowal lacze do tej osoby bo i tak tyle nie wysle
a reszta bedzie lagowana bo nie dostanie nic.
dlatego lepiej jest ustawiac sv_maxtrate na 20000.
moze sie wydawac ze to nie ma sensu ale chyba mozna sie po valve spodziewac wszystkiego od czasow steam.
sys_ticrate:
znajdowanie optymalnej wartosci wymaga troche eksperymentow.
najpierw sprawdz czy serwer jest boots'owany, bo inaczej nic ci to nie da.
pamietaj ze podnoszenie fps powyzej 200 jest zbyteczne ze wzgledow mozliwosci samej gry i laczy internetowych.
dodatkowo wyciskanie za duzo fps na maszynie ktora ma kilka serwerow hlds na sobie jest niekorzystne dla innych serwerow
spowoduje to tylko pogorszenie gry na obu serwerach bo procesor nie bedzie wyrabial.
nie zapominaj ze czesto na serwerach dziala tez www , mail i ftp.
dodatkowo nie kazdy wie ze czasem serwer fps wskazuje na niektore tylko wartosci albo po prostu dziala na innych
np. na jednej z maszyn zaobserwowano ze fps ukladaja sie tak: 85, 102, 128, 170, 256 ...
i zadnych fps (liczb) miedzy nimi.
wiec jak damy w tym przypadku sys_ticrate 100 to serwer bedzie dzialal na predkosci nizszej ni zapodana
w typ wypadu bedzie to 85 fps
dlatego lepiej jest dawac sys_ticrate zwiekszone o 20 do 50 fps niz. te ktora chcesz osiagnac
np. moze sie zdarzyc ze masz sys_ticrate 150 a serwer bedzie wyciagal tylko 128 fps.
rekomendowane:
sys_ticrate 110 - 180 w zaleznosci od mozliwosci twojego sprzetu.
No a jak grac na LAN'ie
organizacje typu CPL uzywaja cl_updaterate 101 gdyz to sie wiaze z jakoscia serwowanych przez nich serwery - silne maszyny z booster'ami.
aby latwo sie przekonac czy serwer na lanie jest z booster'em - popatrz na ping graczy z lan'u.
normalny serwer bez booster'a na 60-65 fps powoduje ze gracze maja pingi powyzej 15ms
natomiast jak serwer ma wiecej fps i ma booster'a to pingi sa o wiele mniejsze - przewaznie w granicy 5ms.
Wiadomo ze CPL, ESWC i WCG uzywaja serwerow z booster'ami.
Special thanks to:
Alfred Reynolds, Valve Software
Yahn Bernier, Valve Software
Zibbo, UDPSoft
The HLDS Mailing Lists
The server.counter-strike.net forums
Nie możesz pisać nowych tematów Nie możesz odpowiadać w tematach Nie możesz zmieniać swoich postów Nie możesz usuwać swoich postów Nie możesz głosować w ankietach
)
