Небольшое HowTo:

Эта оптимизация имеет смысл только для невысоких cl_updaterate. При приближении значения cl_updaterate к клиентскому фпс она теряет смысл и появляется пинг 4-5. Причина появления - как раз таки низкий клиентский фпс.

Оптимизация работает только когда сервер получает больше пакетов, чем требуется отправлять клиенту (иными словами, при cl_cmdrate > cl_updaterate)

Разность cl_cmdrate и cl_updaterate не должна быть большой. Максимальную разность, которую может компенсировать оптимайзер задается кваром xds_boostfactor в долях cl_updaterate. Например, при cl_updaterate 40 и xds_boostfactor 0.4 максимальный cl_cmdrate будет 40+(40*0.4) = 56. Если поставить значение выше, то синхронизация upd и cmd пакетов сбивается, и время отклика увеличивается.

Для любителей низкого пинга: ставим xds_boostfactor 10. Тогда оптимизация будет работать даже при cl_updaterate 40 и cl_cmdrate 101. Но помните, что значение cl_updaterate будет игнорироваться и сервер будет отвечать upd пакетом на каждый cmd пакет, что приведет к росту исходящего трафика и загрузки цп.

Что надо сделать, чтобы достичь минимального пинга? Ответ ниже:
o На клиенте должен быть стабильный фпс. Неважно, 60 или 100, главное, что он не должен прыгать.
o Клиент должен отсылать cmd пакеты через равные промежутки времени. Контролируется это самым нижним графиком в net_graph 2
Xds Optimizer, Оптимизация соединений ClientHLDS

Каждая точка на графике - это отрисованный клиентом кадр. Красная точка означает, что в момент отрисовки этого кадр не был послан cmd пакет. Прозрачная точка означает, что cmd пакет был послан. Этот график должен быть либо полностью прозрачным (клиент отсылает данные каждый фрэйм, достигается установкой cl_cmdrate 101), либо данные должны отсылаться через кадр, как показано на картинке. Для этого ставим cl_cmdrate = client_fps/2 + 10.
o ставим cl_updaterate на 10 меньше cl_cmdrate.
o На стороне сервера должен быть стабильный фпс >200
o choke и loss быть не должно! Универсальный рецепт от choke - ставить sv_minrate 50000
o Помните, что красивый маленький пинг не отражает реальной задержки. Минимальная задержка достигается установкой cl_cmdrate 101, cl_updaterate 101 (если это позволяет сервер)

Чтобы не было подозрений, что пинг 0 - это фэйк, я расскажу как он расчитывается. Во-первых, пинг (это то что отображается в столбце Latency в Scoreboard) - это задержка ответа клиента относительно сервера. В упрощенном варианте - сервер посылает запрос на клиент и ждет, когда он ответит. После этого находится время время между посылкой и ответом - это есть реальная игровая задержка. Далее из этого времени вычитается интервал посылки обновлений, и в результате получается то, что с точки зрения hlds называется пингом. Интервал посылки обновлений находится как 1/cl_updaterate, то есть при cl_updaterate 40 интервал обновления равен 1/40 = 0,025сек = 25мсек.
Пинг 0 означает, что реальная задержка в игре меньше интервала обновления, а не то, что ее совсем нет. Вот так.

Плагин работает только на новых серверах, движок для патчинга взят с dproto. Все кто сидит на всяких 3647 и 2738 идут в трещину smile.gif

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

Как устанавливать:

* Создаем папку gamedir/addons/xdsopt
* Распаковываем в нее архив
* Открываем текстовым редактором gamedir/addons/metamod/plugins.ini, добавляем туда строку
под Windows:
win32 addons\xdsopt\xds_opt.dll

под Linux:
linux addons/xdsopt/xds_opt.so

* Запускаем сервер, после запуска смотрим meta list. Если статус плагина не RUN, значит ваш билд не поддерживается.
* Даем серверу команду xds_stat. Вывод должен быть таким:

[XDSOPT]: Current Status: Active (100)
[XDSOPT]: Owner: DemoVersion
[XDSOPT]: Custom Message:

* Все, установка закончена