f·p·p · p·r·o·d·u·c·t·i·o·n·s   GRY | SERWERY GIER | BANNERY
 



 
 


rtcw.fpp.pl
Podłącz nasz
baner
 





  f·p·p · r·t·c·w | Columns | [FPP]Vk | Antilag

[FPP]Vk

Antilag

Tłumaczenie artykułu panów z =CompKal= FragCenter utwierdzający w przekonaniu, że AntiLag powinien być włączony na serwerach.

Po pierwsze, jestem jednym z administratorów =Compkal= Fragcenter. Ponieważ wszystkie dyskusje o dobrym i mniej dobrym czasie przepływu pakietów UDP do serwerów RTCW (chodzi o ping :)) zaczynały grać mi na nerwach, postanowiliśmy się temu bliżej przyjrzeć.

Stworzyliśmy takie oto środowisko dla naszych testów:

RtCW1 <-- LAN --> RtCW_Serwer <-- ADSL --> Internet <-- modem 56k --> RtCW2

Przy czym RtCW1: AMD Athlon XP 1.800+, 1 GB Ram, GeForce4 MX400 64 MB, ping [<20ms do serwera] RtCW_Serwer: serwer "dedicated" I RtCW2: Notebook, Pentium 600 MHz, 256 Ram, 53 Mobility16 MB, 56k V.90 Modem, ping [~225ms do serwera]

Postawiliśmy oba komputery (RtCW 1 i RtCW2) blisko siebie, aby uzyskać wrażenie wzrokowe,czyli np. jeśli figurka na RtCW1 się poruszy, po jakim czasie zobaczymy to na RtCW2, albo jeśli zostanie użyty Voice Chat na RtCW1 (np. v54/vGH), po jakim czasie usłyszymy na RtCW2 Hello!.

Po pierwszym teście właściwie moglibyśmy już je zakończyć. Powód jest prosty: wynik testu jest taki sam jak wynik końcowy wszystkich testów, które później przeprowadziliśmy. ABSOLUTNA SYNCHRONICZNOŚĆ!!!

W drugim teście strzelaliśmy z RtCW1, celując prosto w gracza na RtCW2 i staraliśmy się uniknąć kul na RtCW2. Wynik następujący: Każdy strzał trafiał!!! Powtarzaliśmy ten test kilka razy w obie strony i otrzymywaliśmy zawsze ten sam rezultat, (nawet ping 250ms nie miał żadnego wpływu ani na trafienia, ani na 'omijanie' kul).

W kolejnym teście zmieniłem konfigurację:

RtCW1 <-- ISDN64k --> Internet <-- ADSL --> RtCW_Serwer <-- ADSL --> Internet <-- modem56k --> RtCW2

Przy czym RtCW1 ping [~90ms do serwera] a RtCW2 ping [~225ms do serwera].

Wzrokowo nic się nie zmieniło na obu systemach. Wynik testu Voice Quick Chat był taki sam jak w naszym pierwszym teście.

W ostatnim teście umieściłem obu graczy (RtCW1 i RtCW2) naprzeciwko siebie i zanim zacząłem strzelać RtCW1 w kierunku RtCW2, wyłączyłem internet wyjmując na chwilę wtyczkę sieciową z RtCW2. Spowodowało to gwałtowny lag na obu systemach (RtCW1 & 2). Zanim znów podłączyłem Internet przestałem strzelać w gracza RtCW2. Wynik następujący: RtCW1 nic nie wystrzelił (amunicja była wciąż pełna) a RtCW2 niczym nie 'oberwał' (nadal 100 życia).

Ale jak to możliwe???

Powód jest prosty i ciekawy: RtCW_Serwer musi posiadać coś w stylu bramkowania czasu synchronizacji (lub taktu/rytmu) [ang. time synchronization gating (or beat), proszę się nie śmiać, tylko napisać jak to przetłumaczyć :)], które jest wysyłane do wszystkich systemów podłączonych graczy. W naszym przypadku do RtCW1 i RtCW2. Systemy graczy wysyłają ich informacje kontrolne, zawierające rytm czasu synchronizacji, do serwera RtCW. Teraz serwer oblicza wszystkie informacje z systemów graczy, jedynie z niewielkim 'przekłamaniem' (pszesunięcie czasu). [dopóki wszystkie pakiety nie osiągną celu w czasie przeznaczonym na to przez serwer]. Potem serwer rekalkuluje co się stało.. gdzie to miało miejsce.. gdzie jest każdy gracz.. kto strzelił.. kto 'oberwał'.. kto coś mówił... itd. i wysyła rezultat swojej pracy do wszystkich podłączonych graczy (w naszym przypadku do RtCW1 & 2). Systemy graczy oceniają(?) wynikowe pakiety i ukazują na monitorze, co się stało.. gdzie to miało miejsce.. gdzie jest każdy gracz.. kto strzelił.. kto 'oberwał'.. kto coś mówił... itd. To również wyjaśnia, czemu gracz z extremalnie niskim pingiem ma czasami wrażenie laga. Serwer czeka określony czas (max. 400ms) i dopiero wtedy wysyła graczom pakiety. Jeśli jakieś pakiety dotrą trochę za późno, informacje te zostaną dołączone do bieżącego taktu czasu synchronizacji. (Widać to podczas chodzenia - efekt elastycznej taśmy).

Wniosek: Grając w RtCW z patchem 1.4 na serwerach z włączonym AntiLagiem, żaden gracz nie będzie miał jakiejkolwiek przewagi ani niekorzyści, niezależnie od pingu. Jeśli jednak gracz ma trwały ping >400ms, zobaczy on na ekranie Connection Interrupted i będzie tak stał i bluzgał na dostawcę. Ale nie może zostać skrzywdzony przez żadnego gracza, jak i sam nie może skrzywdzić innych. Jedynie kiedy system gracza ma taki sam rytm jak bramkowanie czasu synchronizacji na serwerze, będzie mógł ponownie wkroczyć do gry. To dlatego ewntualne próby czitowania graczy (np. nieskończona amunicja czy niesmiertelność) nie są możliwe. Serwer dyktuje, kto ma ile amunicji i kto ma ile życia.

Funkcja AntiLag w patchu RtCW 1.4 (protokół 60) nie może jednak uniknąć lagów całkowicie. Jeśli kogoś połączenie jest przerywane - to połączenie jest przerywane i tyle.

De facto: Żaden gracz RtCW na protokole 60, na jakimkolwiek serwerze RtCW z wł. AntiLagiem nie ma z tego żadnej przewagi czy niekorzyści wynikających z niskich czy wysokich pingów.

Mam ogromną nadzieję, że wszystkie dyskusje i głupie odzywki (np. Ojejku, jejku! mój ping jest taki zły, nie mam żadnych szans!) ZAKOŃCZĄ SIĘ JAK I TEN ARTYKUŁ.

Oryginał niemiecki: www.compkal.net
autor: Newbroker

Tłumaczenie na angielski: www.compkal.net
autor: DanTheMan

Z angielskiego na polski: eth0




Temat Autor Data  
Bullshit
Swiety 03·11·2001-02:00  
Odp: nie do końca
eth0 03·11·2001-02:01  
Hmmm
Swiety 03·11·2001-02:01  
Antilag a timenudge
TheAbyss 03·11·2001-04:00  
Odp: Napisz coś więcej. Rzuć linkie...
eth0 03·11·2001-06:01  
Odp: Hmmmm...
TheAbyss 03·11·2001-07:00  
Odp: Hmmmm...
TheAbyss 03·11·2001-07:00  
Odp: przeczytaj jeszcze raz
eth0 03·11·2001-07:00  


 + DODAJ NOWY TEMAT 




--------------------------------------
Autor: [FPP]Vk
Aktualizacja: 03·11·2001 - 01:01



 : DRUKUJ 

     




   


f·p·p · p·r·o·d·u·c·t·i·o·n·s © 2000-2005 f·p·p productions. Skontaktuj się z nami w celu uzyskania dodatkowych informacji.
Przeczytaj reklama z nami, aby dowiedzieć się jak ukierunkować swoje produkty i usługi do graczy.


Dzisiaj jest Czwartek · 9 Maja · 2024
Strona wygenerowana w 0.102640 sek.