Gaikotsu

а нафига objectId игрока умножать на 1000, перед передачей его в getHeroDate?

а, ты про это. ну дык броадкастить MagicSkillUse надо на нужных целях так же как на самом кастере поля.

что конкретно то не показывает? само поле? ну дак это не анимация скилла, а внешний вид самого нпс, который стоит в центре поля и кастует скиллы.

не так уж и много. даже в официальных аугментациях на каждый лс выделено всего по 2-3 сотни ид где-то просто за счет их случайных комбинаций и получается в итоге такое многообразие конечных аугментаций. короче на словах объяснять долго - проще самому посмотреть variationdata.txt и понять достаточно простой принцип генерации ауг на оффе. и без всяких извращенных методов генерации ауг, которые наличествуют в преобладающем большинстве всех сборок.

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

если что можно заюзать дополнительно к аугам enchant options (доп бонусы от заточки вещи, ну вот как к примеру в Рубашке Ольфа) - это даст возможность навешивать еще до 3 дополнительных бонусов на вещь без особо серьезных доработок ядра и не потребует по сути никаких доработок клиента. не помню правда с каких хроник данное дело для вещей появилось.

еще в getEffects надеюсь не забыл подобные проверки добавить? чтобы и от дебаффов защититься.

"немножко"... ты не забывай еще о том что тебе пакетку придется перерабатывать местами.

Некоторые "кривожопые" как ты выразился, вообще предпочтут не формировать такие байпасы, в которых есть хоть какая-то потенциальная возможность сделать подмены данных. По мне дак по возможности надо слать в подобных случаях самый минимум данных, ну вот к примеру в выше приведенном байпасе что-то типа <a action="bypass _cbbforge:id_или_uid_предмета_для обработки:id_данных_для_работы">и все. к чему слать в подробностях в байпасе все что нужно для обработки, если можно заранее сформировать нужные варианты данных и обращаться к ним по идентификаторам.

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

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

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

не надо так издеваться над щитами.если надо где-то точно определять что это щит, а не оружие, что нужно по сути очень редко, то можно же это определять именно щит - по exType или по слоту и типу. public boolean isShield() { return _exItemType == ExItemType.SHIELD; } а по соскам - что мешает по быстрому расставить потребление сс/спс, выковыряв эту инфу из клиентских данных? там дел то всего ничего.

ну как минимум данные по пакетке можно у l2j посмотреть, а дальше уже все зависит от прямоты рук и умения искать инфу. я вот меньше чем за неделю переписал вроде все или почти все по пакетке под этрейю в нашей сборке линдвиора (базирующейся на овере). правда пока на этом пришлось остановиться и отложить работы над этим всем, т.к. потребовалось пока заняться более насущными делами и посему ковыряние с этрейей отложено на неопределенный срок.

на зг acmi давно уже выкладывал тулзу, с помошью которой с можно вытянуть NA-клиенты любых версий начиная 526 протокола линдвиора и далее ну а если нужен ру клиент, то только последний, чрез стандартный апдейтер руофовский. и там если что уже 610 протокол.

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

сразу после телепорта вешаем скилл с эффектом, отменяющимся при любом действии и все. аналоги таких скиллов по сути в овере есть.

за 100$ нагенерю тебе хоть 10кк логинов

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

а поддержка триггеров в скиллах есть в сборке?

угу, продаст к примеру тот же ГВ, исходники которого уже есть в шаре

поменяй return getSkill().isToggle(); просто на return true; у тебя getSkill().isToggle() скорее всего false возвращает, а это означает что больше вызывать onActionTime не надо.

запускать сервер в режиме отладки в самом IDE и не париться - исправляемый код будет сразу же применяться к запущенному серверу. Эклипс такое может без проблем, Идея - не знаю, т.к. не пользовался, но наверняка такой функционал у нее тоже есть.

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

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