CS 1.6 Netcode Po Polsku - Historia wersji

D4rk o 12:25, 6 lip 2007

2007-07-06T12:25:45Z

D4rk o 12:20, 6 lip 2007

2007-07-06T12:20:53Z

D4rk o 12:14, 6 lip 2007

2007-07-06T12:14:10Z

Pokaż zmiany

D4rk o 11:57, 6 lip 2007

2007-07-06T11:57:52Z

D4rk o 11:47, 6 lip 2007

2007-07-06T11:47:31Z

Pokaż zmiany

D4rk o 11:37, 6 lip 2007

2007-07-06T11:37:26Z

D4rk: status -> stats

2007-07-06T11:31:41Z

status -> stats

KaszpiR: dodałem sekcje o fps_max

2007-05-21T18:04:06Z

dodałem sekcje o fps_max

KaszpiR: /* sys_ticrate */

2006-09-08T19:55:09Z

sys_ticrate

KaszpiR: /* sys_ticrate */

2006-09-08T19:52:24Z

sys_ticrate

@@ Linia 12: / Linia 12: @@
 Artykuł był najpierw dostępny ogólnie na Gotfrag.
-Następnie stal się tzw Primie - czyli widocznym tylko dla zarejestrowanych.
+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ść.

@@ Linia 54: / Linia 54: @@
 '''Rekomendujemy''' cl_cmdrate równe fps serwera lub trochę większe.
-Dlatego na serwerach linuksowych często jest 50 a na widowsowych 70
+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
@@ Linia 126: / Linia 126: @@
 ==sv_maxupdaterate==
-*Jak cl_maxupdaterate ale dziala na serwer - ile klient maksymalnie może przyjąć od serwera.
+*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.
@@ Linia 143: / Linia 143: @@
 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).
+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.
@@ Linia 151: / Linia 151: @@
 *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
+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.
@@ Linia 161: / Linia 161: @@
 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.
+*Zawsze sprawdź stats kilka razy.
 Znajdowanie optymalnej wartości wymaga trochę eksperymentów.
@@ Linia 226: / Linia 226: @@
 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 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
@@ Linia 232: / Linia 232: @@
 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.
+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 wiekszego!!!
+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 hego blokowanie zmiennych nie będzie tak uciążliwe.
+ex_interp 0.1 czyli nie dotykać - wtedy HLGuard i jego 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.
+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 uzywa 9999.
+standardowo jest chyba 5000 albo i mniej ale np. clanbase używa 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.
+'''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==
-Domyslnie jest rowne 0 co nie oznacza że jest najlepiej.
+Domyślnie jest równe 0 co nie oznacza że jest najlepiej.
 Dlaczego?
-sv_maxrate 0 wykryje rate kazdego gracza i bedzie się staralo spełnic wymogi gracza.
+sv_maxrate 0 wykryje rate każdego gracza i będzie się starało spełnić 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).
+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 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.
+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śći sv_maxrate możemy przewidywać maksymalne uzycie łącza na miesiąc - jesli płacimy z atransfer w GB.
+*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 ustawiac sv_maxrate na 20000.
+'''Rekomendujemy''' dlatego ustawiać 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.
+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 latwo się przekonac czy serwer na lanie jest z booster'em - popatrz na ping graczy z lan'u.
+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 powyzej 15ms.
+*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 sa o wiele mniejsze - przewaznie w granicy 5ms.
+*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 uzywaja serwerow z booster'ami bo ich na to stać.
+Wiadomo że CPL, ESWC i WCG używają serwerów z booster'ami bo ich na to stać.
 =Podziękowania=

@@ Linia 15: / Linia 15: @@
 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 )
+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
@@ Linia 36: / Linia 36: @@
 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.
+*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=
@@ Linia 51: / Linia 51: @@
 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
+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.
@@ Linia 80: / Linia 80: @@
 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.
+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.
@@ Linia 89: / Linia 89: @@
 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.
+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 przychodza za rzadko i gra nie ma z czego interpolowac polozenia graczy - masz efekt skaczacych modeli.
+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 zjade na 70 - efekt skaczacych modeli spadnie.
+No dobra. dajmy na to że zjadę na 70 - efekt skaczących 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)
+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)
-*Poniewaz klient bez rcon'a nie ma jak sprawdzic ile serwer ma fps i se dobrze dobrac te zmienna, trzeba zgadywac.
+*Ponieważ klient bez rcon'a nie ma jak sprawdzić ile serwer ma fps i se dobrze dobrać tę zmienną, trzeba zgadywać.
-Na szczescie mozna to zrobic doswiadczalnie w prostu sposob.
+Na szczęście można to zrobić doświadczalnie w prosty sposób.
 . zacznij z cl_updaterate 101, ex_interp 0
-. 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.)
+. 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.)
-Oczywiscie "bardzo nie skacza" to kwestia gustu.
+Oczywiście "bardzo nie skaczą" to kwestia gustu.
-Dopoki ex_interp = 1/cl_updaterate modele beda na wioch rzeczywistych miejscach.
+Dopóki ex_interp = 1/cl_updaterate modele będą na swioch 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.
+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 bojmy się zejsc z wartosciami ponizej updaterate 50 bo tak czy siak interpolacja bedzie dzialac.
+Nie bójmy się zejść z wartościami poniżej updaterate 50 bo tak czy siak interpolacja będzie działać.
-No dobra, ktos pomysli, ale ja wezme updaterate 20 i bede szedl w gore.
+No dobra, ktoś pomyśli, ale ja wezmę updaterate 20 i będę szedł w gore.
-No to nie jest dobry pomysl bo ex_interp = 1/cl_updaterate.
+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 domyslnie nie zmniejsza sam z siebie interna.
+a ex intern 0.05 > 0.02 a H-L domyślnie nie zmniejsza sam z siebie interna.
-wtedy musisz wystukac za kadmy razem ex_interp 0 recznie aby obliczyc go.
+wtedy musisz wystukać za kadmy razem ex_interp 0 recznie aby obliczyć go.
-tak wiec widac że istnieje zaleznosc pomiedzy serwer fps, cl_udpaterate i ex_interp 0 razem.
+tak więc widać że istnieje zależność pomiędzy serwer fps, cl_udpaterate i ex_interp 0 razem.
-najlepiej miec updaterate rowny fps serwera a ex_interp 0
+najlepiej mieć updaterate równy fps serwera a ex_interp 0
 '''Rekomendacja:'''
-cl_updaterate rowny fps serwera i nie wiekszy od sv_maxupdaterate.
+cl_updaterate równy fps serwera i nie większy od sv_maxupdaterate.
-Koncowa notka: wiele serwerow uzywa sv_maxupdaterate 30 tak wiec cl_updaterate 30 bedzie wtedy wartoscia najlepsza w
+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.
@@ Linia 166: / Linia 166: @@
 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 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 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.
+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
@@ Linia 175: / Linia 175: @@
 i zadnych fps (liczb) miedzy nimi.
-Wiec jak damy w tym przypadku sys_ticrate 100 to serwer bedzie dzialal na predkosci nizszej ni zapodana
+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 bedzie to 85 fps
+w typ wypadu będzie to 85 fps
-Dlatego lepiej jest dawac sys_ticrate zwiekszone o 20 do 50 fps niz. te ktora chcesz osiagnac
+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.
@@ Linia 203: / Linia 203: @@
 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
+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.

@@ Linia 24: / Linia 24: @@
 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.
+*'''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 tez trzeba te komendy wpisywać albo w konsoli hlds bezpośrednio (jak jest na screen'ie itp., albo wraz z użyciem komendy rcon,
+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ć tez info o drugiej komendzie.
+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 - cos lepszego niż SDI, najlepiej Neostrada i temu podobne.
+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.
@@ Linia 40: / Linia 40: @@
 =Ogólnie o zmiennych=
 ==cl_cmdrate==
-*definiuje ile maksymalnie pakietow moze wyslac klient (tzn. ty, graczu ze swojej maszyny) do serwera.
+*definiuje ile maksymalnie pakietów może wysłać klient (tzn. ty, graczu ze swojej maszyny) do serwera.
-*numer oznacza liczbe pakietow na sekunde
+*numer oznacza liczbę pakietów na sekundę
-Oczywiscie wiecej znaczy lepiej - szybciej serwer zareaguje na twoje reakcje.
+Oczywiście więcej 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.
+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 lacze i siedzisz na laczu sam to spoko mozesz zwiekszyc.
+Jak masz dobre łącze i siedzisz na łączu sam to spoko możesz zwiększyć.
-Jak wspoldzielisz z kims lacze (np. neo na 2 osoby) to zbyt wysokie wartosci u obu graczy beda powodowac nagle lagi i ping spike.
+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.
-Warotsc maksymalna zalezy tu od tego jaki masz upstream do provider'a - czyli ile mozesz wyslac w internet.
+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 rownac liczbie fps serwera!!! a nie klienta.
+W idealnym przypadku ta komenda powinna sie równać liczbie fps serwera!!! a nie klienta.
-Jak wyslesz wiecej pakietow to serwer je po prostu zignoruje bo nie bedzie wyrabiac.
+Jak wyślesz więcej pakietów to serwer je po prostu zignoruje bo nie będzie wyrabiać.
-Tak wiec za wysokie wartosci nie zaszkodza ale tylko beda marnowac twoje lacze :D
+Tak wiec za wysokie wartości nie zaszkodzą ale tylko będą marnować twoje łącze :D
-'''Rekomendujemy''' cl_cmdrate równe fps serwera lub troche wieksze.
+'''Rekomendujemy''' cl_cmdrate równe fps serwera lub trochę większe.
-Dlatego na serwerach linuksowych czesto jest 50 a na widowsowych 70
+Dlatego na serwerach linuksowych często jest 50 a na widowsowych 70
-oczywiscie jak serwer ma wiecej fps to walimy 100 i sie cieszymy
+oczywiście jak serwer ma więcej fps to walimy 100 i sie cieszymy
 ==cl_updaterate==
-*podobna do poprzedniej komendy ale dziala w odwrotnym kierunku.
+*podobna do poprzedniej komendy ale działa w odwrotnym kierunku.
-*numer definiuje maksymalna liczbe pakietow na sekunde jaka ty mozesz otrzymac od serwera.
+*numer definiuje maksymalna liczbę pakietów na sekundę jaka ty możesz otrzymać od serwera.
-*wiecej znaczy lepiej ale tez zwieksza uzycie lacza.
+*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),
@@ Linia 148: / Linia 148: @@
 <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.
+*Czasem ta komenda nie działa na niektórych platformach.
-*Im wiekszy ticrate tym wieksze uzycie procesora.
+*Im większy ticrate tym większe użycie procesora.
-Czasem na mapach de_inferno i de_aztec uzycie procka skacze czasem do szalonych wartosci - ale to mowie - czasem.
+Czasem na mapach de_inferno i de_aztec użycie 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
+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 dziala gorzej - to zalezy od hardware'u
+przyjemne i wszystko raczej działa gorzej - to zależy 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
+*Jak masz dostęp do rcon to możesz sprawdzić aktualne fps na serwerze wpisując
   rcon stats
-Aby sprawdzic jakiego kopa dostanie serwer na chwile wlacz
+Aby sprawdzić jakiego kopa dostanie serwer na chwile włącz
   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
+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 sprawdz statsy kilka razy.
+*Zawsze sprawdź statsy kilka razy.
 Znajdowanie optymalnej wartosci wymaga troche eksperymentow.
@@ Linia 169: / Linia 169: @@
 </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.
+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

@@ Linia 159: / Linia 159: @@
 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
+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 statusy kilka razy.
+*Zawsze sprawdz statsy kilka razy.
 Znajdowanie optymalnej wartosci wymaga troche eksperymentow.
@@ Linia 192: / Linia 192: @@
   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ą '''status'''
+* 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==

@@ Linia 187: / Linia 187: @@
 '''Rekomendujemy''' sys_ticrate 125, ale lepiej nie przekraczac 200.
 ==ex_interp==
 *interpolacja czyli przyblizenie wartosci korzystajac z co najmniej 2 wartosci granicznych

@@ Linia 145: / Linia 145: @@
 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 niektorych platformach.

@@ Linia 136: / Linia 136: @@
 ==sys_ticrate==
-*Definiuje ile maksymalnie klatek na sekunde moze wyciagnac serwer.
+*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.