Gaikotsu

При криптовании с 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,", т.е. указание что строка в юникоде - подозреваю что именно в этом у тебя ошибка.

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

А что в конфиге нет параметров на это? К примеру на минимальный/максимальный уровень мобов что могут стать чемпионами?

Так вроде ж понятно из ошибки, что размер данных не соответствует ожидаемому, т.е. как вариант в каких-то условиях приходит кривой пакет AuthRequest Так что только изучать, что конкретно криво приходит - завернуть к примеру этот фрагмент кода, в котором происходит ошибка (содержимое метода readImpl класса AuthRequest), дополнительно в try/catch и в случае появления ошибки выводить в catch в лог к примеру полностью дамп пришедших данных. после чего изучать и думать.

так и хочется орфографическим словарем треснуть...

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

Кстати выше приведенный код корректно проверит только клановые значки, но не значки альянса и тем более не значки на клановый щит (есть ли они в IL я не помню)

с фига ли мобиус это по сути та же лыжа, т.е. ее ответвление. жтс же базируется на овере

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

Доработать пакет NpcInfo на эту тему