смысл не изменился, на сухом языке фраза 'чем больше этих тиков, тем плавней у клиента будет картинка(меньше лагов)," на сухом языке примерно так- чем больше тикрейт, тем лучше.Очень неточно сформулированное разъяснение. Это как раз у сервера "картина" игрового мира от высокого тикрейта будет плавнее. Клиент - это отдельная песня, он как зеркало для сервера, при том обычно кривое :) .
Фраза "чем больше у вас тиков с сервером" вообще бредом попахивает.
Насчет зависимости от канала и железа. Допустим есть 100-тиковый сервер. Он будет 100-тиковым, и должен выдавать 100 тик, даже если канал отдачи позволяет отправить каждому клиенту лишь 80 пакетов, вместо 100. И страдать от этого сервер не будет, в отличии от клиентов, которые недополучат 20 пакетов каждую секунду, а это серьезные лаги.
Зависимость от железа, то-есть показателя FPS сервера более очевидна. Если пригрузить сервер до уровня 80FPS, 100 тиков он никак не успеет просчитать. И теперь лаги будут и на стороне сервера тоже.
Осталось добавить, что в Source есть 3 значения серверных тикрейтов: или 33, или 66, или 100.
Первоначально там было написано пакетов, но после не большой дискусии выше твоего поста я исправил на байты.Не верно. Это переменная клиента, указывающая серверу максимальное количество байт, которое клиент готов принять от сервера за секунду.
Часто считают, что она должна отражать ширину входящего канала клиента, но для движка Source это не совсем так, верней, совсем не так.
Именно заниженное значение переменной есть частой причиной появления choke, т.е. пакетов, которые не доходят до клиента из-за узкого канала либо лимитированного rate'ом объема трафика за секунду.
Допустим, у меня канал на скачку 256kbit/s. Сервер за одну секунду хочет отдать моему клиенту 16000 байт. Но на клиенте стоит rate 10000. И сервер пошлет лишь 10000, ведь мой клиент сказал ему, что готов принять лишь столько. А остальные 6000 сервер просто обрежет и выбросит. В результате мой клиент недополучит ХХнадцать идущих подряд пакетов, что и отразиться на датчике choke.
В идеале, на движке Source клиент может установить себе как можно большее значение rate, даже в случае, если его входящий канал сможет пропустить в несколько раз меньше байт. Например, при rate 100000 датчик choke практически всегда будет показывать 0.
Увы, очень мало серверов, у которых достаточно широкий канал отдачи для всех клиентов и переменной sv_maxrate 100000. В основном из-за незнания админами сетевого протокола Source'а.
Потому, ставить rate выше, чем sv_maxrate сервера проку особого, к сожалению, нет.
тоже, что было написано выше.Опять же, это количество пакетов, которое клиент хочет послать серверу.
Именно из-за заниженного значения этой переменной можно видеть на сервере игрока с минимальным пингом, но со страшными дерганиями и задержками анимации и действий. Попасть в такого игрока становиться трудно, ведь инфа о клиенте при низком cmdrate приходит редко, и серверу трудно угадать где ж эта св*лочь на самом деле находиться. В Source 2007, если я правильно понял, новый сетевой код позволяет серверу более удачно регистрировать попадания в таких лагеров.
Как и в случае с updaterate, cmdrate нужно брать в зависимости от ширины канала клиента на отдачу. Можно также учесть, что фактический cmdrate не будет выше за FPS в игре (точно так же как updaterate и tickrate выше FPS сервера).
Значения cmdrate, в зависимости от размера исходящего канала, для игры на Source-сервере несколько менее требовательны, ведь там информация только об одном игроке (клиенте):
до 32 kbit/s »» cl_updaterate 33
на 64-128 kbit/s »» cl_updaterate 66
на 256 kbit/s и выше »» cl_updaterate 100
Что не так? Результат моих расчётов полностью совпадает с информацией на этом сайте.Надеюсь, будет учтено все выше мною изложенное.
Отлично особенности сетевого кода Source описаны тут: http://www.jason35.com/Netcode.htm (на английском).
А от этого я не знал.сталось сказать, что update/cmdrate могут иметь значения 0-100. И максимальное определяется не всегда тикрейтом (помним о sv_maxupdaterate, sv_maxcmdrate).
Первое число идет размер в байтах последнего полученного пакета, за ним правее входящий трафик в килобайтах/с, и только последнее крайнее правое число - число полученных пакетов за секунду.
Первоначально было написано что первое этой размер в байтах, но после не большой дискусии выше твоего поста было я изменил наПервое число идет размер в байтах последнего отосланного пакета, за ним правее исходящий трафик в килобайтах/с, и только последнее крайнне правое число - число отправленных пакетов за секунду.
число передаваемых пакетов
Ты не правильно понял моё предложение. На сухом языке будет звучать так - чем меньше пинг тем лучше.Быстрее hit registration на сервере - да. Но не быстрота вылета пуль.
Эта статья на 55% рерайт, 45% получены вбиванием команд в консоль.P.S. Одно интересно, зачем браться писать мануалы, если человек явно сам в вопросе плавает?
1. TF2 моложе ксс.Еще не разу не видел, что бы игроков TF2 было хотя бы в половину КССовцев. И дело тут не в том, что в стате берутся только игроки с лицензий.
2. СРС 2007 более новый.
Я думаю, я нашёл правильные ответы твоей критике. Исправлю биты на пакеты и добавлю инфу про sv_maxrate...(этого я действительно не знал.)
ЗЫ Проверял эти настройки. На сервере ксмании разницы вообще не почуствовал, а вот на этом ,не сочтите как рекламу, появились изминения в лучшую строну.[/spoiler]
