Poradnik nie mój! Został napisany przez Czesia z blacklisted.pl i to Jemu należą się największe podziękowania!
1. Wstęp.
Parametr ex_interp przy ocenie demek ma bardzo duże znaczenie, z którego wiele osób nie zdaje sobie sprawy. Oglądając to samo demko z ustawionym interpem 0.01 możemy dojść do kompletnie innych wniosków niż gdy ustawimy 0.1.
2. Krótko o interpie.
Niby każdy wie co to jest, choć w praktyce bywa różnie. Na szczęście akurat oglądając demko da się łatwo sprawdzić jak to naprawdę działa. ex_interp to opóźnienie modeli w sekundach jakie gra wprowadza, aby poruszały się płynnie. W sekunach, czyli 0.05 = 5 setnych sekundy = 50 ms. Na wysokim poziomie śrubujemy to ustawienie do minimum, aby wszyscy gracze poruszali się w świecie jak najbardziej zbliżonym do tego, który jest na serwerze.
Wyższy ex_interp = płynniejsza gra, ale mniej precyzyjne pozycje modeli
Niższy ex_interp = ryzyko skakania modeli, ale bardziej precyzyjne pozycje
Nie wierzysz, że to opóźnienie? Odpal byle jakie demo, gdzie ktoś ma niesamowity refleks przy interpie 0.01 (może być jedno z poniższych). Przestaw teraz interp na 0.1 i obejrzyj jeszcze raz. Widzisz pre-fire? Jak to oglądasz z takim interpem model jest mocno opóźniony przez grę, aby było płynniej. Tak bardzo opóźniony, że oglądana osoba nie powinna go widzieć, gdy zaczyna strzelać! Dlatego ważne, żeby zdawać sobie sprawę z tego jaki mamy ustawiony ex_interp podczas oglądania dema. Szczególy niżej.
3. POV a HLTV.
W obu przypadkach to jaki interp ustawimy ma wpływ na pokazywaną grę. Zasadnicza różnica polega na tym, że w demku HLTV opóźnione są nie tylko modele innych graczy, ale również ten którego właśnie spectujemy. Szczególy samych pomyłek przy oglądaniu opisałem w punkcie Timingi.
Zwykle ustawiamy jak najniższy interp. Okazuje się, że demo skacze. Prawie zawsze tak się dzieje przy demku HLTV. Jest tak dlatego, że demo zawiera za mało informacji - było nagrywane ze zbyt małym cl_updaterate. Przy skaczącym demku również można dojść do bardzo złych wniosków - to opisałem w punkcie Rejestracja pocisków.
Jak wiadomo każdy gracz ma ustawiony indywidualny cl_updaterate, czyli parametr mówiący o tym ile razy informacje o grze docierają do niego w czasie sekundy. HLTV również, domyślnie 20, nie może przekroczyć 40. Niestety tylko 40. Demko HLTV zawsze będzie gorsze od POV-a i zawsze będzie skakać przy interpie 0.01.
4. Timingi.
Częstą wpadką cheaterów jest strzelanie, gdy jeszcze lub już nie widzi przeciwnika. Ten pierwszy przypadek znają wszyscy pod nazwą pre-fire. Ten drugi nazwałem post-fire, na przykładzie zrozumiecie o co mi chodzi.
4.1 Pre-fire typ 1.
Popularna sytuacja. Podejrzany wyczekuje ofiarę i strzela za szybko. Demko: prefire_typ1.dem (POV)
Obejrzyjmy je na interpie 0.1, bo tak wygodniej - nigdy nie ścina:
Ewidentny pre-fire. Do pieca. Dziękuję, dobranoc.
Ale! Wysoki ex_interp opóźnił model. To samo na interpie 0.01:
Clear?
4.2 Pre-fire typ 2.
Chyba jeszcze bardziej popularna sytuacja. Podejrzany wychyla się zza ściany zaczyna strzelać w ofiarę zanim ją zobaczy. Tutaj chodzi o opóźnienie modelu, który jest spectowany, więc w tym przypadku ex_interp ma wpływ tylko przy demkach HLTV. Demko: prefire_typ2.dem (HLTV)
Odpalamy na ex_interp 0.1:
(kolejne filmiki będą w formie linków ze względu na limit mediów w poście)
+b
A na ex_interp 0.01:
Info ładne, ale jak nie opóźnimy modelu interpem to pre-fire nie występuje!
4.3 Post-fire.
Tę wpadkę haxów nazwałem w ten sposób, bo jest to w pewnym sensie przeciwieństwo poprzednich. Podejrzany wychyla się, gdy przeciwnik akurat się chowa. Podejrzanemu wydaje się, że widział ofiarę, więc skanuje. Demko: postfire.dem (POV). Najpierw zobaczmy sytuację z WH na ex_interp 0.01:
Wyłączamy WH, żeby się upewnić, że nie miał prawa widzieć ani piksela.
+b
To samo z interpem 0.1:
i okazuje się, że podejrzany widział jak typ się chowa. Wystarczyło, że miał opóźnione modele.
Jak widzicie nie ma jednej recepty jakiego interpa używać do demek. Więcej w punkcie 6.
Przy demku HLTV i poruszaniu się obu modeli rozbierzności między skrajnymi interpami mogą być dwukrotnie większe niż przedstawione powyżej.
5. Rejestracja pocisków.
Często zdarza się posądzanie gracza o aimbota lub no-recoil. Nie można tego robić, gdy nasze demo skacze! Na takim demku w ogóle nie widać ruchów celownika, które są zasadnicze przy tego typu cheatach. Gdy obejrzymy to samo demo z wyższym interpem, np. 0.05, okazuje się, że akcje w ogóle nie są podejrzane. Bardzo duże znaczenie ma tutaj również updaterate. Zauważcie, że standardowe demko HLTV ma zaledwie 20 informacji na sekundę. To aż 4 razy mniej niż wymagane w większości lig. Gubimy w tym momencie informacje takie jak gwałtowne ruchy celownikiem i precyzyjne informacje gdzie lecą kolejne pociski. Trzeba mieć to na uwadze posądzając o haxy. Jestem przeciwnikiem oskarżania o aimbota na podstawie demka HLTV (nie licząc oczywistych przypadków). Tutaj doskonały przykład różnicy między HLTV a POV (dzięki za linki, QbC):
HLTV:
POV:
6. Wnioski: jak oglądać?
6.1 Gdy podejrzewamy WH/ESP.
Ustawiamy ex_interp 0.01. Trudno, że ścina! Przynamniej nie będziemy niesłusznie posądzać gracza o za dobry refleks. W przypadku akcji typu post-fire ustawmy na chwilę interp 0.1 i upewnijmy się czy teraz akcja ma taki sam przebieg. W dziwnych sytuacjach typu widział/nie widział dobrze jest je sprawdzić na różnych interpach.
6.2 Gdy podejrzewamy AB.
Tutaj ustawiamy minimalny interp, ale taki, żeby demko nie skakało. Dzięki compLexity Demo Player możemy sprawdzić jakie podejrzany gracz (w przypadku POV-a) lub HLTV (w przypadku dema HLTV) miał cl_updaterate. Znając tę wartość ustawiamy odpowiadający interp (tabelka niżej), ew. dodając 0.01 jeśli wciąż widzimy skoki. Pamiętajmy, że gracz może zmienić cl_updaterate w czasie gry, jednak wszystkie te informacje są widoczne w analizie dema.
7. Tabelka ex_interp - cl_updaterate.
ex_interp nie może być niższe niż wartość "1 / cl_updaterate". Sama gra na to nie pozwala i zwiększa interp (komunikat "ex_interp forced up to 20 msec"). W związku z tym, że zwykle zależy nam na jak najmniejszym interpie korzystamy ze wzoru:
ex_interp = 1 / cl_updaterate
Przeliczone wartości:
cl_updaterate 10 -> ex_interp 0.1
cl_updaterate 20 -> ex_interp 0.05
cl_updaterate 30 -> ex_interp 0.034
cl_updaterate 40 -> ex_interp 0.025
cl_updaterate 50 -> ex_interp 0.02
cl_updaterate 80 -> ex_interp 0.013
cl_updaterate 100 -> ex_interp 0.01
8. Widoczny a prawdziwy cl_updaterate
Informacja głównie dla osób konfigurujących serwery. Mimo że gra pozwala ustawić dowolny cl_updaterate (od 10 do 102) to faktyczna wartość tego ustawienia jest limitowana przez serwer. Za dolny limit odpowiada komenda sv_minupdaterate, za górny - sv_maxupdaterate. HLTV jest tutaj traktowane jak zwykły gracz. Może nas to wprowadzić w błąd, bo analiza dema za pomocą CDP nie pokazuje prawdziwego updaterate'a.









