pvpgate

угу, уже разобрался, спасибо. Я так понимаю с помощью l2smr я могу только менять координаты объектов на картах и все?

Спасибо, а конкретно файлы где арены олимпа не подскажешь?

Всем привет. Встречал на некоторых серверах High Five и в некоторых патчах убранный на арене с 4 столбами мусор (валяющийся щит, меч, иногда даже срезанные по высоте столбы и т.д.) Подскажите пожалуйста, какой файл за это отвечает, и может у кого есть готовый, без мусора?

Алгоритм поиска пути как я и описывал - волновой. Но вот "вес" или расстояние для каждой следующей точки считается не просто как расстояние до предыдущей +1, а немного сложнее. В методе PathFind.traverseCost() расстояние увеличивается не на 1 а на 3 если точка вокруг которой ищется точка непроходима в одну из сторон n.nswe != NSWE_ALL а также увеличивается на 2 если точка вокруг которой ищется соседняя точка соседствует с непроходимой в одну из сторон точкой getHeightAndNSWE(n.x + 1, n.y, n.z); if(hNSWE[1] != NSWE_ALL || Math.abs(n.z - hNSWE[0]) > 16){ return 2f; } getHeightAndNSWE(n.x - 1, n.y, n.z); if(hNSWE[1] != NSWE_ALL || Math.abs(n.z - hNSWE[0]) > 16){ return 2f; } getHeightAndNSWE(n.x, n.y + 1, n.z); if(hNSWE[1] != NSWE_ALL || Math.abs(n.z - hNSWE[0]) > 16){ return 2f; } getHeightAndNSWE(n.x, n.y - 1, n.z); if(hNSWE[1] != NSWE_ALL || Math.abs(n.z - hNSWE[0]) > 16){ return 2f; } ну и если расстояние по z > 16 тоже, но это наверно разумно оставить. Однако, выпилив все эти условия понадобится переписывать pathClean() и намного тщательнее относиться к качеству геодаты. Может придется кое что изменить в диагональном поиске пути еще, посмотрим...

Разобрался, не актуально. Правда теперь проблема с pathClean, но это уже совсем другая история..

не совсем. Он использует волновой алгоритм, начиная от начальной точки он для всех соседних точек проставляет путь = пути от предыдущей +1 (в случае с диагональю - ~1.4, но для тестов я отключил диагональный поиск). Если соседняя точка уже занята (ей проставлено значение пути от другой точки) он сравнивает это значение с тем, которое может записать. Если он может записать меньшее значение - перезаписывает. Кроме того для каждой след. точки предыдущая (из которой в нее проставлено значение) записывается как родительская (parent). Таким образом волна распространяется от начальной точки во все стороны пока не окажется что очередная точка это точка финиша. После этого, начиная от финишной точки, выбирается ее "родительская" точка, для нее - ее родительская, и так пока не упремся в стартовую точку. На этом путь считается проложенным. Сейчас начал логировать путь в методе GeoMove.findMovePath() и отрисовывать его, впринципе все то же самое выходит, только путь строится до середины геоноды, поэтому возникает такой "хвост" в конце (справа на скрине) К сожалению мне туговато дается java без особого опыта в программировании, так что пока не слишком получается логировать на всех этапах, т.к. лог забивается поиском пути для всех ресающихся мобов, а в методе findMovePath() в качестве агрумента передается игрок и можно отрисовывать только для isPlayable()...

Всем доброго времени суток, уже создавал тему про гео на лостворлде, но теперь разобрался в теме поподробнее и мне все еще очень нужна помощь. Ниже изложу всю суть. Не прошу ничего за меня править, но очень прошу ткнуть меня носом в конкретное место из-за которого так происходит, ибо я уже недели 2 сижу в попытках разобраться. Теперь подробности У меня в сборке персонаж довольно странно взамодействует с гоедатой, когда речь заходит о поиске пути: Вот так оббегает у меня углы (если расстояние от угла до стартовой и финишной точки более 3 ячеек геодаты (ДИАГОНАЛЬНЫЙ ПОИСК В ПРИМЕРАХ ОТКЛЮЧЕН ДЛЯ УПРОЩЕНИЯ. С НИМ ПРОИСХОДИТ ТО ЖЕ САМОЕ, ТОЛЬКО УГЛЫ В НАЧАЛЕ И КОНЦЕ СРЕЗАЮТСЯ ПО ДИАГОНАЛЕ): Персонаж делает крюк, пытаясь находится на растоянии 2(в третем) ячейки геодаты от стен. На картинке схематично показан алгоритм работы поиска пути из моего геодвижка (волновй алгоритм, по логике путь должен лежать вдоль стен по возрастанию цифр) Если расстояние от угла до старта и финиша 3 и менее ячеек путь находится корректно: Если расстояние от угла до начала более 3 ячеек, а до конца 3 ячейки, то до угла персонаж будет держаться на расстоянии 2 ячеек, а после на расстоянии одной ячейки: Если расстояние от угла до начала более 3 ячеек а до конца 2, то первую часть пути персонаж будет держаться на расстоянии 2 ячеек, а потом вплотную к стене: Та же история происходит не только при оббегании одного угла, но и при любом взаимодействии с геодатой, требующим поиск пути. Вплотную к стене подбежать можно, и бежать вдоль нее тоже (если не задействован поиск пути) В архиве прилагаю свой геодвижок + creature (на всякий случай): http://rgho.st/67LhC5X9V Ниже описание методов которые я разобрал: geoMove.findMovePath() //собственно вызывается при поиске пути PathFind.findPath() //вызывается в методе выше, отдает лист точек path PathFind.handleNode() //в зависимости от типа ячейки (и того включен ли диагональный поиск) выбирает ближайшие ячейки вокруг PathFind.handleNeighbour() //вызывается методом handleNode(), проставляет для ячеек значение пути и т.д. PathFind.tracePath() //после того как handleNeighbor достиг точки назначения начинает с конца в начало восстанавливать путь, выбирая для каждой ячейки "родительскую" GeoNegine.MoveList() // проверяет лист path из FindPath() на возможность пройти по нему, возвращает лист точек (если все впорядке - идентичный path, судя по всему) Буду безмерно благодарен за любые подсказки. Если кто ткнет носом в конкретное место с меня отдельное спасибо, ну и на пиво рублей 500 (вряд ли конечно будет серьезным мотиватором, но чем могу...)

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

Спасибо за вариант, но я не смогу со своим опытом переписать его под свою сборку, совершенно другая архитектура.(

Проблема в том, что персонаж сперва отбегает от препятствия, а потом обходит угол и опять прижимается к стене. Если отключить диагональный поиск пути в конфигах он сперва сделает шаг от стены, потом побежит, добежит до нужной точки и сделает шаг к стене, хотя никаких препятствий на пути нет, и вручную можно проделать тот же маршрут не делая шаг от стены. Есть хоть какие нибудь предположения почему так происходит и как с этим бороться?

судя по тому что за исключением мест где точка на прямой видимости он бегает либо по перпендикулярным прямым, либо по строгой диагонали, то это какой-то алгоритм волновой трассировки, только очень уж в лобовую написанный...

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

Не совсем понял, что ты имеешь ввиду? Сейчас этот угол, который я записывал, выглядит вот так: vfl Заблокировать проход - это имеется ввиду черная ячейка?

Что это и где?

Что это такое и где, подскажи плз.

Всем привет, опять я со своими вопросами начинающего. Сборка LostWrold, геодата нормальная (много разных пробовал, да и на видео видно что все ок) Собственно ниже видео оббегания углов. Вопрос: куда копать? Я так понимю это геодвижок или чето такое. Насколько реально это фиксить руками? Бывает ли адекватный геодвижок для лостворлда в шаре или в продаже?

Всем спасибо, разобрался. Если кто-то будет искать, данная проверка в самом конце находится в Creature.onMagicUseTimer() Там набирается список целей для атаки, а в свою очередь этот метод записывается в shedule в методе doCast() Достаточно было, почти как писали выше, записать в doCast() новый метод, записывающий таргеты в момент _scheduledCastInterval*(1-skillInterruptTime/skillTime-0.1) и использовать в методе onMagicUseTimer() таргеты записанные ранее.

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

я уже пользуюсь intellij idea Я же не просто так спрашиваю. Я вижу что, к примеру, getTargets() вызывается в 10 местах, и я не совсем понимаю что есть что. Пытаюсь переходить на каждый метод и смотреть откуда в свою очередь он вызывается, и при каких условиях (условия в свою очередь тоже могут быть методами, и могут еще и чето там наследовать и т.д.) Не забывай что про что-то около ООП я пару недель назад слышал разве что мельком, да и java для меня не знакомый язык. Я рассчитывал что кто-нибудь у кого есть опыт с этой сборкой и программированием смог бы указать на нужное место. И еще, после тестов понял что для рассчета срабатывания скилла список целей для notTargetAOE набираются в конце каста. А список целей для анимации набирается в начале каста. В итоге если выйти из зоны каста урона не будет, но анимация будет. А если наоборот, начать каст когда цель вне зоны, и потом она вбегает в зону - будет урон от скилла, но не будет анимации попадания, что полностью вынесло мне мозг.

Я понимаю что нужно сделать. Вопрос в том где. Во-первых, в каком методе для аое скиллов собирается список целей в начале? (вызывается getTargets как я понимаю, но где именно это происходит в начале каста?) Во-вторых, в каком методе идет проверка в конце и удаление ненужных целей? Разве для нонтаргет аое вообще есть набор целей в начале каста? Разве они не набираются тупо в конце?

Понимаю что вопрос тупой, но сам разобраться не могу, слишком запутанно все. Судя по всему никаких прерываний для нон таргет аое скиллов быть не может, при касте таких скиллов в определенный момент мы обращаемся, я так понял, к Skill.getTargets(), который в свою очередь обращается к Skill.AddTargetToList(), который в свою очередь обращается к Skill.checkTarget(), и если тот не отдает null, то наполняет лист таргетов персонажами вокруг. Проверка на видимость идет как раз в Skill.checkTarget() который не позволит записать в лист таргетов невидимый таргет. И вся эта конструкция вызывается (по крайней мере для нонтаргет АОЕ) в самом конце каста. Соответственно список таргетов тоже наполняется в самом конце, и проверка checkTarget() происходит тогда же. Это подтверждается тем, что когда я удалил эту проверку для нонтаргет АОЕ, они начали бить цели, не видимые даже в начале каста. Это то что я понял, если не прав поправьте плз. Теперь что я не понял: В каком именно месте для нон таргет аое вызывается вся эта конструкция? (понятно что в конце каста, но в каком методе какого класса?). Пробовал копать Creature, запутался( И второй вопрос, почему для не нонтаргет АОЕ скиллов цель выбирается в начале каста? (или там проверка видимости каким-то другим образом реализована?)

пока просто добавил first==true , видимо с таким параметром для аое скиллов этот метод не вызывается, потому что все равно нон таргет аое бьют через препятствия, т.е. проверка идет в конце, а т.к. я поставил в проверке first==true то она не срабатывает. Не вкурсе, где этот метод вызывается для нон таргет аое в конце? И еще вопрос, как мне прервать дмг в нон таргет аое скилле по целе, на которую проверка на видимость не сработала, но не прерывать для остальных целей?

у меня в методе checkTarget есть такая проверка: if(isNotTargetAoE() && getCastRange() < Integer.MAX_VALUE && !GeoEngine.canSeeTarget(activeChar, target, activeChar.isFlying())) { return SystemMsg.CANNOT_SEE_TARGET; } Из за нее для нонтаргет аое скиллов нет докаста, хотя он у меня реализован в doCast в Creature и для не нонтаргет аое скиллов работает. А если эту проверку убрать, то нонтаргет аое скиллы будут бить через препятствия. Я не могу понять где именно вызывается этот метод для нон таргет аое, чтобы убрать эту проверку в конце, а добавить в нужный момент

Спасибо, а я все думал что он означает) на самом деле offlike докаст рассчитывается в зависимости от skillHitTime и skillHitCancelTime, у меня игрок недавно сделал ряд подробных тестов по докасту и прерыванию анимации на птс. Прерывание идет через 10% от времени каста после проверки на видимость для докаста

переформулирую вопрос: в каком месте в лосте идет проверка на видимость цели в конце каста, которая не должна быть в конце на самом деле, иначе докаста не будет?