у всех после обновления в нижнем правом углу появилась переменная lerp=xxx.
вопростов много по этому поводу, поэтому полазил по инету, нашел инфу которая мне многое прояснила,
и внаглую скопипастил сюда.
Небольшой ликбез
Клиент-сервер - сетевой код игры созданый на основе обмена пакетами между сервером и клиентом. В этих пакетах информация о текущем состоянии игрового мира (расположении объектов и т.д.)
cl_updaterate - число пакетов которые клиент получает от сервера каждую секунду.
Интерполяция - получение промежуточных значений какой-либо величины, путем усреднения крайних. Интерполяция служит для сглаживания картинки, т.к. пакетов приходящих от сервера зачастую не хватает для того чтобы картинка смотрелась плавно.
Как это работает
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_rat io 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_graph lerp будет отображаться оранжевым цветом. Если же lerp окрашен в желтый, то значит значение lerp больше промежутка времени между отсылаемыми пакетами на этом сервере. В обоих случаях lerp (а значит cl_interp) нужно увеличивать пока тот не станет белым. Если вы будете пытаться играть с НЕ БЕЛЫМ lerp, то вы обрекаете часть своих выстрелов застревать в промежутке клиент-сервер.
Вывод
Добивайтесь минимального значения lerp, оставляя его белым на каждом сервере, на котором играете. Это позволит вам снизить к минимуму все проблемы, связанные с вашим соединением с интернетом.
На последок замечу, что существует миф, будто бы lerp должен быть равен пингу. Пинг - время за которое пакет доходит от сервера к клиенту и он не имеет никакого отношения к интерполяции. Бесполезно пытаться найти связи в этих двух понятиях. При любом пинге сохраняйте lerp минимальным и белым.
Тема: How-to. lerp в css (Прочитано 16713 раз)