Gaikotsu

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

значит остается только страдать дальше - без исходников не исправишь

А что за сборка? Неужели в ней нет нормальных триггеров?

Что свидетельствует о том что в данной сфере ты не очень долго З.Ы. работал с птс с 2005 до 2010 года - с С0 до ХБ, после чего перебрался на яву.

зависит от сборки к примеру может быть так skill.getEffects(caster, target); для получения эффектов скилла без доп. телодвижений или например npc.doCast(skill, target); в этом случае будет выполнена вся цепочка каста - потребление мп, уход в реюз, анимация и т.д.

декодировать Localization.ini и посмотреть - на существующие ли текстуры карты указывают соответствующие параметры. пример может там у тебя ссылки на текстуры в L2Font-e.utx, а у тебя в наличии L2Font-ru.utx или наоборот

должны быть опции типа showall или show_all для мультисела. З.Ы. вангую, сборка - это опять недосборка под названием пвсофт?

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

или банально не реализовали шансовость захардено оно вряд ли, если да - то это очень кривожопо - ибо разные скиллы дающие вампирик имеют разные шансы к примеру у меня так описыаются такие скиллы <!-- Поэма Лютни / Lute Melody --> <skill id="11522" levels="4" name="Поэма Лютни" enchant_levels="10"> <!-- [01] На 30 мин. для члена группы Скор. Атк. +34%, Скор. Маг. +31%. С определенным шансом накладывает 9% эффект Гнева Вампира. [02] На 30 мин. для члена группы Скор. Атк. +35%, Скор. Маг. +32%. С определенным шансом накладывает 9% эффект Гнева Вампира. [03] На 30 мин. для члена группы Скор. Атк. +36%, Скор. Маг. +33%. С определенным шансом накладывает 9% эффект Гнева Вампира. [04] На 30 мин. для члена группы Скор. Атк. +37%, Скор. Маг. +34%. С определенным шансом накладывает 9% эффект Гнева Вампира. --> <table name="#time">1800</table> <table name="#rate1">1.34 1.35 1.36 1.37</table> <table name="#rate2">1.31 1.32 1.33 1.34</table> <table name="#reuseDelay">2000</table> <table name="#abnormalLevel">1 2 3 4</table> <table name="#mpConsume2">140 151 170 181</table> <table name="#magicLevel">85 90 95 99</table> <stat name="magicLevel" value="#magicLevel" /> <stat name="mpConsume2" value="#mpConsume2" /> <stat name="icon" value="icon.skill11518" /> <stat name="reuseDelay" value="#reuseDelay" /> <stat name="hitTime" value="700" /> <stat name="target" value="PARTY" /> <stat name="skillRadius" value="1000" /> <stat name="skillType" value="BUFF" /> <stat name="operateType" value="OP_ACTIVE" /> <stat name="coolTime" value="300" /> <stat name="nextAction" value="NONE" /> <stat name="effectPoint" value="687" /> <stat name="blockSlot" value="@lute_melody" /> <enchant route="1" name="Cost"> <table name="#mpConsume2">173 166 158 151 144 137 129 122 115 108</table> </enchant> <enchant route="2" name="Time"> <table name="#time">1980 2160 2340 2520 2700 2880 3060 3240 3420 3600</table> </enchant> <for> <effect name="Buff" stackOrder="#abnormalLevel" stackType="buff_special_move" time="#time"> <add order="0x40" stat="absorbDam" value="9" /> <max order="0x40" stat="absorbDamChance" value="80" /> <mul order="0x30" stat="pAtkSpd" value="#rate1" /> <mul order="0x30" stat="mAtkSpd" value="#rate2" /> </effect> </for> </skill> и как это выглядит в офф скриптах skill_begin skill_name = [s_enchanter_move_up1] /* [포엠 오브 비파] */ skill_id = 11522 level = 1 operate_type = A2 magic_level = 85 special_level = 0 magic_critical_rate = 5 change_skill_id = 0 self_effect = {} effect = {{p_attack_speed;{all};34;per};{p_magic_speed;{all};31;per};{p_vampiric_attack;9;80};{i_dispel_by_slot;improve_vampiric_haste;-1};{i_dispel_by_slot;attack_time_down;-1};{i_dispel_by_slot;vampiric_attack;-1};{i_dispel_by_slot;casting_time_down;-1};{p_block_buff_slot;{improve_vampiric_haste;attack_time_down;vampiric_attack;casting_time_down}}} end_effect = {} is_magic = 22 is_double = 0 mp_consume1 = 28 mp_consume2 = 112 cast_range = -1 effective_range = -1 skill_hit_time = 0.7 skill_cool_time = 0.3 skill_hit_cancel_time = 0.5 reuse_delay = 2 activate_rate = -1 lv_bonus_rate = 0 basic_property = none abnormal_time = 1800 abnormal_lv = 1 abnormal_type = buff_special_move abnormal_instant = 0 irreplaceable_buff = 0 buff_protect_level = 0 attribute = {attr_none;0} trait = {trait_none} effect_point = притом есть очень важный ньюанс - если несколько скиллов дают вампирик, то шансы от каждого скилла не складываются - просто выбирается максимальный шанс из имеющися. т.е. к примеру один скилл дат шанс срабатывания вампирика в 30%, а другой 80% - в итоге будет шанс в 80%.

а что там переносить то? по сути поменять в Compiler.java опцию -1.6 на -1.8 и заменить библиотеку ecj на версию компилящую в 8 яву и все по сути. а, ну и в build.xml ту же опцию для javac поправить. ну и может поправить несколько конфликтующих методов в классах, о которых эклипс или идея сами сообщат после переключения проекта на уровень совместимости с 8 явой.

зачем? тогда было бы слишком легко.

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

вобще странная так-то реализация клинс и аналоги должны быть реализованы по аналогии с канселом, просто вместо баффов сносить любые дебаффы (кроме тех у кого стоит запрет канселинга) с 100% шансом, до 10 штук даже в офф скриптах если что эффект клинса обявлен как {i_dispel_by_category;slot_debuff;100;10} для сравнения - эффект кансела {i_dispel_by_category;slot_buff;25;5}

jar - это обычный zip-архив, так что при измненении содержимого class-файлов, при том что их размер остался примерно тот же, они могут начать более эффективно сжиматься (или наоборот хуже). так же jar'ка могла создаваться при другом указанном коэффициенте сжатия.

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

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

А если тебе для другого сета захочется сделать под другой уровень энчанта - будешь еще атрибуты однотипные вводить? сделай лучше универсальный параметр для скиллов сета, который будет указывать, начиная с какого уровня заточки частей сета этот скилл выдавать. Вот как пример - начиная с заточки +6 выдаются разные уровни скилла 13341. <set id="209"> <parts> <head id="19789;19853;19917;35028;35058" /> <chest id="19790;19854;19918;35029;35059" /> <legs id="19791;19855;19919;35030;35060" /> <gloves id="19792;19856;19920;35031;35061" /> <feet id="19793;19857;19921;35032;35062" /> </parts> <skills> <skill id="13091" level="1" parts="2" /> <skill id="13091" level="2" parts="3" /> <skill id="13091" level="3" parts="4" /> <skill id="13091" level="4" parts="5" /> <skill id="13063" level="1" parts="5" /> <skill id="13341" level="1" enchant="6" /> <skill id="13341" level="2" enchant="7" /> <skill id="13341" level="3" enchant="8" /> </skills> </set>

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

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

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

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

любая на базе Phoenix/Overworld/Lostworld там имеется работа с отдельной таблицей item_delayed в которую можно добавлять записи на выдачу предметов и которую сервер проверяет на наличие новых записей с определенной периодичностью. Смотри и изучай вобщем класс DelayedItemsManager в ядре.

В той теме я тебе уже ответил о причине такого. Если есть исходники, то изучай метод setTarget в Creature или NpcInstance на тему накладывания/снятия абнормала 17. Если же исходников нет, то увы...

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

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