Gaikotsu

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

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

или Rar с новым алгоритмом из 5-й версии. но только 5-й версией потмо и можно распаковать.

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

если на пакетном уровне не поддерживается такое, то нет. и я вот увы не помню, были ли в пакете MultiSellList во времена интерлюда поля с этими данными.

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

ничего сложного вроде нет. вполне логично что в RequestMultiSellChoose производить обработку новых параметров (по аналогии с энчантом). а в пакете MultiSellList в нужных полях слать ид обоих частей ауги (два поля сразу после поля с энчантом).

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

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

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

следующим вопросом 100% будет "а где и что править то для этого?"

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

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

это еще мягко говоря я лично этот код там сомтрел чисто чтобы понять что и когда в этих квестах делать надо, а реализовал совершенно по другому. типичный динамический квест у меня выглядит так package dynamic_quests; import l2p.gameserver.model.dynamicquest.DynamicQuest; public class _0001_DestroyTheDaemonAngma extends DynamicQuest { public _0001_DestroyTheDaemonAngma() { super(1); } } проще некуда, если не учитывать нужные для работы квеста данные, типа таких всем у меня рулит общий класс DynamicQuest, которому в большинстве случаев достаточно передать ид квеста, а дальше уже пусть разбирается.

даже близко не норм. зачем тебе запускать задачи CheckPlayerIsInCommandChannel и setAntharasSpawnTask столько раз, сколько у тебя народу в кк?

классы Calendar и ThreadPoolManager с Runnable или RunnableImpl тебе в помощь

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

более корректное private void cloneOwnerEffect(Effect ef) { Skill skill = ef.getSkill(); if (skill.isOffensive() || skill.isToggle() || skill.isCubicSkill()) return; for (EffectTemplate et : skill.getEffectTemplates()) { if (!et._applyOnSummon || et._applyOnCaster || et.isOffensive(skill.isOffensive())) continue; Effect effect = et.getEffect(new Env(this, this, skill)); if (effect != null) { effect.setCount(ef.getCount()); effect.setPeriod(ef.getCount() == 1 ? ef.getPeriod() - ef.getTime() : ef.getPeriod()); getEffectList().addEffect(effect); } } } а в onSpawn класса Summon добавить if (owner != null) for (Effect ef : owner.getEffectList().getAllEffects()) cloneOwnerEffect(ef);

не совсем корректно 1. скопируются только первые эффекты из скиллов. 2. скопируются не только баффы, но и к примеру дебаффы. 3. при копировании у эффекта выставится полная продолжительность, а не текущая.

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

:рукалицо: 2автор: скорее всего ошибка из-за того, что у тебя после окончания эвента игрокам показывается какая-то хтмлка, в которой есть ссылка вида "... npc_%objectId%_ ...", при нажатии на которую и вызывается эта ошибка. З.Ы. вариант не 100%, но самый вероятный.

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

а лучше настрой нормально работу с бд судя по проблеме соединение и обмен данными идут не в той кодировке (все должно быть в utf8).

in share only Rest-Zone with very crappy sources.

или объявить на весь мир зону с запретом трейда - хотя это то еще извращение.