Вот под таким незамысловатым названием выйдет, наверное, последняя статья по сетевому коду CS 1.6. Этому вопросу я посвятил целых пять топиков, однако та информация является уже относительно устаревшей (хотя прошло всего лишь чуть более двух лет) и местами неверной. Причиной тому послужило весеннее мажорное обновление, которое всколыхнуло тогда все комьюнити.

На самом деле, вся шумиха поднялась после того, как сервис цифровой дистрибуции Steam, принадлежащий Valve, стал-таки доступен под Linux. Однако толку от доступности сервиса на другой ОС нет, если игры системой не поддерживаются. В связи с этим Valve портировала некоторые свои игры под Linux, в числе которых такие признанные хиты, как Left4Dead 2, Team Fortress Classic и Team Fortress 2, все части Half-Life, Counter-Strike:Source и, конечно же, оригинальный Counter-Strike.

Linux-версия Counter-Strike получила некоторые важные изменения, поэтому для устранения различий Windows-версия также подверглась модернизации. Процесс портирования никогда не проходит безошибочно, в связи с чем был создан баг-трекер на GitHub. Помимо ошибок портирования программисты Valve попутно исправляют мелкие баги оригинальной игры.

Также с введением новой системы доставки контента под названием SteamPipe слегка поменялось расположение игровых каталогов. Теперь файлы Counter-Strike располагаются в директории Steam\SteamApps\common\Half-Life.

Теперь вернёмся к нашему вопросу. В интернете много информации по этой теме; местами встречаются даже статьи, написанные ещё в начале нулевых и адаптированные под dial-up соединение. И некоторые не особо искушенные в консольных вопросах люди следуют тем советам! Чтобы не случалось подобных казусов, я стараюсь поддерживать информацию в актуальном состоянии. Изменения, внесенные обновлениями, коснулись консольных переменных (CVars) — именно о них я сегодня расскажу. В плане теории особых изменений нет, за исключением некоторых моментов, которые почему-то ускользнули от моего внимания в прошлый раз. Тем не менее, если вы еще не знакомы с моими топиками, то советую начать именно с них, потому что в этот раз описание будет очень сжатым. Ссылки будут даны в конце этой статьи. Ну, поехали!

fps_max

Кадровая частота или количество кадров, которое будет отображаться на экране в секунду. После обновлений изменение значения этой переменной заблокировано.

Значение по умолчанию — 100
Рекомендуемое значение — 100
Связанные переменные — fps_override, fps_modem, gl_vsync

fps_override

При значении «1» позволяет выставить значение для fps_max более 100.

Значение по умолчанию — 0

fps_modem

Устарела и удалена из игры.

gl_vsync

Отвечает за вертикальную синхронизацию.

Значение по умолчанию — 1
Рекомендуемое значение — 0

ex_interp

Промежуток времени (в секундах), во время которого происходит интерполяция (читать подробнее) между каждым обновлением, получаемым от сервера. ex_interp — зависимая переменная и рассчитывается по формуле 1/cl_updaterate — время между приходом каждого из пакетов обновления. Именно это количество времени клиент должен интерполировать. Существуют два «идеализированных» значения — 0.1 и 0.01.

• 0.1 — интерполяция происходит каждые 100 мс (реже); плавное передвижение моделей игроков; расположение модельки не соответствует реальному расположению хитбоксов (отстает).
• 0.01 — интерполяция происходит каждые 10 мс (чаще); в некоторых случаях возможны подергивания в передвижении моделей игроков; расположение модельки соответствует реальному расположению хитбоксов.

Откуда берутся подергивания моделей в одном случае и разность в расположении модели и хитбокосов в другом? Существует мнение (небезосновательное), что расположение моделек при игре по интернету отстает от реального расположения хитбоксов. Скорее всего это связано с тем, что игроки неодинаково синхронизированы с сервером вследствие разности пингов (т.е. у игроков разное время задержки при обмене данными с сервером). Помимо этого, игроки сами не всегда в полном объеме отправляют нужные серверу данные, и тогда уже самому серверу приходится выполнять интерполяцию.

За пример возьмем ситуацию, когда вы получаете от сервера 100 обновлений в секунду (cl_updaterate = 100 пакетов, п.; время = 1 с = 1000 мс).

ex_interp 0.1: 1/10 c = 100 мс (интерполяция происходит каждые 100 мс); 100 п/1000 мс = 0.1 п/мс = 1 пакет в 10 мс (один пакет обновления приходит каждые 10 мс); 0.1 п/мс*100 мс = 10 пакетов. Следовательно, интерполяция будет выполняться только на основании данных каждых десяти пакетов. Это означает, что ваш компьютер сумеет отрисовать более плавную картинку за счет большего количество данных, которые, к сожалению, успеют устареть (в данном случае на 100 мс). Этим объясняется отставание модельки от хитбоксов.


ex_interp 0.1. Закрашенный силуэт — настоящее расположение игрока, пунктирный силуэт — результат интерполяции.

ex_interp 0.01: 1/100 c = 10 мс (интерполяция происходит каждые 10 мс); 100 п/1000 мс = 0.1 п/мс = 1 пакет в 10 мс (один пакет обновления приходит каждые 10 мс); 0.1 п/мс*10 мс = 1 пакет. Следовательно, интерполяция будет выполняться после каждого пакета обновления, к чему и следует стремиться. В таком случае расположение модели на экране игрока и хитбоксов на сервере примерно одинаковое. Подергивания объясняются рассинхронизацией между сервером и каждым игроком.


ex_interp 0.01. Частые обновления позволяют всегда точно восстанавливать местоположение игрока; время между приходом обновлений оставляет белые области, подвергающиеся интерполяции.

Значение 0.01 принято использовать при игре в локальной сети и, соответственно, на LAN-турнирах, где игрокам обеспечиваются равные условия как в плане оборудования, так и в плане сетевых задержек (т.е. все игроки синхронизированы с сервером практически одинаково).

Значение ex_interp рассчитывается автоматически по формуле 1/cl_updaterate, поэтому я предлагаю использовать значение «0», чтобы дать компьютеру выставить правильное значение самому (об этом будет свидетельствовать следующее сообщение в консоли: “ex_interp forced up to xx msec”).

Значение по умолчанию — 0.1
Рекомендуемое значение — 0
Связанные переменные — cl_updaterate, cl_cmdrate

rate

Отвечает за пропускную способность канала обмена данными между клиентом и сервером (в обе стороны). Измеряется в байтах в секунду. После обновлений выполняет функции переменной cl_rate.

Значение по умолчанию — 50000
Максимальное значение — 100000
Рекомендуемое значение — от 20000 в зависимости от пропускной способности вашего интернет-канала (читать подробнее)

cl_rate

Устарела и удалена из игры.

cl_cmdrate

Количество пакетов обновлений, которые вы будете отправлять на сервер в секунду.

Напрямую зависит от кадровой частоты, на которой работает ваш клиент. При 100 fps для полной синхронизации с сервером значение «100»/«101» является недостаточным. Это легко проверяется следующим образом: net_graph 1; cl_cmdrate fps_max/2 (cl_cmdrate 50, например). Внизу графика появляется множество красных точек.

Таким образом, значение cl_cmdrate следует подбирать на несколько пунктов выше (~5), чем средний fps. Однако слишком высокое или слишком низкое значение может привести к choke.

Значение по умолчанию — 60
Рекомендуемое значение — fps_max +5 (fps_max 100 => cl_cmdrate 105)
Связанные переменные — cl_cmdbackup

cl_updaterate

Количество пакетов обновлений, которые вы будете запрашивать с сервера в секунду.

Значение cl_updaterate не должно превышать значение sv_maxupdaterate. Слишком высокое значение приведет к choke, т.е. вы запрашиваете большее количество обновлений, чем сервер готов вам передать. В таком случае необходимо понижать значение до тех пор, пока значение choke не будет в пределах 0-10.

Значение по умолчанию — 60
Рекомендуемое значение — 100

cl_cmdbackup

Количество дублируемых команд (выполненных и отосланных на сервер в предыдущем пакете обновления), добавляемых в каждый последующий пакет обновления. Под командой подразумевается любое действие, которое выполняется на стороне клиента (шаг, выстрел, смена оружия и т.д.).

Принцип работы. cl_cmdbackup 2; содержимое одного из пакетов обновления: 12345. Содержимое следующего: 45678. Затем: 78901 и т.д.

В зависимости от ситуации значение можно менять, однако не рекомендуется ставить значение «0». Следует учитывать, что повышение значения повысит использование пропускной способности.

Значение по умолчанию — 2
Рекомендуемое значение — 2-4

cl_resend

Ошибочно была отнесена мною к неткоду. На самом деле отвечает за количество времени (в секундах), через которое клиент заново отошлет на сервер команду connect.

Теперь предлагаю создать конфигурационный файл, он же конфиг. У меня он называется rates.cfg. Впрочем, создавать отдельный конфиг необязательно. Однако он может пригодиться вам, когда нужно оперативно восстановить какую-либо отдельную группу настроек (например, настройки соединения), не затрагивая при этом другие настройки.

Содержимое моего rates.cfg:

ex_interp "0"
rate "25000"
cl_cmdrate "105"
cl_updaterate "100"
cl_cmdbackup "4"
echo Rates.cfg has been succesfully loaded.