ORG

W tej chwili mam w QL confa z Q3 czy ktoś może próbował jakoś tuningować parametry sieciowe QL ? jak najlepiej ustawić te max pakiety i czy są jakieś inne dodatkowe komendy które pomogą choć trochę ustabilizować ping ?

Najlepiej to się tym nie bawić. Ewentualnie cl_timenudge daj na -10 jak nie grasz po lanie tylko wifi ale to tez zalezy jak komu pasi :). Mozesz tez probowac net_restart jak masz problemy.

ok thx

// NET
Na wstępie chciałbym tutaj zaznaczyć, że funkcjonowanie niektórych z poniższych komend nie zostało jasno sprecyzowane i wyjaśnione przez developerów Quake Live dlatego trudno jednoznacznie opisać ich działanie a tym bardziej wskazać prawidłową konfigurację wszystkich razem a także podać zalecane wartości dla każdej z nich z osobna. Niestety poniższe polecenia każdy z nas musi dostosować indywidualnie bo są zależne od parametrów naszego połączenia. Jak to zrobić? Zastosować metodę prób i błędów : )

cl_maxpackets [30 – 125] - kontroluje ilość pakietów (klatek) wysyłanych przez nas do serwera (domyślnie 63), przykładowo jeśli mamy com_maxfps = 125 oraz cl_Maxpackets = 125 będziemy wysyłać do serwera pakiet z każdą klatką czyli 125 pakietów na sekundę, w przypadku ustawienia cl_maxpackets na 63 wyślemy pakiet z co drugą klatką. W przypadku naprawdę dobrego łącza i bardzo niskiego pingu ustawić 125 pakietów na sekundę (domyślnie 63).

rate [8000-25000] - kontroluje prędkość przepływu pakietów z serwera do klienta (w bajtach na sekundę) (domyślnie 16000), zalecane 25000

cl_packetdup [0 – 5] - określa ile razy ma zostać powtórzone wysyłanie tego samego pakietu do serwera w celu uniknięcia straty pakietów (domyślnie 1), wartość 1 oznacza wysłanie tego samego pakietu dwa razy do serwera

cl_timeNudge [-20 - 20] - wartości ujemne uruchamiają aparat odpowiadający za predykcje ruchów przeciwnika. Mechanizm ten na podstawie otrzymanych informacji próbuje oszacować i przewidzieć następne położenie przeciwnika i pokazuje je z określonym przez nas w ms wyprzedzeniem, np. cl_timeNudge = -5 oszacuje położenie przeciwnika i pokaże je z 5ms wyprzedzeniem na naszym ekranie. Jeśli gra otrzyma pakiet informujący, ze nie stało się jednak to, co mechanizm przewidział, to cofa nas, tak się może zdarzać jeśli ruchy przeciwnika są bardzo szybkie i gwałtowne, możemy doświadczyć z tego powodu efektu warpa.

Wartości dodatnie spowodują, że mechanizm narysuje ruchy przeciwnika z minimalnym opóźnieniem, dzięki czemu jego ruchy będą bardziej płynne. Przydatne do oglądania graczy ze spect czyli również dla osób, które strimują.

cg_predictLocalRailShots [0/1] - ponieważ grając na wysokim pingu >80 mija sporo czasu między kliknięciem przez nas strzału a zarejestrowaniem tej akcji (ruchu) przez serwer dlatego często w takich sytuacjach odnosimy fałszywe wrażenie, że nasz rail przeszedł przez przeciwnika mimo iż tak na prawdę go nie trafił (zanim serwer zarejestrował nasz strzał, przeciwnik już zdążył zmienić swoją pozycję). Tak się dzieje w przypadku wysokiego pingu i komendy ustawionej na 1. Ustawiając wartość 0 dostaniemy prawdziwy obraz opóźnienia między strzałem a reakcją serwera ponieważ nasz klient gry zanim wystrzeli "zaczeka" na odpowiedź serwerach (czas ten określa aktualny ping) żeby się z nim zsynchronizować i dopiero wtedy wykona akcję w efekcie czego zobaczymy na ekranie, że przeciwnik zdążył się już przesunąć zanim my tak na prawdę wystrzeliliśmy. Mimo wszystko w przypadku niskiego pingu (poniżej 80) zalecane jest używanie wartości 1. I żeby była jasność, komenda nie ma wpływu na to gdzie nasz rail trafi tylko jak my to zobaczymy i usłyszmy.

cg_predictItems [0/1] - działa analogicznie jak komenda cg_predictLocalRailShots tylko dotyczy podnoszenia itemów. Wartość 1 wywoła dźwięk w momencie kiedy widzimy na ekranie swojego monitora podniesienie itemu, "0" natomiast da komunikat tylko wtedy kiedy podniesienie itemu zarejestruje serwer, czyli będzie miało realny skutek. Jednak po ustawieniu na 0 sygnał będzie wysyłany z pewnym opóźnieniem, które jest adekwatne do naszego pingu. W przypadku niskiego pingu i brak straty pakietów nie ma sensu ustawianie wartości 0. (domyślnie 1)

cg_nopredict [0/1] - analogicznie j.w., wartość 1 zapewni bezbłędny komunikat o podniesieniu itemu jednak z możliwym, niewielkim opóźnieniem. Trudno powiedzieć czy i która z powyższych dwóch komend jest nadrzędna i czy się wykluczają. (domyślnie 0)

cg_smoothClients [0/1] - ustawione na 1 "wygładza" ruchy przeciwnika (nadaje płynności jego ruchom) jeśli ten traci sporo pakietów i przez to "warpi" (domyślnie 0), cg_smoothClients = 1 jest niekompatybilne z ujemnymi wartościami cl_timeNudge

cg_projectileNudge [0-80] - komenda ma za zadanie kompensować opóźnienie z jakim widzimy lecące w naszym kierunku pociski, rysując je z odpowiednią predykcją, opóźnienie to jest spowodowane oczywiście naszym pingiem. Działa podobnie do cl_timeNudge ale dotyczy tylko pocisków, nie prognozuje zachowania modelu przeciwnika (domyślnie 0). Nie ma wzoru jak odpowiednio sparować tą komendę z cl_timeNudge.

Pisałem to dosyć dawno więc nie wie czy te komendy dalej aktualne.