Недавнее содержимое от Gaikotsu

L2MonsterInstance находится в ядре, не в датапаке

Если быть более точным, то или пустой или содержит всего один элемент (индексация же идет с 0) Возможно в коде как раз тупанули на тему "если массив не пуст, то возьмем первый элемент по индексу 1".

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

При желании можно даже стандартные как либо разнообразить У меня к примеру сделаны 8 видов PvP-эвентов: DeathMatch: тут все понятно думаю - все против всех с целью набить нужное количество очков за убийства (после смерти игроки ресаются снова с определенной задержкой); Team DeathMatch: то же...

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

А вот кстати в скриптах эссенса/классика 287 протокола можно найти шоты с эффектом i_soul_shot;130, которые и являются этими самыми блесс соулшотами, дающими бонус +130%, вместо обычных 100%. И это как раз да - камаэль, но только камаэль на классике, а не оригинальный старый. Так что у ТС просто...

Я вот тоже что-то не припоминаю блесс соулшотов вобще никак... даже если пошариться по птс скриптам разных хроник, то там для соулшотов всегда используется только i_soul_shot;100, что по сути означает +100% к урону от соулшотов, нет каких либо более высоких значений. Конечно конкретно скриптов...

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

Ну так у тебя тут и не вызывается интеншн атаки - потому и не атакует. Отправка ExAutoPlayDoMacro вобще по сути опциональна - даже без ее отправки должно работать. Если не ошибаюсь, то ExAutoPlayDoMacro просто говорит что надо запустить с начала макрос в указанном слоте. Чтобы по сути при выборе...

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

Сервер. Вот в коде что ты выше выкладывал добавь вывод значений нужных переменных и все.

как вариант - не инициализирует заново личный счетчик для modify наград после ее выдачи. выводи в консоль значение playCount к примеру тупо через System.out.println и смотри что в итоге будет - сбросится ли он вобще после выдачи modify награды.

ну вот попробуй вывести при розыгрыше инфу, какого типа награды тебе выдает и уже от этого дальше разбирайся, если modify наград нет а это вобще никак не должно влиять на выбор награды

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

уники должны по сути выдаваться когда на текущее значение счетчика проведенных наград есть уникальная награда в коде у тебя это вычисляется в этом вот фрагменте for (int i = 0; i < _reading; i++) { final int serverGameNumber =...