Банят за кривой лерп. Примерно тот ,который я нашёл :) (не буду писать какой )
Клиент-сервер - сетевой код игры, созданый на основе обмена пакетами между сервером и клиентом. В этих пакетах информация о текущем состоянии игрового мира (расположении объектов и т.д.).
cl_updaterate - число пакетов которые клиент получает от сервера каждую секунду.
Интерполяция - получение промежуточных значений какой-либо величины путём усреднения крайних. Интерполяция служит для сглаживания картинки, т.к. пакетов приходящих от сервера зачастую не хватает для того, чтобы картинка смотрелась плавно.
Настройки клиентской части по умолчанию: cl_updaterate 20; cl_interp_ratio 2; cl_interp 0.1.
Как это работает
cl_updaterate 20 означает, что клиент будет получать от сервера пакеты 20 раз в секунду, разница между пакетами - 50 мс. Чтобы предотвратить лагание от возможной потери пакета, интерполяция должна происходить в промежуток времени равный 2х50=100 мс. Чтобы обеспечить такую интерполяцию, необходимо задать параметр cl_interp 0.1. Множитель два означает, что мы хотим интерполировать две области между тремя пакетами пришедшими от сервера: "._._.". Если мы хотим интерполировать только одну область "._.", мы должны изменить соответствующий параметр. Этим параметром является переменная cl_interp_ratio. Она может принимать значения 2, 1, 0. Как не сложно догадаться, если эта переменная равна нулю, то интерполяция на клиенте будет отсутствовать. В общем случае формула для промежутка такова: lerp = cl_interp, но не может быть меньше cl_interp_ratio/cl_updaterate. Итак, тут мы приходим к самому определению:
lerp - промежуток времени, в котором пакеты, полученные клиентом, будут интерполироваться.
По сути, значение lerp определяет пропорцию между пакетами, пришедшими от сервера, и пакетами, сгенерированными на клиенте. Чем меньше значение lerp, тем меньше пакетов будет "придумано" на клиентской стороне, тем точнее то, что вы видите, будет соответствовать тому, что происходит на сервере. Чем больше значение lerp, тем большую долю в вашей картинке будет играть интерполяция.
После теории перейдем к практике. С самого начала кажется, что в идеале lerp должен быть равен 0, ведь при таком значении lerp нет интерполяции и клиент видит то же, что видит сервер. Вы НЕ можете себе позволить lerp = 0 по двум причинам.
1) Ваш интернет канал оставляет желать лучшего.
Предположим, что вы счастливый обладатель модема или в вашем городе широкополосный интернет пока по карману только избранным, или ваш сосед по общежитию по вечерам заливает на торрент пачку свежих немецких фильмов. Это значит, что вы можете себе позволить исключительно скромные сетевые настройки. Скорее всего те, что стоят по умолчанию, а быть может ваши дела ещё хуже. При cl_updaterate 20, даже если все пакеты благополучно приходят от сервера к клиенту, вы видите 20 кадров в секунду (не имеет значения, какой у вас компьютер). Человеческий глаз воспринимает эту картинку как дёрганную. Если же, не дай бог, потери (choke) есть, то играть вы просто не сможете, так как будете видеть слайдшоу.
2) Настройки серверов не позволяют клиентской части выставлять необходимые значения некоторых переменных.
Главная проблема тут безусловно cl_interp_ratio, на данный момент ни один европейский серверный конфиг не позволяет играть с этой переменной равной нулю. Сейчас добавление sv_client_min_interp_ratio 0 (эта команда отвечает за минимальное значение cl_inerp_ratio, которое может иметь клиент находясь на этом сервере) в евроконфиге скорее всего вопрос времени, и я пологаю, ждать осталось не долго. Но факт остается фактом: значение этой серверной переменной по умолчанию равно 1, а это значит, что клиент не может сделать lerp меньше, чем 10 мс.
Если вторая причина вопрос времени, то вот с первой причиной совладать способов не очень много.
Если у вас плохой коннект и постоянно теряются пакеты, то lerp=0 не для вас. Вам нужна интерполяция cl_interp_ratio 2.
Если же интернет не проблема, то тогда рецепт очень прост. Поднимайте рэйты: cl_cmdrate 66; cl_updaterate 66; rate 30000 - это ваш минимум. В идеале на 100 тиковом сервере у вас должно быть cl_cmdrate 100; cl_updaterate 100; rate 35000. Если сервер позволяет, ставьте cl_interp_ratio 0; cl_interp 0.
66, а тем более 100 кадров в секунду - вполне достаточно, чтобы комфортно воспринимать игру без интерполяции и лагов. Если же сервер не позволяет вам играть без интерполяции (пока что, это самый распространенный случай), рецепт очень прост:
1) Напишите в консоли cl_updaterate и запомните значение этой переменной
2) Напишите в консоли cl_interp_ratio 1
3) Разделите 1 на значение cl_updaterate
4) Напишите в консоли cl_interp и присвойте ему то что получили в пункте 3
Например:
Я играю с cl_updaterate 66, это значит что в 3 пункте я получу 0.0152, следовательно мне нужно написать cl_interp 0.0152. Это даст мне lerp = 15. Что уже довольно неплохо. Так как интерполяция таких временных промежутков не слишком сильно добавляет неточности вашим действиям.
Если вы пишите значение cl_interp меньшее, чем cl_interp_ratio/cl_updaterate, то на net_graph lerp будет отображаться оранжевым цветом. Если же lerp окрашен в желтый, то значит значение lerp больше промежутка времени между отсылаемыми пакетами на этом сервере. В обоих случаях lerp (а значит cl_interp) нужно увеличивать пока тот не станет белым. Если вы будете пытаться играть с НЕ БЕЛЫМ lerp, то вы обрекаете часть своих выстрелов застревать в промежутке клиент-сервер.
Вывод
Добивайтесь минимального значения lerp, оставляя его белым на каждом сервере, на котором играете. Это позволит вам снизить к минимуму все проблемы, связанные с вашим соединением с интернетом.
Напоследок замечу, что существует миф, будто бы lerp должен быть равен пингу. Пинг - время за которое пакет доходит от сервера к клиенту и он не имеет никакого отношения к интерполяции. Бесполезно пытаться найти связи в этих двух понятиях. При любом пинге сохраняйте lerp минимальным и белым.
Ещё совет
Чтобы не париться с математикой, можно забиндить клавиши так:
alias lerpa+ "incrementvar cl_interp 0.01 0.09 +0.0001"// cl_interp +0.0001
alias lerpa- "incrementvar cl_interp 0.01 0.09 -0.0001"// cl_interp -0.0001
alias lerpb+ "incrementvar cl_interp 0.01 0.09 +0.001" // cl_interp +0.001
alias lerpb- "incrementvar cl_interp 0.01 0.09 -0.001"// cl_interp -0.001
alias lerpc+ "incrementvar cl_interp 0.01 0.09 +0.01"// cl_interp +0.01
alias lerpc- "incrementvar cl_interp 0.01 0.09 -0.01"// cl_interp +0.01
bind "INS" "lerpa+"
bind "DEL" "lerpa-"
bind "HOME" "lerpb+"
bind "END" "lerpb-"
bind "PGUP" "lerpc+"
bind "PGDN" "lerpc-"
ЛЕРП
Основные net-настройки:
cl_updaterate - число запросов обновлений игрового мира с сервера в секунду.
cl_cmdrate - число обновлений информации о себе на сервере в секунду
rate - максимальное число отправляемых/принимаемых байт в секунду
cl_interp_ratio - число промежутков между интерполированием мира.
cl_interp - временной промежуток, через который происходит интерполяция.
1. Интерполяция - ШОЦЕТАКЕ?!
В идеальном сферическом мире в вакууме обновление информации о игровом мире с сервера идет бесконечно с задержкой в 1мс. В суровой реальности такого нет и число ваших запросов на обновление мира ограничено (66 максиум, выше - большая редкость и офф. не поддерживается). Между этими обновлениями мир стоит на месте. Чтобы этого не происходило - была придумана интерполяция. Она позволяет _предположить_ передвижение противника до того как мир обновится. Наша задача сводится к тому, чтобы интерполяция происходила одновреммено с обновлением мира - тогда информация о противнике будет самой точной.
2. Рейты - чо и как?
Число, которое стоит в параметрах цмд- и апдейтрейт указывает на число отправленных/принятых пакетов в секунду. Параметр rate позволяет ограничить общий объем передаваемой инфы в этих пакетах. Я видел много "рашн про" с rate 9999. Сжигать их на костре!
3. Как это относится друг к другу?
Мы имеем обновление мира 66 раз в секунду, исходя из того что cl_updaterate 66, нам нужно сделать так, чтобы интерполяция проходила в промежуток между пакетами. Далее мы решаем - через как часто будет происходить интерполяция - между одним или между двумя пакетами. Это задается при помощи cl_interp_ratio:
значение 1 - между двумя пакетами, один промежуток. |_|
значение 2 - между тремя, 2 промежутка. |_|_|
Теперь нам нужно узнать сколько мс длится промежуток. Для этого секунду делим на число обновлений: 1/66 = 0.0(15), округляем до 0.0152. Теперь если один промежуток (cl_interp_ratio 1), то ставим cl_interp 0.0152, если промежутков 2 (cl_interp_ratio 2)
, то ставим cl_interp 0.0152*2=0,0304
Выводим формулу:
1/cl_updaterate = cl_interp/cl_interp_ratio, отсюда получаем:
cl_interp = (1/cl_updaterate)*cl_interp_ratio
Получается, что интерполяция зависит от рейтов. Зная как высчитать интерполяцию составляем конфиг:
cl_updaterate 66;
cl_cmdrate 66; (цмд должен соответствовать апдрейту, для синхронности)
rate 40000; (можно 30000, меньше - хуже)
cl_interp_ratio 1 (лучше 1 промежуток - точнее инфа о противнике)
cl_interp 0.0152 (находим по формуле)
Это практически идеальный конфиг. +10 к пингу -100 к лагучести.
Можно делать вариации для слабого инета:
cl_updaterate 60;
cl_cmdrate 60;
rate 30000;
cl_interp_ratio 2
cl_interp 0.0333
Теперь немного о геях.
cl_updaterate 66
cl_interp 0.100
Самый распространенный "gay-pro" конфиг. Из 66 пакетов игнорируется 46. Противник уходит за стену - а вы его убиваете.
rate 9999 - а вот фиг вам я скажу как и где я двигаюсь! Сам не попаду и вам не дам!
cl_cmdrate 20 - А зачем противнику знать обо мне? (а на деле вы больше бегаете по прямой, стрейфы работают хуже)
Ну и вспомним эпик:
http://www.tf2world....9&postcount=200Эпичные рекомендации лучшего снайпера "Росии". Если вы поняли суть моего гайда, то вам будет смешно от его рекомендаций.
Принимаются рекомендации/недочеты и вообще. Надеюсь вам поможет.
UPD: Лоссы и чоки - ТЫ С КАКОВА СЕРВАКА ПРИШЕЛ, А?!
Лоссы и чоки - это потери пакетов при отправке их от вас на сервер.
Лосс: неконтролируемая потеря пакетов на пути к серверу. Случается из-за беспроводного соединения/плохого качества вашего соединения (в большинстве случаев). Также это бывает, если вы сидите за большим количеством проксей - чем больше сетей проходит пакет по пути от вас к серваку - тем больше вероятность лоссов. (путь пакета от вас к серверу можно посмотреть через пуск - выполнить - cmd - tracert "ip" без кавычек)
Чоки: бывают двух видов:
- первый тип зависит от вас - вы посылаете слишком много пакетов на сервер. Например у вас стоит апдейт рейт 100, а серверный тикрейт 66 (тикрейт сервера - максимальное число отдаваемых/принимаемых пакетов на одного юзера). Тогда чоки будут равны 34 и это значит, что 34% инфы о вас потеряно.
- второй тип чоков - зависит от сервера - сервер не справляется с потоком данных/лаг сети сервера/лаг CPU.
Избавиться от чоков можно по принципу:
net_graph 3 в консоли. Смотрим число чоков и вычитаем увиденное значение из cl_updaterate и cl_cmdrate.
Пример: choke 20 при cl_updaterate и cl_cmdrate 66. Вычитаем - пишем в консоли cl_cmdrate 46; cl_updaterate 46.
UPD:
Есть скрипт я пробовал он у меня работает!
вот он сам:
alias lerpa+ "incrementvar cl_interp 0.01 0.09 +0.0001"// cl_interp +0.0001
alias lerpa- "incrementvar cl_interp 0.01 0.09 -0.0001"// cl_interp -0.0001
alias lerpb+ "incrementvar cl_interp 0.01 0.09 +0.001" // cl_interp +0.001
alias lerpb- "incrementvar cl_interp 0.01 0.09 -0.001"// cl_interp -0.001
alias lerpc+ "incrementvar cl_interp 0.01 0.09 +0.01"// cl_interp +0.01
alias lerpc- "incrementvar cl_interp 0.01 0.09 -0.01"// cl_interp +0.01
bind "INS" "lerpa+"
bind "DEL" "lerpa-"
bind "HOME" "lerpb+"
bind "END" "lerpb-"
bind "PGUP" "lerpc+"
bind "PGDN" "lerpc-"
Как видете там есть бинды вот ими мы и пытаемся как-то накрутить свой лерп,но говорю еще раз у меня этот скрипт не пошёл!
Второй способ . По моему мнению это лучший способ хоть как то повлиять на значение лерпа!
Для этого мы будем пользоваться камандами:
cl_interp_ratio (Если не 0, то 2)
cl_interp (очень неплохо 0.003)
Оранжевый lerp - незначительное отклонение от идеального значения - ситуация когда получается значение лерпа в периоде/имеет слишком большое количество цифр и округленно.
Желтый lerp - сильное отклонение.
Красный lerp - тотальный ппц. Крайне редок.
Белый lerp - идеален. Но странно то, что лерп 0.1 засчитывается как идеальный тогда, когда он явно не подходит.
Ещё кое что, если lerp желтый - идут большие потери пакетов, а значит сервер- УГ.
Если lerp оранжевый, то потерь нет, но если будет лаг или лосс, то интерполировать будет нечего.
