Скорость разворотов и фпс патч из Инжекта Опции

[Wap]

А сложно вообще в UO клиенте изменить скорость разворотов персонажа? Отдельно от всего. А то обидно как-то. В популярном сейчас фпс патче есть очень простой по своей сути критичный баг - в нем скорость разворотов удвоена. Исправить это - и он никому мешать не будет.

P.s. Если кто тут начнет впаривать про какие-то высокие материи, размер буфера и прочее, он не шарит в теме и пишет бесполезный оффтоп. Потому что не то чтобы это было неправдой... возможно в клиенте с фпсом что-то отличается... возможно. Но прыгает на поворотах он не из-за этого, а того, что я написал, лично тестил и фиксил это на локале с серверной стороны. И пока этот баг там есть, обсуждать все остальное нет никакого смысла, этот баг критичнее на порядок.

[EL-GReeN]

Сколько играл не замечал никакой скорости разворота(наверно потому что на абисе этот фпс мод включен был всегда), единственное что это есть задержка на шаги, если не ошибаюсь примерно:
шаг 800мс,
шаг бега/шаг на лошади 400мс,
шаг бега на лошади 200мс.
Прыжки на разворотах это как?.

Еще может вам пригодится для поиска заветного адреса, таким скриптом я включал фпс мод на клиенте 1.26.4:

Код

  set linedelay 0
  set #h1 0 //76
  set #h2 67634184 //33817092
  set #adr1 11605616
writemem #h1 0x047ABDF b
  for #i 0 1998 4
   writemem #h2 #adr1 d
   set #adr1 #adr1 + 4
  end_for
  end_script

[Aimed]

Сколько играл не замечал никакой скорости разворота(наверно потому что на абисе этот фпс мод включен был всегда), единственное что это есть задержка на шаги, если не ошибаюсь примерно:
шаг 800мс,
шаг бега/шаг на лошади 400мс,
шаг бега на лошади 200мс.
Прыжки на разворотах это как?.

400/200/100

С разницой в интервалах до 70 мс, в зависимости от пинга и GetTickCount(), которая выравнивается при следующем шаге такого-же типа и т.д.
ФПС патч не действует отдельно на повороты и другие типы перемещения, он общий таймер изменяет.
Так что это надо свой ФПС патч с 0 писать, что-бы это пофиксить так как хочешь ты, Вап.

П.С. Ты ничего не фиксил у себя на локалке своими блоками ускоренных пакетов при разворотах, это не работает. Его нельзя на стороне сервера пофиксить, даже если как-то замедлять ответы, так-как клиент начнёт реагировать на замедленные ответы и ускорять ещё больше, подрезая задержку на следующий шаг. Я уже это 3 или 4 раз пишу. Так что на сервере это не фиксится. А если блокировать пакеты, то это не фикс будет, а баг. Потому что те у кого нестабильный пинг, либо высокий, потому что играют издалека, начнут терять пакеты, что и происходит и тебе это на форуме игроки писали уже неоднократно.

[StaticZ]

П.С. Ты ничего не фиксил у себя на локалке своими блоками ускоренных пакетов при разворотах, это не работает. Его нельзя на стороне сервера пофиксить, даже если как-то замедлять ответы, так-как клиент начнёт реагировать на замедленные ответы и ускорять ещё больше, подрезая задержку на следующий шаг. Я уже это 3 или 4 раз пишу. Так что на сервере это не фиксится. А если блокировать пакеты, то это не фикс будет, а баг. Потому что те у кого нестабильный пинг, либо высокий, потому что играют издалека, начнут терять пакеты, что и происходит и тебе это на форуме игроки писали уже неоднократно.

Клиент работает асинхроно он не ждет ответ (по идее, хотя честно сказать не проверял - имхо нафиг надо такой изврат), но бороться с рассинхроном на стороне сервере можно более чем успешно -
ловим рассинхрон, если он превышает определенную величину (время шага) - шлем reject на движение и фризим игроков на величину рассинхрона. Правда конечно у тех кто попадет под раздачу это будет не очень - периодически чал будет стопорится и изза чего будет дерганное перемешение, так что это скорее не способ лечения косяков клиента на стороне сервера, а средство борьбы с теми кто експлойтит этот баг.


Но это, как говорил вят - не для runuo users... =))





А насчет скорости разворота это кстати в списке задач UCS - меня бесит что чар моментально разворачивается, особенно на коне.

[Aimed]

Клиент работает асинхроно он не ждет ответ (по идее, хотя честно сказать не проверял - имхо нафиг надо такой изврат), но бороться с рассинхроном на стороне сервере можно более чем успешно -
ловим рассинхрон, если он превышает определенную величину (время шага) - шлем reject на движение и фризим игроков на величину рассинхрона. Правда конечно у тех кто попадет под раздачу это будет не очень - периодически чал будет стопорится и изза чего будет дерганное перемешение, так что это скорее не способ лечения косяков клиента на стороне сервера, а средство борьбы с теми кто експлойтит этот баг.
Но это, как говорил вят - не для runuo users... =))
А насчет скорости разворота это кстати в списке задач UCS - меня бесит что чар моментально разворачивается, особенно на коне.

Ясное дело что асинхронно работает, но ответа он все-равно ждет, что-бы повысишить счетчик последовательности шагов. Потому что если разница будет больше 3, он попросту зависнет/встанет.

Слать reject - это и есть провал. Это сделал Вап и теперь игроки с высоким пингом теряют шаги, их сервер стопает просто так. Кроме того, те у кого сильно нагружена система во время игры либо если, допустим, GetTickCount() 2 раза по максималке устроит разброс - клиент даже на локалке может подрезать интервал задержки на шаг и выслать раньше - тогда сервер тебя стопанет rejectом. Что будет, если такое случится когда игрок падает из-за этого на свой топ шмот, думаю и так понятно.

[StaticZ]

Слать reject - это и есть провал. Это сделал Вап и теперь игроки с высоким пингом теряют шаги, их сервер стопает просто так. Кроме того, те у кого сильно нагружена система во время игры либо если, допустим, GetTickCount() 2 раза по максималке устроит разброс - клиент даже на локалке может подрезать интервал задержки на шаг и выслать раньше - тогда сервер тебя стопанет rejectом. Что будет, если такое случится когда игрок падает из-за этого на свой топ шмот, думаю и так понятно.

Ну если слать тупо так как вы сказали, то да это это те еще грабли, а если слать по уму то все работает хорошо и GetTickCount() никакой даже не нужен, да и точность у него низковатая для этого %) Просто палить надо время отправки пакета и время в который должна будет окончиться очередь движения, а не время получения (двух пакетов?), если их разброс выше 800\400\200 то это говорит о том что клиент шлет пакеты с опережением или наоборот с отставанием т.е. таймер клиента сбит, что в частности делает фпс патч )