Что такое рейт в CS:GO, какой рейт ставить в кс го

Сетевые настройки всегда были очень сложной и часто обсуждаемой темой в кс, и все еще существует большое количество недоразумений относительно сетевых настроек в CS:GO. Мы постараемся изложить всю суть дискуссий по сетевым настройкам и объясним, какие сетевые настройки вам следует использовать для соревновательной игры.

Объяснение переменных конфига

rate 786432 (означает 196608)
Максимальное количество данных в байтах/ сек., которое может принять хост
cl_cmdrate 128 (по умолчанию 64, мин. 10,000000 макс. 128,000000)
Максимальное количество командных пакетов, отправляемых на сервер в секунду
cl_updaterate 128 (по умолчанию 64)
Количество обновлений пакетов в секунду, которые вы запрашиваете с сервера
cl_interp 0 (по умолчанию 0,03125, мин. 0,000000 макс. 0,500000)
Устанавливает количество интерполяции (ограничено нижним уровнем с помощью серверных настроек коэффициента взаимодействия)
cl_interp_ratio 1 (по умолчанию 2.0)
Устанавливает количество интерполяции (окончательное количество cl_interp_ratio / cl_updaterate)

В сентябре 2016 года Valve обновила некоторые аспекты сетевых настроек CS: GO и увеличила рейты по умолчанию с 80000 до 196608, что позволяет подключать пользователей со скоростью Интернета 1,5 Мбит/с и выше.

Они также увеличили настройки максимального рейта до 786432 для пользователей со скоростью не менее 6 Мбит/с. Если ваша пропускная способность составляет 6 Мбит/с или более, вы должны использовать новые максимальные рейты 786432, чтобы CS: GO мог передавать больше трафика от сервера к вашей системе.

Старые и новые хитбоксы

15 сентября 2015 года Valve выпустили обновление, которое улучшило старый “скелет” игрока и систему хитбоксов в CS: GO. Они также заменили все анимации игроков, чтобы избавиться от некоторых по настоящему раздражающих ошибок. Пользователь форумов reddit под ником whats0n просмотрел файлы моделей и опубликовал очень хорошее изображение со сравнением старой и новой систем хитбоксов.

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

Упростим и подведем итог

На стороне клиента:

fps var: низкое значение = хорошо
fps var: высокое значение = плохо

На стороне сервера:

64 тикрейт: sv <15.625 мс = хорошо 64 тикрейт; sv> 15,625 мс = плохо
128 тикрейт: sv <7,8 мс = хорошо 128 тикрат; sv> 7,8 мс = плохо

В чем разница между 64- и 128-тиковыми серверами

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

Конечно, это очень примитивное объяснение, но чтобы понять преимущество более высокого тикрейта, вам, прежде всего, нужно понять основы многопользовательской сети в движке Source. Мы могли бы перефразировать эту информацию своими словами, но мы считаем, что вам стоит самим прочитать официальные слова от Valve:
“Сервер симулирует игру в дискретных временных интервалах, называемых тиками. По умолчанию временной интервал составляет 15 мс, поэтому 66,666… тиков в секунду имитируются, но моды могут установить свой собственный тикрейт.

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

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

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

Кроме того, каждый клиент имеет разные задержки сети, которая меняется со временем из-за другого фонового трафика и частоты кадров клиента. Эти различия во времени между сервером и клиентом вызывают логические проблемы, которые усугубляются с увеличением задержек в сети.

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

Если вам интересно глубже разобраться в сетевом коде CS: GO, мы настоятельно рекомендуем вам посмотреть «Анализ сетевых кодов» от Battle(non)sense. Он хорошо покахал основы сетевого кода в онлайн-играх, а также измерил задержки в CS: GO и сравнил их с другими играми.