Gaikotsu

ковырять ядро, а конкретно методы checkCondition и checkTarget в классе Skill (хз так ли точно в этой сборке так эти методы называются).

что мешает расписать все нужные эффекты раздельно? ну типа так: <skill id="358" levels="1" name="Bluff"> <!-- Deceives the enemy into turning his back, losing his urge to attack and becoming stunned for 9 seconds. Requires a dagger. Target cancel is possible. --> <!-- Обманом поворачивает противника к себе спиной. Отнимает у противника желание атаковать, противник теряет цель. Оглушает врага на 9 сек. Требуется кинжал. --> <table name="#activateRate">40</table> <table name="#magicLevel">77</table> <set name="levelModifier" val="20" /> <set name="icon" val="icon.skill0358" /> <set name="reuseDelay" val="8000" /> <set name="magicLevel" val="#magicLevel" /> <set name="hitTime" val="1000" /> <set name="hitCancelTime" val="500" /> <set name="mpConsume2" val="35" /> <set name="target" val="ONE" /> <set name="activateRate" val="#activateRate" /> <set name="skillType" val="DEBUFF" /> <set name="operateType" val="OP_ACTIVE" /> <set name="trait" val="DERANGEMENT" /> <set name="basicProperty" val="PSYCHO" /> <set name="nextAction" val="NONE" /> <set name="allowSkill" val="10279;10517;10025;10776;11770;1904;11264;11093;13314;1912" /> <set name="effectPoint" val="1" /> <set name="debuff" val="1" /> <cond msgId="113" addName="1"> <using kind="Dagger,Dual Dagger" /> </cond> <enchant1 levels="15" name="Chance"> <table name="#activateRate">42 44 46 48 50 52 54 56 58 60 62 64 66 68 70</table> <table name="#magicLevel">81 81 81 82 82 82 83 83 83 84 84 84 85 85 85</table> </enchant1> <for> <effect count="1" name="Stun" stackOrder="-1" stackType="stun" time="9" val="0" /> <effect count="1" name="Turner" time="0" val="0" chance="80" /> <effect count="1" name="DeleteHateOfMe" time="0" val="0" chance="80" /> <effect count="1" name="RemoveTarget" time="0" val="0" chance="80" /> </for> </skill> С заданным рейтом срабатывает стан, если он прошел, то только тогда с указанными шансами срабатывают остальные 3 эффекта.все полностью соответствует оффициальному описанию скилла skill_begin skill_name = [s_bluff1] /* [블러프] */ skill_id = 358 level = 1 operate_type = A2 magic_level = 77 special_level = 0 magic_critical_rate = 5 change_skill_id = 0 self_effect = {} effect = {{i_align_direction;80};{i_target_cancel;80};{i_delete_hate_of_me;80};{p_condition_block_act_skill;{10279;10517;10025;10776;11770;1904;11264;11093;13314;1912}}} end_effect = {} operate_cond = {{equip_weapon;{dagger;dualdagger}}} is_magic = 0 is_double = 0 mp_consume2 = 35 cast_range = 40 effective_range = 400 skill_hit_time = 1 skill_cool_time = 0 skill_hit_cancel_time = 0.5 reuse_delay = 8 activate_rate = 40 lv_bonus_rate = 20 basic_property = magic_abnormal_resist abnormal_time = 9 abnormal_lv = 1 abnormal_type = stun abnormal_instant = 0 irreplaceable_buff = 0 buff_protect_level = 0 attribute = {attr_none;0} trait = {trait_derangement} effect_point = -1 target_type = enemy_only affect_scope = single affect_limit = {0;0} next_action = none abnormal_visual_effect = {ave_stun} debuff = 1 ride_state = {@ride_none} multi_class = 0 olympiad_use = 1 skill_end

ой не нес бы ты пургу, не понимая о чем вобще речь идет...

<add - добавить <mul - умножить <sub - отнять <div - разделить <set - установить order означает порядок выполнения действий над статой - операции выполняются в порядке возрастания order. по сути можно использовать любые значения, но на практике обычно используют только несколько: 0x08 / 0x10 - для установки/прибавления базового значения параметра 0x0C - для прибавок бонусов от заточки предмета (используется только в описаниях предметов) 0x20 - используется во внутренних расчетах самого ядра, в случаях когда к базовому значения статы например надо прибавить значение, зависящее еще от чего-то (в основном это используется в StatFunctions) 0x30 - используется для умножения/деления базового значения (ну почти базового, т.к. к этому времени оно может быть уже модифицировано операциями с ордером 0x0C и 0x20) 0x40 - используется для установки/прибавления/вычитания из значения после 0х30. обычно используется для прибавления статичных значений к параметру 0x50 - используется для умножения/деления значений в которых должны учитываться и статичные прибавки 0x60 - используется для установки/прибавления/вычитания значений, на котрые более ничего не должно в дальнейшем влиять

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

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

ну там вроде я с масками изображений намудрил, давно уже иконки не добавлял новые в клиент

http://rghost.ru/7fPW8KDQs правда гарантию работы в интерлюде не даю - нет у меня его клиента под рукой для проверки. да, и название пака менять не надо - ибо шифрование текстур-паков привязано к их имени и если его поменять - оно будет неправильно декодироваться клиентом.

что мешает создать utx-пак с этими иконками то? там делво то на пару минут - UnrealEd, а потом закодить при помощи l2encdec

ковыряй запуски задач - там скорее всего проблема. З.Ы. но сама реализация инстанса в общем и в целом вырвиглазный писец...

блин... пользуйся тэгами code и spoiler - не читабельно же вобще.

ну вобще-то я программирую больше 9 лет. это именно с пхп начал в 2005-2006 году знакомиться. ну а так - продвижения есть, "небольшие" в качестве примера, если взять тот же пхп, то из написанного мной более-менее крупного: сайт нашего сервера (никакого готового движка - все с нуля написано своими руками ибо не очень то я доверяю в таких вещах готовым движкам - мало ли какие дыры там могут обнаружиться); админки под наши сервера - сначала под птс (выкладывал в шару) и кончая несколькими версиями под яву (сначала под феникс, а потом под сервер на основе овера); куча разных версий бз, некоторые из которых мной выкладывались в шару тут и на зг; список-каталогизатор для аниме (ну это чисто для своих нужд, чтобы удобней было вести учет в своей "небольшой" коллекции аниме [всего-то 3к+ наименований на данный момент]). а так же неисчислимое количество самых разных простых и не очень скриптов, которые я пишу по мере необходимости, когда надо по быстрому скажем обработать какие-то данные или еще что автоматизировать.

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

> Каким образом работает формула множитель обычно на серверах? чаще всего сначала идет увеличение шанса до 100%, а затем уже увеличение количества. но для некоторых типов вещей правила могут быть другими - например для адены или камней в катах идет изначально только увеличение количества и не затрагивается шанс. > Каким образом произвести замену по своей формуле? Точнее как данная формула выглядит? > Как все это заменить имея кучу лишних данных, но в то же время не затрагивая их? Забыть о таком нереальном деле - ибо править существующий патч - это ваять придется парсер этих строк, для выделения нужных данных из них, анализировать все это и пересчитывать. Проще и логичней все это генерировать, используя данные по дропу и спойлу из самого сервера. > Каким софтом это возможно реализовать или нужно писать свой личный софт для таких задач? Ой да чем угодно - я в свое время банально набросал для этого простейший скрипт на пхп, который выдирал данные из самой перовй моей бз (данные в которую заносились из скриптов pts-сервера), вносил по полученным данным дополнительную инфу в npcgrp, а так же генерил новые строки для skillgrp и skillname-e. кстати я походу в свое время был возможно первым кому в голову пришла идея такого патча и собственно говоря его реализация (покопавшись в архивах нашел у себя кажется одну из самых своих первых версий, еще от начала 2006 года) - по крайнйе мере мне до этого ничего подобное не попадалось тогда. вот кстати, кого может этот раритет заинтересует - он еще для C1 вроде делался - датирован 15.03.2006 сам по себе код правда страшненький - с пхп я тогда только -только начинал работать можно сказать.

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

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

бери тогда уж с гитхаба чистый бранч Ertheia от самих l2j и его пили.

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

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

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

легко и просто все пишется в аналогах блокнотов

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

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

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

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