Настройка основных консольных команд для комфортной игры через Интернет

Ещё раз всем привет. Сегодня я выкладываю последние две части статьи "Настройка основных консольных команд для комфортной игры через Интернет". Если у вас появились какие-либо вопросы, оставляйте их в комментариях, буду рад осветить их в своём руководстве ;).

Часть четвёртая. Рекомендуемые значения переменных
fps_max. Многие игроки ставят значение данной переменной, равное 101. Это позволяет добиться частоты обновления экрана приблизительно 100 раз в секунду. Не рекомендуется ставить более высокое значение, потому что:
1) для глаза не будет ощутимой разницы, зато чрезмерное повышение FPS здорово скажется на производительности;
2) слишком высокое значение будет замедлять все ваши движения.

Рекомендуемое значение для fps_max – 101.

fps_modem. Сомневаюсь, что кто-то ещё играет на dial-up соединениях. Так что этот параметр можно и вовсе не трогать.

Рекомендуемое значение для fps_modem – 0.

rate. В основном серверы оптимизированы под значение 20000 (sv_maxrate 20000). Ставить значение выше 20000 нет смысла, потому что это отразится на качестве вашего соединения в виде «засоренности» канала и последующей ошибки CL_FlushEntityPacket. В то же время, вы должны учитывать ширину своего исходящего канала и не отводить его полностью под Counter-Strike. Например, мой входящий канал имеет пропускную способность до 2 мегабит в секунду. Путём нехитрых математических вычислений можно посчитать, что мой канал может получать до 262144 байт в секунду. Таким образом, я спокойно могу поставить себе значение 20000 и не заботиться об остатке, потому что это всего 8% от всей пропускной способности канала. А вот пользователю с пропускной способностью порта в 256 килобит в секунду, значение rate 20000 не подойдёт, потому что это 61% всей пропускной способности. Следует также учитывать, что вы не получаете всю скорость, заявленную вашим провайдером. До 10-15% трафика является служебным, т.е. он не находится в вашем распоряжении и вы не в силах его контролировать. Поэтому я бы советовал несколько уменьшить значение rate. Грубо говоря, значение в 20000 подойдёт всем, у кого пропускная способность входящего канала не ниже 1 мегабита в секунду.

Рекомендуемое значение для rate – 20000 (25000+ для LAN).

cl_rate. Здесь всё точно так же, как и в случае с rate, только обмен данными происходит в обратном направлении (клиент-сервер). Максимальное значение для cl_rate является «20000». По умолчанию стоит «9999».

Рекомендуемое значение для cl_rate – 9999 (оставить по умолчанию). Либо, если позволяет ширина исходящего канала – 20000.

ex_interp. Сразу же ставим на «0» и больше ничего не трогаем. Движок игры автоматически посчитает нам значение данной величины по формуле 1/cl_updaterate. О том, что движок сам посчитал значение, переменной мы узнаем по сообщению в консоли: “ex_interp forced up to xx msec”.

Рекомендуемое значение для ex_interp – 0.

cl_cmdrate. Помимо того, что данная величина должна перекликаться с вашим FPS, она ни в коем случае не должна быть выше серверного FPS (значение серверного FPS задаётся командой sys_ticrate). Если вы посылаете пакетов больше, чем сервер может обработать, то лишние пакеты будут отклонены сервером. Представим себе ситуацию, когда сервер работает на 64 FPS (стандартный сервер под управлением ОС Windows), а вы ему отсылаете 100 пакетов. Таким образом, 36 пакетов будут отклонены сервером. Эти 36 отклонённых пакетов просуществуют на канале, пока не исчезнут. Об этом мы уже говорили в первой части статьи, когда речь зашла о TTL. Простая арифметика: 36 отклонённых пакетов в секунду, TTL каждого из которых равен 46 секундам. За две секунды мы получим 72 отклонённых пакета, в то время как за 46 – уже 1656 пакетов. Прикинем, что величина каждого отправленного пакета равна 20 килобайтам – это минус 33120 байт от пропускной способности вашего исходящего канала. Но не всё так страшно, как кажется на самом деле. Современные игровые серверы способны просчитывать до 1000 FPS. То есть можно не опасаясь выставить максимальное значение cl_cmdrate — 101. Тем не менее, пока вы не знаете rcon-пароль от сервера, серверный FPS вы никогда не узнаете. Так что в некоторых случаях значение придётся подбирать вручную.

Рекомендуемое значение для cl_cmdrate – 101, либо ниже, в зависимости от серверного FPS.

cl_updaterate. Значение данной переменной также должно перекликаться с серверным FPS, но не должно быть выше значения переменной sv_maxupdaterate. Многие игроки считают, что нужно ставить значение, равное 101 — ни больше, ни меньше. Но не всё так просто. Во-первых, картинку без лагов при таком значении способны обеспечить лишь очень мощная и правильно настроенная серверная машина и LAN-подключение. Тут опять же возникает мнение, что если машина не в силах передать необходимое количество данных, то пусть передаёт максимально возможное на данный момент. Всё бы ничего, если бы не зависимая от cl_updaterate переменная ex_interp. Допустим, вы также запрашиваете от сервера 101 пакет в секунду. При этом значение переменной ex_interp будет равно 0.009. Но если вы не будете получать все запрашиваемые пакеты, то движения игроков на вашем экране будут отображаться рывками, потому что баланс между значениями переменных будет нарушен. Поэтому, на мой взгляд, наилучшее решение – это установить значение «101» для cl_updaterate, «0» для ex_interp, и потом уже понижать значение cl_updaterate до значения, при котором вам будет удобно играть. При этом не забываем поглядывать на показания choke. Не бойтесь понижать значение cl_updaterate ниже 50. Если вы будете уменьшать значение cl_updaterate, то значение ex_interp будет рассчитываться движком автоматически. Но как только вы решите увеличить значение cl_updaterate, вам придётся заново присваивать команде ex_interp значение «0», чтобы движок автоматически рассчитал нужное значение.

Рекомендуемое значение для cl_updaterate – не выше значения sv_maxupdaterate и не выше серверного FPS; подбирается путём уменьшения значения – от 101 и по убывающей.

cl_cmdbackup. Значением по умолчанию является «2». При слишком больших потерях пакетов при передаче значение данного параметра можно увеличить до «8». Даже в случае хорошей связи с сервером не рекомендуется ставить значение «0». Элементарно для перестраховки лучше оставить стандартное значение.

Рекомендуемое значение для cl_cmdbackup – от 2 до 4, максимально – 8, в зависимости от ситуации.

cl_resend. Значением по умолчанию является «6», т.е. пакет будет заново послан через 6 секунд. Не рекомендуется ставить значение «1», потому что велик риск «вылететь» с ошибкой “WARNING: Connection Problem” (в случае, если канал сильно загружен, и резервный пакет также не дойдёт).

Рекомендуемое значение – от 3 до 6.

Все эти команды должны использоваться в комплексе. Изменение какой-либо одной команды положительного эффекта не даст, а зачастую даже может привести к ухудшению ситуации.

Часть пятая. Распространённая ошибка Cl_FlushEntityPacket
Данная ошибка говорит о том, что обмен данными между клиентом и сервером не происходит в полном объёме, либо вовсе прекратился. Возможные причины:
1) проблемы с подключением к Интернету со стороны сервера, либо с вашей стороны;
2) активно работающая программа типа P2P;
3) другие компьютеры в локальной сети используют данное соединение
4) перегрузка канала на стороне сервера;
5) вы используете беспроводное подключение;
6) ваш компьютер заражён вирусами, которые генерируют трафик;
7) вы используете dial-up подключение;
8) слишком высокие значения cl_cmdrate и cl_updaterate для вашего соединения.

Способы решения проблем:
1) проверить доступность подключения к Интернету со своей стороны;
2) отключить все P2P-клиенты, а также браузеры, мессенджеры и т.д.;
3) если вы работаете через локальную сеть, проверьте, насколько активно её используют другие компьютеры;
4) просто подождать, пока сервер не разгрузит свой канал;
5) использовать кабельное подключение (LAN или xDSL);
6) проверить свой компьютер на наличие вирусов;
7) использовать кабельное подключение (LAN или xDSL);
8) понизить значения cl_cmdrate и cl_updaterate, либо увеличить значение rate (если позволяет пропускная способность входящего канала).

Статью подготовил Lincoln “Maverick” Burrose