Может потому, что его там нет?) Потому и не дал)))
Может кто-то успел скачать пока он там был :crazy:
Лучше бы спасибо сказал)))
В треше на alliedmods этот плагин находится отнюдь не потому, что он "плохой", а потому, что он форсирует рейты через эксплойт :)
Но это не суть, главное работает отлично и все довольны :)
автовыдача Rate для Соурсмода в CS:S
Очень хороший плагин enforcer, действительно устойчиво меняет rate клиента, но есть несколько багов:
Он нормально работает, если у клиента rate < sv_minrate
Тогда он меняет у клиента rate, cl_updaterate, cl_cmdrate
Но если у клиента rate>= sv_minrate
Тогда он не реагирует на cl_updaterate, cl_cmdrate.
Прошу тех, кто мастер скриптов соурсмода, сделать так, чтобы он реагировал и на cl_updaterate, cl_cmdrate, если
sv_maxupdaterate<cl_updaterate<sv_minupdaterate
sv_maxcmdrate<cl_cmdrate<sv_mincmdrate
Я использую плагин от xaider - ratewatcher. Но он не может принудительно менять рейты клиента.
Если уважаемый xaider может сделать такие же проверки, как в ratewatcher плагине (на диапазон cl_updaterate и cl_cmdrate),
то будет очень даже шикарно.
Лично мне было бы удобнее, чтобы был один плагин, а не два.
И сама идея enforcer -использовать VGUI для принуждения к прописыванию правильных параметров - очень даже правильная. Т.к., как показала практика - игроки - упрямые бараны (уж извините... но факт... ). Никакие выскакивающие сообщения, меню, киканье, замораживание, взрывание и т.п. издевательства не помогают заставить 90% игроков сделать то, что просят.
P.S. xaider - я не знал, что ты - русский... я то парился писал на англ. свои просьбы на офф форуме соурсмода.
Он нормально работает, если у клиента rate < sv_minrate
Тогда он меняет у клиента rate, cl_updaterate, cl_cmdrate
Но если у клиента rate>= sv_minrate
Тогда он не реагирует на cl_updaterate, cl_cmdrate.
Прошу тех, кто мастер скриптов соурсмода, сделать так, чтобы он реагировал и на cl_updaterate, cl_cmdrate, если
sv_maxupdaterate<cl_updaterate<sv_minupdaterate
sv_maxcmdrate<cl_cmdrate<sv_mincmdrate
Я использую плагин от xaider - ratewatcher. Но он не может принудительно менять рейты клиента.
Если уважаемый xaider может сделать такие же проверки, как в ratewatcher плагине (на диапазон cl_updaterate и cl_cmdrate),
то будет очень даже шикарно.
Лично мне было бы удобнее, чтобы был один плагин, а не два.
И сама идея enforcer -использовать VGUI для принуждения к прописыванию правильных параметров - очень даже правильная. Т.к., как показала практика - игроки - упрямые бараны (уж извините... но факт... ). Никакие выскакивающие сообщения, меню, киканье, замораживание, взрывание и т.п. издевательства не помогают заставить 90% игроков сделать то, что просят.
P.S. xaider - я не знал, что ты - русский... я то парился писал на англ. свои просьбы на офф форуме соурсмода.
-
pinkpiton2
- Майор
- Сообщения: 724
- Зарегистрирован: 06.08.2008
- Откуда: Одесса
- Благодарил (а): 1 раз
- Поблагодарили: 1 раз
кстати при менюшку ratewatcher-а по нажатию нуля можно закрыть
чего вродь по всем раскладам быть не должно
может кто из гуру растолкует где блокировать чтобы оно висело до полного окончания таймаута (он у меня больше времени заморозки)
по поводу rateenforcer-а - вродь всё работает, но уж очень оно квадратно работает
лучше бы оно само смотрело на серверные квары и выставляло минимум от них если не попадает игрок в диапазон
2Yogurt: выложи оригинал если он остался, а то русификация хардкодом не есть очень правильно
чего вродь по всем раскладам быть не должно
может кто из гуру растолкует где блокировать чтобы оно висело до полного окончания таймаута (он у меня больше времени заморозки)
по поводу rateenforcer-а - вродь всё работает, но уж очень оно квадратно работает
лучше бы оно само смотрело на серверные квары и выставляло минимум от них если не попадает игрок в диапазон
2Yogurt: выложи оригинал если он остался, а то русификация хардкодом не есть очень правильно
вот прямая ссылка, если зареген там
http://hlmod.ru/forum/showthread.php?p=3368
или отсюда
http://file.qip.ru/file/122492937/aa32a ... orcer.html
Добавлено спустя 3 минуты 35 секунд:
Рейты такого игрока не меняются.. а надо бы.
http://hlmod.ru/forum/showthread.php?p=3368
или отсюда
http://file.qip.ru/file/122492937/aa32a ... orcer.html
Добавлено спустя 3 минуты 35 секунд:
Он не работает, если на сервере maxcmdrate 66, а заходит игрок с cmdrate 100.pinkpiton2 писал(а): по поводу rateenforcer-а - вродь всё работает, но уж очень оно квадратно работает
лучше бы оно само смотрело на серверные квары и выставляло минимум от них если не попадает игрок в диапазон
Рейты такого игрока не меняются.. а надо бы.
В этом и фишка, что там можно настроить, чтоб выставлялись минимальные рейты, а не фиксированные.pinkpiton2 писал(а): лучше бы оно само смотрело на серверные квары и выставляло минимум от них если не попадает игрок в диапазон
2 VamPiro32
Сервер сам нормально правит cl_cmdrate и cl_updaterate. Их и форсировать не надо.
Словосочетание "прямая ссылка" имеет несколько другое значение ;)
Я не совсем понимаю по какому алгоритму сервер "правит" клиентские cl_cmdrate и cl_updaterate.
Пример: -tickrate 33 sv_maxcmdrate =66 cl_cmdrate = 100
Вариантов несколько:
1) клиент посылает 100 пакетов, но сервер принимает только 66, остальные отбрасывает, -> засоряя канал, сетевуху и процессор сервера. При этом мир обрабатывает всё равно 33 раза и не понятно, что он делает с 66 пакетами.
2) клиент посылает 100 пакетов, но сервер принимает только 66, каким-либо образом усредняя выборку, -> засоряя канал, сетевуху и процессор сервера. При этом мир обрабатывает всё равно 33 раза и не понятно, что он делает с 66 пакетами.
3) сервер посылает клиенту настройку, согласно который клиент теперь отсылает не 100 пакетов, как прописано в конфиге клиента, а только 66. При этом мир обрабатывает всё равно 33 раза и не понятно, что он делает с 66 пакетами.
Вроде как почти идеальный вариант, только не верится, что так и работает. Особенно если посмотреть sm_rates
Поэтому, чтобы не проводить научных изысканий, не писать писем программистам Valve гораздо проще и логичней заставить прописать всех клиентов на сервере cl_cmdrate = 66, а ещё лучше cl_cmdrate = 33.
Чего собственно я и хочу от энфорсера или ratewatcher.
Пример: -tickrate 33 sv_maxcmdrate =66 cl_cmdrate = 100
Вариантов несколько:
1) клиент посылает 100 пакетов, но сервер принимает только 66, остальные отбрасывает, -> засоряя канал, сетевуху и процессор сервера. При этом мир обрабатывает всё равно 33 раза и не понятно, что он делает с 66 пакетами.
2) клиент посылает 100 пакетов, но сервер принимает только 66, каким-либо образом усредняя выборку, -> засоряя канал, сетевуху и процессор сервера. При этом мир обрабатывает всё равно 33 раза и не понятно, что он делает с 66 пакетами.
3) сервер посылает клиенту настройку, согласно который клиент теперь отсылает не 100 пакетов, как прописано в конфиге клиента, а только 66. При этом мир обрабатывает всё равно 33 раза и не понятно, что он делает с 66 пакетами.
Вроде как почти идеальный вариант, только не верится, что так и работает. Особенно если посмотреть sm_rates
Поэтому, чтобы не проводить научных изысканий, не писать писем программистам Valve гораздо проще и логичней заставить прописать всех клиентов на сервере cl_cmdrate = 66, а ещё лучше cl_cmdrate = 33.
Чего собственно я и хочу от энфорсера или ratewatcher.
На серве прописываешь sv_maxcmdrate 66 и sv_mincmdrate 66 и будет у всех cl_cmdrate 66.
Не понимаю чё из-за ерунды такую тему раздули...да ещё и программистам вальвы собрались писать
Не понимаю чё из-за ерунды такую тему раздули...да ещё и программистам вальвы собрались писать
Такое впечатление, что мой предыдущий пост не прочитан.
А какой "умник" будет ставить sv_maxcmdrate 66 на 33-тиковом сервере?)))VamPiro32 писал(а): Пример: -tickrate 33 sv_maxcmdrate =66 cl_cmdrate = 100
Если сервер 33 тик, а у клиента cl_cmdrate 100 и cl_updaterate 100, то сервер "скажет" клиенту, что может принять/отдать лишь 33 пакета, на что клиент выставит эти значения. Если через sm_rates это не видно, то по нетграфу это очень даже видно))
По сути "правильщики" рейтов нужны только потому что не работает серверный cvar sv_minrate
Вот эта тема поможет разобраться с рейтами.
А форсировать cl_cmdrate и cl_updaterate к единому значению = не уважать игроков (не считая 33 тик сервера, конечно)
1) Я уже писал, что не понятен алгоритм уравнивания кол-ва пакетов между сервером и клиентом.
То, что показывает нетграф(применительно к updaterate) - говорит только о двух параметрах:
- кол-ве пакетов в сек то ли дошедших до клиента, то ли принятых клиентом, то-ли отправленных клиенту - 55,1/s
- фиксированное значение клиентского updaterate 140/s.
Ситуация совсем не ясна. То-ли просят, а не дают. То-ли просят, дают, но не доходит. То-ли просят, дают но не могут принять. Во всех 3-х случаях показания нетграфа будут одинаковые, а вот с сетью и с нагрузкой на сервер всё будет сильно отличаться.
2) На сервер, смотрящий в интернет заходят люди с совершенно разным каналом до сервера.
2 ситуации:
а) Клиент из Германии. С сетью у него всё в порядке... лоссов нет, комп шустрый. Но пинг клиента до сервера 180.
б) Клиент из России - Миг-телеком - пракически у всех маленький пинг, но БОЛЬШИЕ потери (лосс) - 5-10%. Лаги обеспечены.
Оба клиента имеют 100Мб выход в инет, крутые компы и гнут пальцы, что у них должен быть cmd, update = 100 или иногда особо крутые "пацаны" ставят 101.
Им пофиг, что где-то на канале от них до сервера узкое место или несколько узких мест, повышающих их пинг или создающих лоссы.
С учётом собственных алгоритмов усреднения сервера гораздо честнее оставить на сервере немца - он не будет дёргаться.
Сервер не знает - почему лаги... то-ли клиентский комп не успевает, то-ли его канал до сервера лимитирует.
Но вполне можно попробовать уменьшить пинг и лаги путём уменьшения клиентского updaterate, cmdrate. Я проверял - очень часто это помогает уменьшить его пинг и даже лоссы.
Только после этого включать проверку на превышение допустимого пинга на сервере.
3) многие игроки даже не знают как поменять updaterate, cmdrate. Они просто скачали "пацанские" конфиги.
4) Я, как администратор сервера ДОЛЖЕН заботиться не о конкретном "отце" и его обидах, а об основной массе игроков.
С учётом всего этого безобразия я не вижу ничего обидного в уменьшении клиентского updaterate, cmdrate. Вижу только пользу ОСТАЛЬНЫМ игрокам сервера с нормальным пингом и без лоссов.
То, что показывает нетграф(применительно к updaterate) - говорит только о двух параметрах:
- кол-ве пакетов в сек то ли дошедших до клиента, то ли принятых клиентом, то-ли отправленных клиенту - 55,1/s
- фиксированное значение клиентского updaterate 140/s.
Ситуация совсем не ясна. То-ли просят, а не дают. То-ли просят, дают, но не доходит. То-ли просят, дают но не могут принять. Во всех 3-х случаях показания нетграфа будут одинаковые, а вот с сетью и с нагрузкой на сервер всё будет сильно отличаться.
2) На сервер, смотрящий в интернет заходят люди с совершенно разным каналом до сервера.
2 ситуации:
а) Клиент из Германии. С сетью у него всё в порядке... лоссов нет, комп шустрый. Но пинг клиента до сервера 180.
б) Клиент из России - Миг-телеком - пракически у всех маленький пинг, но БОЛЬШИЕ потери (лосс) - 5-10%. Лаги обеспечены.
Оба клиента имеют 100Мб выход в инет, крутые компы и гнут пальцы, что у них должен быть cmd, update = 100 или иногда особо крутые "пацаны" ставят 101.
Им пофиг, что где-то на канале от них до сервера узкое место или несколько узких мест, повышающих их пинг или создающих лоссы.
С учётом собственных алгоритмов усреднения сервера гораздо честнее оставить на сервере немца - он не будет дёргаться.
Сервер не знает - почему лаги... то-ли клиентский комп не успевает, то-ли его канал до сервера лимитирует.
Но вполне можно попробовать уменьшить пинг и лаги путём уменьшения клиентского updaterate, cmdrate. Я проверял - очень часто это помогает уменьшить его пинг и даже лоссы.
Только после этого включать проверку на превышение допустимого пинга на сервере.
3) многие игроки даже не знают как поменять updaterate, cmdrate. Они просто скачали "пацанские" конфиги.
4) Я, как администратор сервера ДОЛЖЕН заботиться не о конкретном "отце" и его обидах, а об основной массе игроков.
С учётом всего этого безобразия я не вижу ничего обидного в уменьшении клиентского updaterate, cmdrate. Вижу только пользу ОСТАЛЬНЫМ игрокам сервера с нормальным пингом и без лоссов.
Поддерживаю VamPiro32 в этом вопросе, сам постоянно наблюдаю в нетграфе такую же ситуацию на движке Source 2007 U1 в лефте параметры sv_cmdrate и sv_updaterate вообще не изменяются и при любом значении нетграф выдает 30/s, а у клиента к примеру стоит 100/s. Собственно меня даже не волнует вопрос пытается ли клиент принять или отдать по 100 пакетов и я не вижу ничего плохого что плагин приравняет клиентские рейты к серверным (хотябы в нетграфе наконец вырисовывается правильная картина, а не этот бред что он обычно показывает). Вопрос о пользе плагина конечно спорный, но потестив вечерок rate_forcer на L4D скажу лишь что хуже от него никому небыло, а по субъективному мнению даже наоборот.
Правда плагин почему то не всегда сбрасывает завышенные клиентские рейты к прописанным в конфиге, может кто разбирается и попробует поправить код скрипта?
Правда плагин почему то не всегда сбрасывает завышенные клиентские рейты к прописанным в конфиге, может кто разбирается и попробует поправить код скрипта?
В CS:S проверено, min/maxrate, min/maxcmdrate и min/maxupdaterate работают.
Т.ч. либо вы что-то не так настроили, либо что-то не так смотрите и упрямо не желаете разобраться.
Т.ч. либо вы что-то не так настроили, либо что-то не так смотрите и упрямо не желаете разобраться.
sv_minrate не работают, остальные работают, это проверено)))kadet89 писал(а):В CS:S проверено, min/maxrate, min/maxcmdrate и min/maxupdaterate работают.
Если бы работали, не нужен был бы рейт энфорсер)))
Обоих кикать нафиг!)))VamPiro32 писал(а):а) Клиент из Германии. С сетью у него всё в порядке... лоссов нет, комп шустрый. Но пинг клиента до сервера 180.
б) Клиент из России - Миг-телеком - пракически у всех маленький пинг, но БОЛЬШИЕ потери (лосс) - 5-10%. Лаги обеспечены.
Для таких проблем есть плагин hpk, его можно настроить на кик пингорасов, лосеров, чокеров и прочей нечисти.
А данный плагин, повторюсь, можно настроить так, чтобы при несоответствии он подводил клиентские рейты к минимальным серверным, а не фиксированным.
Такое впечатление, что всё-таки не читают мои сообщения. Или не понимают, что я пишу.Yogurt писал(а):sv_minrate не работают, остальные работают, это проверено)))kadet89 писал(а):В CS:S проверено, min/maxrate, min/maxcmdrate и min/maxupdaterate работают.
Если бы работали, не нужен был бы рейт энфорсер)))
Попробую проще и односложнее.
1) Как проверено? Показаниям нетграф я не верю, причины описаны выше.
2) Пример с пивом, может быть поможет...
У вас есть бочка пива с несколькими маленькими выходными трубками. Из бочки одновременно высасывают пиво несколько клиентов.
Вы, как вежливый хозяин дома должны обеспечить всех друзей равным кол-вом пива. Несколько ситуаций:
а) Подключается друг1 с трубой в 3 раза больше вашей выходной трубы. Клиент постоянно скандалит и требует обеспечить наполнение его огромной трубы.
б) Подключается друг2 с трубой в 3 раза больше вашей выходной трубы. Но его труба засорена и даже если вы сделаете свою трубу такой же, как его труба, он всё равно не получит чего хочет. Но клиент постоянно скандалит и требует обеспечить приход пива по его огромной трубе, в соответствии с её диаметром.
в) Чистая труба друга3 ровно такого внутреннего диаметра, как трубка из бочки. Клиент не ругается - его устраивает. Но он видит, что рядом беснуются 2 пьяных соседа с огромными трубами.
Вопрос! Какой вариант устроит вас, как вежливого и честного хозяина дома?
VamPiro32, сравнивать пиво с исходящим трафиком в корне некорректно. Во-первых потому, что пиво когда-то кончится, а трафик нет. А во-вторых, исходящего трафика сервер сгенерирует ровно столько, сколько нужно (согласно апдейтрэйтам/рэйтам) и не байтом больше.
55.1/s - сколько клиент реально получает пакетов с серва
65.8/s - сколько клиент реально отправляет пакетов на серв
66/s - значение cl_cmdrate
Разница между 140 и 55.1 объясняется следующими причинами:
1) На сервере updaterate урезается по sv_maxupdaterate.
2) Сервер может отправлять только по одному update пакету каждому клиенту за время обсчета одного фрэйма. А значит реальный updaterate не может быть больше серверного fps.
3) пакетики дропаются по пути от сервера к клиенту (loss)
4) choke, оно же принудительная задержка отправки пакетов, чтобы не превысить лимит полосы, заданный в rate.
140/s - значение cl_updaterate (сколько клиент хочет получать пакетов с серва)VamPiro32 писал(а):
55.1/s - сколько клиент реально получает пакетов с серва
65.8/s - сколько клиент реально отправляет пакетов на серв
66/s - значение cl_cmdrate
Разница между 140 и 55.1 объясняется следующими причинами:
1) На сервере updaterate урезается по sv_maxupdaterate.
2) Сервер может отправлять только по одному update пакету каждому клиенту за время обсчета одного фрэйма. А значит реальный updaterate не может быть больше серверного fps.
3) пакетики дропаются по пути от сервера к клиенту (loss)
4) choke, оно же принудительная задержка отправки пакетов, чтобы не превысить лимит полосы, заданный в rate.
Не уловил логики, причем тут sv_minrate?Yogurt писал(а):Если через sm_rates это не видно, то по нетграфу это очень даже видно))
По сути "правильщики" рейтов нужны только потому что не работает серверный cvar sv_minrate