Gaikotsu

[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 года назад" - так что видимо он тебе и может помочь.

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

в пакете NpcInfo слать ид существующего на сервере клана, с нужным значком

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

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