Валидация playable-персонажей

[TheMads]

Добрый вечер, решил переписать flytype-скилы (Rush Impact, Shadow Step, Warp и тд) и на последнем этапе столкнулся с проблемой некорректной обработки движения после использования Charge-скилов.

Баг актуален для всех сборок на базе l2p (Так же актуально для l2gw) даже если не трогать изначальный код.

В чем суть:
Если после окончания каста (после срабатывания clearCastVars() и finishFly()) начать отбегать то подключается nextAction.MOVE (обрабатывается в PlayableAI). По окончанию бега если персонаж на стороне клиента не добегает до точки то его возвращает в последние координаты после каста (в координаты, что находится в переменной _flyLoc и возвращается функцией getFlyLoc()).

Соответственно бежать можно бесконечно и по итогу персонаж все равно окажется на "левых" координатах. При этом после окончания бега сработает пакет validatePosition и переместит/портанет персонажа в зависимости от diff между клиентом и сервером.

Данного бага не было на лайве лостворлда (в шарных сурсах он остался)

Подробней как это проявляется:

Собственно вопрос - кто-то фиксил этот момент? Такое чувство что он зарыт где-то в мув-листе

 

[ツsmile10ツ]

хезе, судя по видосикам с лайва и вообще отзывам, не такое и говно, хотя вообще хз, не смотрел что они из себя представляют

шарные ребелионы с кучей сличенных сервисов

 

[TheMads]

хезе, судя по видосикам с лайва и вообще отзывам, не такое и говно, хотя вообще хз, не смотрел что они из себя представляют

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

теперь добавился немного перепиленый мувинг (сам таск передвижения, пакет ValidatePosition и MoveToLocation, т.е использование пакетов как они изначально должны использоваться) под птс но проблему данной темы это не решает. И выявить на уровне пакетов не выходит тк там все четко вплане координат. Возможно чардж скилам необходима определенная формула просчета конечной локации и другую клиент не может воспринимать, тут все таки стоит глянуть на декомпил ГФ но терпеть не могу ассемблер

 

[Elastic Heart]

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

теперь добавился немного перепиленый мувинг (сам таск передвижения, пакет ValidatePosition и MoveToLocation, т.е использование пакетов как они изначально должны использоваться) под птс но проблему данной темы это не решает. И выявить на уровне пакетов не выходит тк там все четко вплане координат. Возможно чардж скилам необходима определенная формула просчета конечной локации и другую клиент не может воспринимать, тут все таки стоит глянуть на декомпил ГФ но терпеть не могу ассемблер

Нет там никакой формулы У меня даже до перепила мувинга не было багов с рашами, только с самим движением.

 

[Influence]

Нет там никакой формулы У меня даже до перепила мувинга не было багов с рашами, только с самим движением.

это у гринда что ли?

 

[TheMads]

Нет там никакой формулы У меня даже до перепила мувинга не было багов с рашами, только с самим движением.

Ну изначально на сурсах основанных на фениксах, т.е большинстве сурсов не на лыже он присутствует и простым удалением validateLocation или добавлением исключения в validatePosition это не исправляется, уверен что его нет? Тк если ты не трогал расчет координат для раша то этого бага и не будет, но сам раш будет работать коряво

 

[Elastic Heart]

это у гринда что ли?

Ну, оверы, по факту. От гринда там были только захардкоженные свистоперделки.
Мувинг что на оверах, что на лостах одинаковый.

 

[Influence]

Ну, оверы, по факту. От гринда там были только захардкоженные свистоперделки.
Мувинг что на оверах, что на лостах одинаковый.

ну так то да, но в лосте этот баг есть

 

[Elastic Heart]

Ну изначально на сурсах основанных на фениксах, т.е большинстве сурсов не на лыже он присутствует и простым удалением validateLocation или добавлением исключения в validatePosition это не исправляется, уверен что его нет? Тк если ты не трогал расчет координат для раша то этого бага и не будет, но сам раш будет работать коряво

Метод, который расчитывает "точку назначения" для полетных скиллов я не менял. Это я про getFlyLocation

 

[TheMads]

Метод, который расчитывает "точку назначения" для полетных скиллов я не менял. Это я про getFlyLocation

Значит раш у тебя работает коряво и залитает либо в лицо либо за спину в зависимости от того что у тебя прописано в 793 скиле (isFlyToBack).
Попробуй переписать этот метод для оффлайк-его работы (подлет к ближайшей точке) и столкнешься с этой проблемой.
На данный момент я не видел даже приватных сборок где пофикшен этот момент (никто не трогал этот метод)

 

[Elastic Heart]

Значит раш у тебя работает коряво и залитает либо в лицо либо за спину в зависимости от того что у тебя прописано в 793 скиле (isFlyToBack).
Попробуй переписать этот метод для оффлайк-его работы (подлет к ближайшей точке) и столкнешься с этой проблемой.
На данный момент я не видел даже приватных сборок где пофикшен этот момент (никто не трогал этот метод)

Спойлер

¯\_(ツ)_/¯

 

[TheMads]

Спойлер

Посмотреть вложение 22245

¯\_(ツ)_/¯

Интересно, а что в таком случае передается в методе doCast при switch-е флайтайпов в FlyToLocation для CHARGE?

Спойлер

Я про эту часть если что)

 

[Elastic Heart]

Интересно, а что в таком случае передается в методе doCast при switch-е флайтайпов в FlyToLocation для CHARGE?

Спойлер

 

[TheMads]

Спойлер

Посмотреть вложение 22246

setLastValidation и getValidationCounter что-то новенькое)
Это я так понимаю часть переписанного мувинга?

 

[Elastic Heart]

setLastValidation и getValidationCounter что-то новенькое)

Ну так валидация координат вся переписана по pts-like

 

[TheMads]

Ну так валидация координат вся переписана по pts-like

Ну это дело я переписал относительно. Т.е эти методы записывают координаты которые передает клиент в массив? или это счетчик?.

Сейчас у меня сохраняется только предпоследняя и последняя координаты для вычисления разницы и сравниваются с с позицией относительно сервера.

 

[Elastic Heart]

Ну это дело я переписал относительно. Т.е эти методы записывают координаты которые передает клиент в массив? или это счетчик?.

Сейчас у меня сохраняется только предпоследняя и последняя координаты для вычисления разницы и сравниваются с с позицией относительно сервера.

Первый обнуляет время последнего прихода пакета ValidatePosition, последний обнуляет каунтер моментов рассинхрона, чтобы не слался пакет ValidateLocation

 

[TheMads]

Первый обнуляет время последнего прихода пакета ValidatePosition, последний обнуляет каунтер моментов рассинхрона, чтобы не слался пакет ValidateLocation

Мм, собственно время прихода пакета используется для отсылки того же ValidateLocation в последствии?

На данный момент у меня записывается время прихода и в самом пакете ValidatePosition идет проверка последнего прихода односительно мув-тика что бы второй сразу же приходящий пакет не обрабатывал ситуацию

По твоему методу getFlyLocation - на данный момент у тебя просчитывается как раз лицо, попробуй заменить всю эту хрень

loc = new Location(target.getX() - (int) (Math.sin(radian) * 40), target.getY() + (int) (Math.cos(radian) * 40), target.getZ());

на обычный

loc = applyOffset(target.getLoc(), 45)

 

[Elastic Heart]

Мм, собственно время прихода пакета используется для отсылки того же ValidateLocation в последствии?

На данный момент у меня записывается время прихода и в самом пакете ValidatePosition идет проверка последнего прихода односительно мув-тика что бы второй сразу же приходящий пакет не обрабатывал ситуацию

По твоему методу getFlyLocation - на данный момент у тебя просчитывается как раз лицо, попробуй заменить всю эту хрень

loc = new Location(target.getX() - (int) (Math.sin(radian) * 40), target.getY() + (int) (Math.cos(radian) * 40), target.getZ());

на обычный

loc = applyOffset(target.getLoc(), 45)

Ничего не изменилось
¯\_(ツ)_/¯

 

[TheMads]

Ничего не изменилось
¯\_(ツ)_/¯

Кроме того что рашит не в лицо ничего и не должно было измениться))
Переписал с нуля ValidatePosition основываясь на лыже тк ничего больше не приходит из пакетов - безрезультативно.
В мувинг левых координат не прописывается, ValidateLocation не отправляется, ValidatePosition не отрабатывает, даж не представляю в какую сторону еще можно капнуть этот момент

Также для оффлайк работы по наблюдению с птски - в magicSkillUse и FlyToLocation кооридината Z имеет сдвиг в большую сторону на ColRadius/2.

Не знаю причем тут координата Z и деленный на 2 радиус но факт остается фактом (Соотв. кто будет заниматься этим моментом - лучше спарсить colHeight и colRadius с птс скриптов

 

[Elastic Heart]

Кроме того что рашит не в лицо ничего и не должно было измениться))
Переписал с нуля ValidatePosition основываясь на лыже тк ничего больше не приходит из пакетов - безрезультативно.
В мувинг левых координат не прописывается, ValidateLocation не отправляется, ValidatePosition не отрабатывает, даж не представляю в какую сторону еще можно капнуть этот момент

Также для оффлайк работы по наблюдению с птски - в magicSkillUse и FlyToLocation кооридината Z имеет сдвиг в большую сторону на ColRadius/2.

Не знаю причем тут координата Z и деленный на 2 радиус но факт остается фактом (Соотв. кто будет заниматься этим моментом - лучше спарсить colHeight и colRadius с птс скриптов

Ты дебажить смену координат пробовал? Судя по всему ты явно что-то где-то пропустил.