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

На самом же деле пинг - время между отправкой пакета и приемом ответного (если такой есть:) И даже козе понятно: чем ниже - тем лучше! Но на деле не все так просто. Пинг по своей природе делится на нормальный и анормальный. Рассмотрим каждый из них подробно.

НОРМАЛЬНЫЙ ПИНГ

Нормальный пинг - по-простому, это задержка сигнала на всех участках линии, при его "путешествии" от пользователя до сервера плюс то же самое, но назад. Что может быть проще? Но, есть одно "но" - это при отправке одного пакета. А когда их посылается несколько и подряд (т.е. ответ на первый ещё не пришел, а второй уже послан и так со следующим и т.д.), то пинг увеличивается на 40-60% (а иногда и на 100%) от начального. В итоге: минимальный пинг 150 мс, максимальный 250 мс. Вот, именно, максимальный и будет в игре (или даже больше). Конечно, тут большую роль играет качество телефонной линии.

АНОРМАЛЬНЫЙ ПИНГ

Этот пинг - результат несоответствия физических возможностей линии и сетевых настроек игры. Рассмотрим ситуацию: коннект 28.8 кбод, игрок выбегает на толпу противников, его "мясят" и в итоге - фраг с пингом 4096 висит в воздухе или танцует брейк-данс. Тут имеет место всеми любимого FlushEntityPacket - (переполнение) пакеты не могут дойти до пользователя в указанный срок и в нужном порядке. Надо либо увеличить пропускную способность линии, либо уменьшить число пакетов (согласований). Тут гадать нечего: будем уменьшать количество пакетов (т.к. иногда больше 33,6 из модема выжать просто невозможно).

КОМАНДЫ И РЕЗУЛЬТАТ

Собственно, для оптимизации процесса согласования под конкретную машину и конкретное модемное соединение, нужно знать основные команды для оптимизации сетевой игры. Эти команды помогут всегда (или почти :). Но для конкретной ситуации - конкретная конфигурация.

cl_updaterate ## - количество пакетов (согласований), посланых от сервера - клиенту за еденицу времени (секунду). Эта команда напрямую связана со скоростью соединения и имея 28.8 кбод нет смысла ставить значение больше 15 (лучше 10). Потому что поделить 2.5 кб/сек на 15 и получим небольшой размер "пакета" данных на одно согласование (маловато будет). Так что для 28.8 ставьте cl_updaterate "10" и не больше.

При соединении 28.8 Кб, cl_updaterate (1/сек) от 10* до 15

При соединении 33.6 Кб, cl_updaterate (1/сек) от 15* до 20

При соединении 48.8 Кб и более, cl_updaterate (1/сек) от 20* и более

* - Оптимальное значение

cl_cmdrate ## - количество согласований в секунду, посланных от клиента - серверу. Тут дело такое: если Ты хочешь общаться по микрофону и хочешь, чтобы другие игроки слышали твой голос, а не "дизельный выхлоп" или хуже, то ставь значение 30. Но как известно единовременно исходящий и входящий потоки они:как два медведя в одной берлоге, взаимоуменьшают друг друга. Так что если общаться голосом не предвидится, то ставь от 10 до 20. В принципе для 28.8 cl_updaterate "10" и cl_cmdrate "30" вполне приемлемо. На каждые три согласования со стороны клиента - одно со стороны сервера. Сойдет!

rate #### - Поток (в байтах) со стороны сервера. Вообще эта величина должна быть ниже скорости модемного соединения примерно на 20-30% (потому что исходящий поток тоже существует и, заняв все 100% пропускной способности линии, Вы себя обречете).
При соединении 28.8 Кб, rate (бит/сек) от 2000 до 2500

При соединении 28.8 Кб, rate (бит/сек) от 2000 до 2500

При соединении 33.6 Кб, rate (бит/сек) от 2500 до 3000

При соединении 48.8 Кб и более, rate (бит/сек) от 3000 и выше

Если задать значение больше допустимого - лови FlushEntityPacket, сервер закидает тебя "пакетами" по твоему же требованию в удобный для него момент. Учтите, что для большого числа игроков (16-20) скорость соединения играет большую роль. Не рекомендуется ставить максимальное значение, если пакеты часто не доходят: на их "перепосылку" надо иметь "резерв".

cl_latency -### - Компенсация лагов. Величина, необходимая для хоть какого-то скрашивания серых будней "модемного" игрока. Задаётся как 50% или 75% от текущего пинга с противоположным знаком (100% имеет эффект, но не стОит столько задавать). Например для пинга 200 подойдет cl_latency "-150". Эта величина ОЧЕНЬ важна. Но в КС1.6 она не используется.

cl_rate #### - Тоже, что и rate, но со стороны клиента. Величина не столь важная, т.к. клиент никогда не сможет использовать её на 100% (только когда происходит закачка "лого" на сервер). По умолчанию стоит cl_rate "9999", так и оставим.

fps_max ### - Как уже видно из названия - максимальный FPS в игре. Обычно ставят 100. Это зависит от "мощности" машины. В принципе от 60 до 100 - вполне приемлемое качество. НО, без следующей переменной вы не увидите эти FPS вообще.

fps_modem ### - А вот это то, что надо. Приравниваем fps_modem к fps_max и всё. Ходит мнение, что fps_modem должна ровняться cl_updaterate. Представляете "дурдом" в 20 FPS? Я из принципа fps_max "100" и fps_modem "100" поставлю. К тому же без высокого значения fps_modem нельзя проделать кое-какие "грязные" трюки. Но у этих переменных есть и МИНУСЫ. "Лагает" сильнее, т.е. чаще при высоком fps_modem, чем при низком. Так что ставьте от 60 до 100.

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

Напоследок приведу стандартный "конфиг" для скорости соединения 33.6 кбит/сек.

cl_updaterate "15"
cl_cmdrate "30"
rate "2500"
fps_max "60"
fps_modem "60"

А в autoexec.cfg неплохо бы добавить:
//При latency или пинге в 200мс
cl_latency "-150"
//Использование MMX. Не известно правда, что дает
r_mmx "1"
//Для того, чтобы голос свой слышать наряду с другими игроками.
voice_loopback "1"

Автор: GiNGeR