Ось під такою нехитрою назвою вийде, напевно, остання стаття щодо мережевого коду 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.

а как же прицел)

и Динамичность