Gaikotsu

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

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

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

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

[sarcazm] Народ, берите все пример с автора темы - именно так и надо выкладывать свои работы: с невнятным описанием и обязательно без чейнджлогов. А то ведь конкуренты не дремлют и обязательно сопрут все изменения, а так пусть все гадают - чего же там вобще в сборке было изменено по сравнению с предыдущей версией. [/sarcazm]

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

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

шта?

я без понятия как там у L2jLovely с этим, может хардкодом в ядре, может в свойствах мобов, может даже в квесте на СА расписано. вот в овере это скажем в параметрах нпс расписано, с какого урвовня по какой есть прокачка, каким методом и каким шансом.

самый примитивный вариант: в нужном конфиге добавляем переменную SpawnCoords с содержимым вида SpawnCoords = x1,y1,z1;x2,y2,z2; ... ;xN,yN,zN далее в Config.java: public static ArrayList<Location> SPAWN_COORDS = new ArrayList<Location>(); ... String str = settings.getProperty("SpawnCoords", ""); if (!str.isEmpty()) { String[] spawnCoordsList = str.split(";"); for (String spawnCoords : spawnCoordsList) { try { Location loc = Location.parseLoc(spawnCoords); SPAWN_COORDS.add(loc); } catch (Exception e) {} } } ну и в итоге сам выбор координат превращается в чето-то типа такого if (!Config.SPAWN_COORDS.isEmpty()) { Location loc = Config.SPAWN_COORDS.get(Rnd.get(Config.SPAWN_COORDS.size())); newChar.setXYZInvisible(loc.getX(), loc.getY(), loc.getZ()); } else newChar.setXYZInvisible(template.spawnX, template.spawnY, template.spawnZ);

можно и попроще расписать if (Config.SPAWN_CHAR) { switch (Rnd.get(5)) { case 0: newChar.setXYZInvisible(Config.SPAWN_X, Config.SPAWN_Y, Config.SPAWN_Z); break; case 1: newChar.setXYZInvisible(Config.SPAWN2_X, Config.SPAWN2_Y, Config.SPAWN2_Z); break; case 2: newChar.setXYZInvisible(Config.SPAWN3_X, Config.SPAWN3_Y, Config.SPAWN3_Z); break; case 3: newChar.setXYZInvisible(Config.SPAWN4_X, Config.SPAWN4_Y, Config.SPAWN4_Z); break; case 4: newChar.setXYZInvisible(Config.SPAWN5_X, Config.SPAWN5_Y, Config.SPAWN5_Z); break; } } else newChar.setXYZInvisible(template.spawnX, template.spawnY, template.spawnZ); З.Ы. Но вобще это извращение - для каждой точки спавна заводить новые параметры в конфиге. лучше уж хранить это в одном параметре, в виде массива строк координат и разбирать это дело при загрузке на отдельные координаты.

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

а ничего что СА этих уровней качаются не юзом скилла на цель, а просто шансово при убийстве босса? проверяй, прописана ли для этих боссов прокачка на них СА с 12 до 13 уровня.

TARGET_AREA

для этого не мануалы нужны, а мозги и хоть какое-то знание явы.

ты как будто корейцев не знаешь - ударит им опять что-то в голову и выкинут коленце типа "а давайте пропустим несколько десятков номеров слотов и сделаем новые слоты с номерами ну например с 71".

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

ну это логично, ибо битовую маску со значениями слотов выше 31 в int не пошлешь. интерестно как будут выкручиваться если внезапно еще слотов добавят и 63 (при long) не хватит ну а мне пока даже на будущее нет смысла делать хранение в long - будут лишь лишние преобразования типов в итоге.

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

а так не пробовал? if(bodySlot == (ItemTemplate.SLOT_L_EAR | ItemTemplate.SLOT_R_EAR)) просто ты в if(bodySlot == ItemTemplate.SLOT_L_EAR | bodySlot == ItemTemplate.SLOT_R_EAR) уже над результатами сравнения производишь битовое сложение. или над ItemTemplate.SLOT_L_EAR и bodySlot - я просто не помнь ща наизусть очередность операций в таком случае.

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

экстрасенсы тут не водятся. для начала стоило хотя бы сборку указать.

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

ну или через ArrayUtils.contains , если вариантов классов много.

ну дак вон VREDNbIi утверждает что он это "делал еще 2 года назад" - так что видимо он тебе и может помочь.