шарные ребелионы с кучей сличенных сервисовхезе, судя по видосикам с лайва и вообще отзывам, не такое и говно, хотя вообще хз, не смотрел что они из себя представляют
хезе, судя по видосикам с лайва и вообще отзывам, не такое и говно, хотя вообще хз, не смотрел что они из себя представляют
Нет там никакой формулыЯ выбирал сурс из соображений количества костылей и без лишних сервисов, там основа состоит в этом. Мне все это только мешало.
И на данный момент реализовано множество моментов в локациях которые почему-то все упустили даже на лосте, сама механика наложения эффектов, квестов и прочей мелочи оффлайк, так же перепилен эвент двиг, переписаны все ивенты и их механика, переписана комьюнити под необходимые нужны без всякого шлака и соответственно поправлены основные костыли (заглушки).
теперь добавился немного перепиленый мувинг (сам таск передвижения, пакет ValidatePosition и MoveToLocation, т.е использование пакетов как они изначально должны использоваться) под птс но проблему данной темы это не решает. И выявить на уровне пакетов не выходит тк там все четко вплане координат. Возможно чардж скилам необходима определенная формула просчета конечной локации и другую клиент не может воспринимать, тут все таки стоит глянуть на декомпил ГФ но терпеть не могу ассемблер
это у гринда что ли?Нет там никакой формулыУ меня даже до перепила мувинга не было багов с рашами, только с самим движением.
Ну изначально на сурсах основанных на фениксах, т.е большинстве сурсов не на лыже он присутствует и простым удалением validateLocation или добавлением исключения в validatePosition это не исправляется, уверен что его нет? Тк если ты не трогал расчет координат для раша то этого бага и не будет, но сам раш будет работать корявоНет там никакой формулыУ меня даже до перепила мувинга не было багов с рашами, только с самим движением.
Ну, оверы, по факту. От гринда там были только захардкоженные свистоперделки.это у гринда что ли?
ну так то да, но в лосте этот баг естьНу, оверы, по факту. От гринда там были только захардкоженные свистоперделки.
Мувинг что на оверах, что на лостах одинаковый.
Метод, который расчитывает "точку назначения" для полетных скиллов я не менял. Это я про getFlyLocationНу изначально на сурсах основанных на фениксах, т.е большинстве сурсов не на лыже он присутствует и простым удалением validateLocation или добавлением исключения в validatePosition это не исправляется, уверен что его нет? Тк если ты не трогал расчет координат для раша то этого бага и не будет, но сам раш будет работать коряво
Значит раш у тебя работает коряво и залитает либо в лицо либо за спину в зависимости от того что у тебя прописано в 793 скиле (isFlyToBack).Метод, который расчитывает "точку назначения" для полетных скиллов я не менял. Это я про getFlyLocation
¯\_(ツ)_/¯Значит раш у тебя работает коряво и залитает либо в лицо либо за спину в зависимости от того что у тебя прописано в 793 скиле (isFlyToBack).
Попробуй переписать этот метод для оффлайк-его работы (подлет к ближайшей точке) и столкнешься с этой проблемой.
На данный момент я не видел даже приватных сборок где пофикшен этот момент (никто не трогал этот метод)
Интересно, а что в таком случае передается в методе doCast при switch-е флайтайпов в FlyToLocation для CHARGE?
Ну так валидация координат вся переписана по pts-likesetLastValidation и getValidationCounter что-то новенькое)
Ну это дело я переписал относительно. Т.е эти методы записывают координаты которые передает клиент в массив? или это счетчик?.Ну так валидация координат вся переписана по pts-like
Первый обнуляет время последнего прихода пакета ValidatePosition, последний обнуляет каунтер моментов рассинхрона, чтобы не слался пакет ValidateLocationНу это дело я переписал относительно. Т.е эти методы записывают координаты которые передает клиент в массив? или это счетчик?.
Сейчас у меня сохраняется только предпоследняя и последняя координаты для вычисления разницы и сравниваются с с позицией относительно сервера.
Первый обнуляет время последнего прихода пакета ValidatePosition, последний обнуляет каунтер моментов рассинхрона, чтобы не слался пакет ValidateLocation
loc = new Location(target.getX() - (int) (Math.sin(radian) * 40), target.getY() + (int) (Math.cos(radian) * 40), target.getZ());
loc = applyOffset(target.getLoc(), 45)
Ничего не изменилосьМм, собственно время прихода пакета используется для отсылки того же 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)
Кроме того что рашит не в лицо ничего и не должно было измениться))Ничего не изменилось
¯\_(ツ)_/¯
Ты дебажить смену координат пробовал? Судя по всему ты явно что-то где-то пропустил.Кроме того что рашит не в лицо ничего и не должно было измениться))
Переписал с нуля ValidatePosition основываясь на лыже тк ничего больше не приходит из пакетов - безрезультативно.
В мувинг левых координат не прописывается, ValidateLocation не отправляется, ValidatePosition не отрабатывает, даж не представляю в какую сторону еще можно капнуть этот момент
Также для оффлайк работы по наблюдению с птски - в magicSkillUse и FlyToLocation кооридината Z имеет сдвиг в большую сторону на ColRadius/2.
Не знаю причем тут координата Z и деленный на 2 радиус но факт остается фактом (Соотв. кто будет заниматься этим моментом - лучше спарсить colHeight и colRadius с птс скриптов
We use cookies and similar technologies for the following purposes:
Do you accept cookies and these technologies?
We use cookies and similar technologies for the following purposes:
Do you accept cookies and these technologies?