| ALEX[26] | Дата: Среда, 15.02.2012, 12:36 | Сообщение # 1 |
 Генералиссимус
Группа: Администраторы
Сообщений: 22
Статус: Offline
| Небольшой ликбез
Клиент-сервер - сетевой код игры, созданый на основе обмена пакетами между сервером и клиентом. В этих пакетах информация о текущем состоянии игрового мира (расположении объектов и т.д.).
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 20000 - это ваш минимум. В идеале на 100 тиковом сервере у вас должно быть cl_cmdrate 100; cl_updaterate 100; rate 25000. Если сервер позволяет, ставьте 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_graphlerpбудет отображаться оранжевым цветом. Если же lerp окрашен в желтый, то значит значение lerpбольше промежутка времени между отсылаемыми пакетами на этом сервере. В обоих случаях lerp (а значит cl_interp) нужно увеличивать пока тот не станет белым. Если вы будете пытаться играть с НЕ БЕЛЫМ lerp, то вы обрекаете часть своих выстрелов застревать в промежутке клиент-сервер.
Вывод
Добивайтесь минимального значения lerp, оставляя его белым на каждом сервере, на котором играете. Это позволит вам снизить к минимуму все проблемы, связанные с вашим соединением с интернетом.
Напоследок замечу, что существует миф, будто быlerp должен быть равен пингу. Пинг - время за которое пакет доходит от сервера к клиенту и он не имеет никакого отношения к интерполяции. Бесполезно пытаться найти связи в этих двух понятиях. При любом пинге сохраняйте lerp минимальным и белым.
Ещё совет
Чтобы не париться с математикой, можно забиндить клавиши так:
Code
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-"
Серверная часть
1. К серверу lerp не имеет непосредственного отношения. Интерполяцию сделана для гладкости картинки, но её значение по умолчанию 0,1 на мой взгляд велико т.к. было расчитано видимо на более слабую технику и интренет соединение (cl_updaterate 20) поэтому с увеличением тиков логично понизить интерполяцию
по формуле:
Code interpolation period = max( cl_interp, cl_interp_ratio / cl_updaterate )
2. На сервере своя система - лагокомпенсация пакетов независимая от клиента (это не интерполяция аналогичная клиенту)
Работает эта система по следующему принципу:
Если ты стреляешь например в 21:05:02 , но по факту сервер из-за задержек узнает это в 21:05:03 , и он учитывает эту задержку по системе:
(Command Execution Time = Current Server Time - Packet Latency - Client View Interpolation)
и игрок попадает, хотя в это время хитбоксы цели уже в другом месте.
Предвидя, что станут тыкать в Client View Interpolation поясню, что это значение, а не сервер производит интерполяцию.
Это значение учитывается для каждого игрока и если даже интреполяция 0, то не забывайте, что 0 это тоже значение.
Вот как раз из=за даже мелких неточностей сбивок в этой формуле бывают казусы когда клиент видит попадание
(кровь - кстати тоже на стороне клиента) а по факту его нет, чтобы компенсировать это надо увеличть количество тиков.
Сейчас грубо говоря сервер держит в памяти(симулирует) события за 1 секунду в виде 66 снимков (тиков - tick).
Для игры в реальном времени (без всяких компенсаций) на сервере надо увеличить тики, а игроку убрать интерполяцию,
но к сожалению остается Packet Latency и тут уж все зависит от развития технологий, а пока их нет приходится терпеть такую систему.
Альтернатива этой системе на данный момент только одна - учет попаданий на стороне клиентов и передача уже на сервер факта попадания, но
это будет самое большое раздолье для читеров.
Более подробное про lerp и не только: Сетевая архитектура движка Source
|
| |
| |
