Gaikotsu

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

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

например при помощи SchedulingPattern задавая время следующего возможного выполнения и потом сравнивая с ним текущее - этот класс может генерить время следующего выплнения посредством задавания его в формате cron'а например если задать SchedulingPattern time = new SchedulingPattern("0 17 * * tue"); то в time будет время до ближайшего вторника, 17:00 класс этот можешь взять из сборок на базе овера так же можешь заюзать Quartz, в целом делающий тоже что и SchedulingPattern, только с кучей доп. наворотов Но вобще тебе хватит и первого варианта за глаза, вместо целой библиотеки в виде Quartz

Впервые слышу.

составить правильный build.xml, настроить проект и его компиляцию в IDE и вперед З.Ы. только каким местом тут svn я не понял З.З.Ы. судя по "/* */" в началах строк - это у тебя декомпил? ковыряться с декомпилом - последнее дело... неочевидных багов/косяков при декомпиле может в код внестись куча, притом повторной компиляции они мешать не будут, но вот код в итоге может потом криво работать.

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

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

а в твоей сборке вобще существует поддержка хтмлок диалогов на разных языках?

я к примеру через батник пакую так @soft\l2encdec -h121 %1 %1.tmp @del %1 @ren %1.tmp %1 где %1 это переданное в батник имя файла, типа pack.cmd pack.utx

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

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

от сборки зависит к примеру в сервере на базе овера можно в нужные скиллы дописать примерно такое - в данном случае скилл нельзя будет юзать в инстансе с ид 123 <cond msgId="113"> <not> <player instanceZone="123" /> </not> </cond> или же можно вобще запретить использование в любых инстансах <cond msgId="113"> <player instanceZone="0" /> </cond> в данном случае скилл можно будет юзать тоьлко в нулевом инстансе, коим является основной рефлекшн игры.

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

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

Ну так тебе прямо указывают где проблема, вплоть до строки в классе. 1. NpcInstance.java:381 - NPE на 381 строке класса, что-то в этой строке равно null 2. SendProtocolVersion.java:45 - попытка в 45 строке класса прочесть данные за пределами того, что пришло в пакете, т.е. проще говоря считать больше байт, чем пришло. скорее всего криво сформированный пакет от клиента или вобще мусор вместо данных в нем.

Советую пробелы воткнуть вокруг переменной - некоторые клиенты без этого в строке байпасса переменную найти не могут.

В итоге будет у тебя в логе что-то типа такого выводить при входе и далее:

ну это ты чисто клиентские коды выводишь, а для полноты картины еще и то что сервер шлет выводить стоит для этого можно вывод в sendPacket класса GameClient добавить, как-то примерно так public void sendPacket(L2GameServerPacket gsp) { if (isConnected()) { if (DevConfig.SHOW_SERVER_PACKET_NAME && gsp != null && !DevConfig.HIDE_SERVER_PACKET_NAME.contains(gsp.getClass().getSimpleName())) _log.info(getLogin() + " <-- [S] " + gsp.getClass().getSimpleName()); getConnection().sendPacket(gsp); } } а для клиентских, более информативное что-то типа такого, в конце handlePacket класса GamePacketHandler, перед return msg; if (DevConfig.SHOW_CLIENT_PACKET_NAME) { if (msg != null) { if (!DevConfig.HIDE_CLIENT_PACKET_NAME.contains(msg.getClass().getSimpleName())) { _log.info(client.getLogin() + " --> [C] " + msg.getClass().getSimpleName()); if (DevConfig.SHOW_CLIENT_PACKET_DUMP && !DevConfig.SHOW_ONLY_UNKNOWN_PACKET_DUMP && buf.remaining() > 0) _log.info("Data [" + buf.remaining() + "]:\n\n" + Util.printData(buf.asReadOnlyBuffer())); } } else if (name != null) { if (!DevConfig.HIDE_CLIENT_PACKET_NAME.contains(name)) { _log.info(client.getLogin() + " --> [C] " + name + " [not implemented]"); if (DevConfig.SHOW_CLIENT_PACKET_DUMP && !DevConfig.SHOW_ONLY_UNKNOWN_PACKET_DUMP && buf.remaining() > 0) _log.info("Data [" + buf.remaining() + "]:\n\n" + Util.printData(buf.asReadOnlyBuffer())); } } }

Вобще по логике, чтобы не было косяков с текстурами одеваемой/снимаемой брони при смене вида целым костюмом, в такой ситуации для всех слотов у которых вид меняется этим костюмом надо слать 0 в качестве одетого предмета. Ну само собой кроме слота chest. Ну типа как вот примерно так (тип 1 - внешка меняет верх + низ, тип 2 - внешка в виде полного костюма): int[] inv = new int[Inventory.PAPERDOLL_ORDER.length]; for (int PAPERDOLL_ID : Inventory.PAPERDOLL_ORDER) inv[PAPERDOLL_ID] = charInfoPackage.getPaperdollItemId(PAPERDOLL_ID); if (charInfoPackage.getAppearanceType() == 1) { inv[Inventory.PAPERDOLL_LEGS] = 0; } else if (charInfoPackage.getAppearanceType() == 2) { inv[Inventory.PAPERDOLL_LEGS] = 0; inv[Inventory.PAPERDOLL_GLOVES] = 0; inv[Inventory.PAPERDOLL_FEET] = 0; } for (int itemId : inv) writeD(itemId);

Ты думаешь он хоть что-то из твоих фраз понял?

Выкинь нафиг ты этот говнокод.

За такого "баффера" того кто это написал надо избить ссаными тряпками. 1. в ветке "elif event.startswith("buff_")" при желании можно запросить бафф вобще любого существующего скилла (того же гм хаста к примеру). 2. в ветке "elif event.startswith("profile_")" что в подветке на бафф, что в подветке на сохранение, постоянно идет напрямую работа с бд. "кэширование данных? а нафиг оно надо.". одним этим при желании можно устроить своеобразный ддос серверу не особо даже напрягаясь при этом. З.Ы. я бы такое под страхом смерти на живой сервер не ставил.

Это не та Кхалифа

от сборки зависит, к примеру в овере атакующие/защитники пишутся в siege_clans (или в siege_players в случае реги отдельных игроков на ТВ)

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