вторник, 27 марта 2012 г.

СЕТЕВЫЕ КОМАНДЫ

   Привет геймер! В этой статье продолжу серию «консольных команд» для CS и разберу некоторые из наиболее значимых отвечающие за связь клиента и сервера. И так начнем.

 cl_cmdrate: команда определяет сколько пакетов в секунду пошлете вы, клиент к серверу. Очевидно, чем выше это значение, тем быстрее сервер реагирует на действия, которые вы совершаете (поворот мышью, прыжок, бег, стрельба и прочее). Итак, если вы на выделенной линии и притом очень хорошей, то смело ставьте высокое значение. Если же вы подключили к своей DSL Cable или что там у вас, ещё и своего друга — вы наверняка будете наблюдать частые и высокие скачки лага. Это все из-за высокого значения команды. Большинство высокоскоростных доступов к Интернету не могут дать возможность установления высокого значения upload (к примеру, большинство aDSL которые предоставляют компании — 768download (где-то 90КБ)/128upload (16КБ)), который так необходим для этой команды.



cl_updaterate: это противоположность cl_cmdrate — количество пакетов/секунду которые вы получаете от сервера (ваша download скорость). Здесь, чем выше значение, тем более вы синхронизированы с сервером. Так как только сервер решает, попадают ваши выстрелы или нет, то вам нужно большое количество обновлений информации с сервера — ради эксперимента, попробуйте поставить значение cl_updaterate в 5-10 — и попробуйте убить кого. Получится интересная картина — вы будете ещё стрелять по противнику, а на его мониторе, он вас как секунду назад убил.

sv_maxupdaterate: команда контролирует количество пакетов/секунду которое позволено серверу послать клиенту. Из этого следует, что если на сервере sv_maxupdaterate «60″, а на клиенте cl_updaterate «101″ то клиент будет обновляться со значением cl_updaterate «60″

sys_ticrate: команда устанавливает количество «кадров» в секунду, которые сервер может вычислить. По умолчанию значение равно 100. Почему серверные fps так важны? А этот параметр как раз таки и отображает, как «чувствует себя» сервер. Мы все, когда нить играли на очень хороших серверах, что складывалось такое впечатление, что они хостуются на Tl-83 plus и мы могли бы поклясться что играем мы на LAN а не на HSI-net sys_ticrate только присваивает максимальное значение fps которые может осилить ваш server. Но на деле сервер не может дотянуть без помощи до такого sys_ticrate — это связано и с некоторыми процессами в самой операционной среде, но в основном из-за провайдера. Имейте ввиду, что увеличение fps «загружает» и сам процессор сервера. (Кстати такое «увеличение» каким-то образом загружает процессор по максимуму на таких картах как de_inferno и de_aztec). По умолчанию сервер, основанный на Win32 выдает среднее fps 64, а на Linux — 50fps. «Ускорение» сервера дает возможность получить fps выше 512 в некоторых случаях. Влияние такое высокого серверного fps достаточно спорное, но я думаю вы с легкостью заметите разницу в игре уже при 200fps. Целостность — вот главное. Скачки fps со 100 до 512 скорее всего создадут больше проблем, так что разумным будет ограничить sys_ticrate в районе 150-200, если конечно сервер позволяет стабильно работать при 150-200. Если у вас есть rcon пароль к серверу, вы можете с легкостью проверить серверный fps — напишите rcon stats в консоли, чтобы проверить, «ускорен» ли ваш сервер, временно поставьте значение sys_ticrate «10000″ и исполните команду rcon stats. Если ваш fps выше чем 1000 — значит «ускорен».

ex_interp: интерполяция — это восстановление значения функции в промежуточной точке по известным ее значениям в соседних точках. Итак, вы не можете быть синхронизированы с сервером на все 100% в каждую секунду времени, так как вы получаете ограниченное количество обновлений в секунду с сервера. Когда увеличивается количество обновлений, интерполированная фигура становится более аккуратной. В CS данной фигурой выступает движение игрока в секунду времени. Сервер в данном случае будет тем самым «идеальным кругом» (ведь только сервер имеет абсолютно точную позицию игрока в каждую секунду времени), а вот клиенту придется интерполировать между двумя «верными» пакетами. Вот здесь и появляется ex_interp. Данная команда отражает количество времени (в секундах) для интерполяции между каждым «удачным» обновлением с сервера. Так как интерполяция относится к клиентской части, то естественно возникают неточности и ошибки в самой игре. Так как мы не можем получить 100% точных обновлений с сервера (особенно в Интернете) то интерполяция играет важную роль в самой игре.

Рекомендации для online игры:

rate: я практически уверен что значение 20000 будет доступно большинству высокоскоростных Интернет соединений. А вот использование значений выше 20000 может наоборот привести к снижению производительности. Рекомендую: rate 20000

sv_maxrate: значение в большинстве своем равно 0. Объясню почему это скорее всего не оптимально для online игры. sv_maxrate «0″ будет определять значение rate для каждого клиента и пытаться заполнить его заполнить. Представьте что движок HL позволяет игрокам использовать значения rate выше 20000 (например 999999999999), и сервер будет пытаться заполнить все 999999999999. Это приведет к пустому увеличению нагрузки на канал сервера. Я советую безопасное и вместе с тем хорошее значение sv_maxrate «20000″. В большинстве случаев sv_maxrate 0 и sv_maxrate 20000 будут эквивалентны, но береженного бог бережет. Рекомендую: sv_maxrate 20000

cl_cmdrate: в идеале значение этой команды должно быть равно серверному (!- большинство людей считают что клиентским – в корне не верно) fps. Если вы посылаете серверу пакеты чаще чем он способен обработать — (скажем серверный fps=80, а значение cl_cmdrate 101) то некоторые пакеты будут просто «скинуты» сервером, необработанны ( 101-80=21 необработанный пакет). По сути эти 21 пакета погоды не делают, просто приведут к забиванию вашего upload (и увеличению трафика), что тоже погоды не делает. Рекомендую: смело ставим cl_cmdrate равное серверному fps либо выше.

ex_interp: ставим в 0 без размышлений. CS автоматически поставит ее значение ex_interp= 1/cl_updaterate (в консоли увидите “ex_interp forced up to xx msec”). При значении 0, изменение значения команды cl_updaterate будет автоматически менять и значение ex_interp. Я РЕКОМЕНДУЮ МЕНЯТЬ ЗНАЧЕНИЕ ТОЛЬКО CL_UPDATERATE, ПОЗВОЛЯЯ CS поменять значение ex_interp. Вы уже не можете поставить значение ex_interp ниже чем 1/cl_updaterate, а вот ставить его выше — это уже просто нечестно. Ставить значение выше 1/cl_updaterate приведет к тому, что вам придется стрелять немного позади модельки противника (получается так, что вы видите противника немного раньше, чем положено). К примеру, при использовании cl_updaterate 101, верное значение ex_interp= 1/101=0.009, но по умолчанию ex_interp= 0.1, а это выше чем 1/101- вот тут и возникает глюк… Рекомендую: ex_interp 0- стреляем туда, куда целимся

cl_updaterate: бытует мнение что значение данной команды надо подбирать следующим методом: присваиваем значение cl_updaterate 101 и снижаем его до тех пор пока параметр choke (его можно увидеть, если набрать в консоли команду net_graph 3) не будет равен 0 или очень низок. По мне, так choke — это самое последнее о чем стоит беспокоиться. Правильное значение cl_updaterate — это более глубокий вопрос чем просто choke. Значение sv_maxupdaterate на сервере для чемпионатов должно иметь значение 101 (так настроен сервер для CAL CPL) — из этого можно сделать вывод, что в идеале значение cl_updaterate=101. Однако большинство серверов в online имеют значение sv_maxupdaterate «30″ или просто неспособны, вычислить 101 sv_maxupdaterate. Из чего следует, что сервер просто неспособен послать вам 101 пакет/секунду. Так все-таки, какое значение? Большинство могут сказать «Я поставлю 101, а сколько дойдет — всё моё», но тут уже играет отрицательную роль высокое значение ex_interp, что нарушит баланс между этими командами. Для того, чтобы подобрать оптимальное значение cl_upodaterate (ex_interp «0″) ставить в 101 и начинаем снижать его до тех пор пока модельки игроков не будут слегка двигаться скачками (при ex_interp 0 и cl_updaterate 101 — они будут очень сильно пропускать). Не надо бояться ставить значение cl_updaterate ниже 50, если это необходимо. Большинство серверов sv_maxupdaterate «30″ так что cl_updaterate 30 будет лучшим значением. Стоит отметить, что начинать подборку cl_updaterate надо «сверху вниз» а не наоборот. Рекомендую: равно серверному fps и не выше sv_maxupdaterate

sys_ticrate: для нахождения оптимального значения данной переменной необходимо произвести несколько экспериментов. Прежде всего, если сервер не «ускорен» то значение переменной ticrate выше 100 ни к чему не приведет. Если же сервер находится на хорошей платформе (хороший провайдер), то есть «ускоренный», у вас появляется место для полета фантазии. Не смотря на то что «чем больше серверное fps тем лучше», эффект от увеличения sys_ticrate выше 200 (а может и еще меньше) на самом деле не окажут такого уж хорошего влияния на игру. А вот использовать sys_ticrate «200″ или ниже сделает игру более стабильной даже если придется пожертвовать минимальным количеством производительности. Представьте вдобавок, что компьютер, используемый под игровой сервер тянет аж несколько HLDS (например CS1.6 и CZ) и для обоих sys_ticrate «10000″ нагрузка на процессор возможно будет чрезмерной. Такое положение вещей может привести к потери производительности самой игры. В конце можно добавить, что если вы хотите получить, скажем, 140fps то вам нужно выставить значение sys_ticrate выше предполагаемого где-то на 20-50. (Например, сервер может спокойно тянуть 150fps, значит, значение sys_ticrate будет 150+30= 180.) Рекомендую: sys_ticrate 110-180 — зависит от качества сервера.

Про LAN

Почему, же большинство известных турниров, таких как CPL, WCG используют cl_updaterate 101 — зависит от качества сервера. На таких чемпионатах все сервера обычно «ускорены» что делает реальным такое высокое значение cl_updaterate. Для того чтобы быстро узнать «ускорен» ли сервер, достаточно просто обратить внимание на пинг — у простого сервера, fps которого 50-60, все игроки имеют средний пинг 15ms, а вот на «ускоренном» — 5 ms.

Вот наверно на этом пока все. И дальше буду рассматривать разные описания и настройки консольных команд. До новых встреч!

Комментариев нет:

Отправить комментарий