Gaikotsu

Проверку на премиум не в классе инстанса смотреть надо, а в классе нпс, который туда перемещает.

Вы б еще на малинке сервер поднимали...

ты чо, тогда бы не было повода создать эту тему.

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

Ну, если есть исходники то не проблема дополнить функционал татушек, как это сделано с новыми красками в хрониках выше ХФ. Чтобы кроме стат к примеру скиллы выдавали, а в скиллы уже можно любые бонусы впихать.

а ты однако оптимист

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

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

Или просто отослать с сервера после выполнения байпасса что-то типа такого и никаких модифицикаций в интерфейсе не потребуется. public static void hide(Player player) { player.sendPacket(new ShowBoard(null, "101", player, false)); player.sendPacket(new ShowBoard(null, "102", player, false)); player.sendPacket(new ShowBoard(null, "103", player, false)); } Что значат передаваемые параметры public ShowBoard(String html, String id, Player player, boolean show) {

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

https://java-course.ru/begin/database03/ https://habr.com/ru/post/501756/ вот к примеру З.Ы. я у себя делал удаление отдельными запросами, чтобы проще было знать сколько записей затронул каждый запрос, для последующего вывода этого в лог сервера. Хотя в принципе смотрю конечно и батч эти данные возвращает, но не вижу смысла реально заморачиваться с усложнением кода запросов удаления предметов - тем более выигрыш в скорости обработки запросов на удаление, после переделки на батч, все равно будет считанные миллисекунды - на фоне общего времени загрузки сервера это ничто.

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

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

Не, ну мне реально интересно - что там за такой параметр в бд записывается, наличие/отсутствие которого влияет на стрельбу из лука. И вобще зачем это сделано? -- Кажется я понял в чем причина, декомпильнув и поизучав код сервера. Нашел я там такую порнографию, как то что проверка времени возможного следующего выстрела из лука высчитывается по тикам времени, из GameTimeController, а там оно высчитывается из из какого-то типа L2Calendar, в который изначально запихиваются данные о дате/времени, хранящиеся в server_data. Так что в теории если по какой-то причине текущее время и дата будут сильно отличаться от этих сохраненных, то я думаю и не такие косяки можно словить - фиг знает что там в сервере еще на эти тики времени и т.д. завязано. К примеру в таблице сохранилось время/дата которые еще не наступили (ну время там переводили зачем-то в системе или еще что), то в итоге все то что срабатывает при условии "время пришло/прошло" перестанет работать до тех пор, пока текущее время не догонит сохраненное. Зачем весь этот маразм был сделан - непонятно. Тот же реюз атаки при стрельбе из лука можно было сделать проще и понятней намного и без всяких привязок к каким-то странным календарям и т.п... Вобщем если вдруг решили перезапустить сервер и сделали частичный вайп, то не забудьте на всякий случай поудалять из server_data все записи начинающиеся с "GameTime."

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

Блин, неужели в этой "сборке" нет даже простейших вещей типа возможности задать определенные флаги для предметов? Ну типа такого для овера

Нда... даже такое в этой сборке через ж... сделано...

А если прям вобще приспичило запретить одевать, то тебе идти в пакет UseItem и добавлять костыли, там где начинается блок с условием if (item.isEquipable()) добавляя там свои проверки типа "если грейд предмета такой-то, а уровень игрока меньше такого-то - он идет нафиг".

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

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

Ты хотя бы допустимым для установки краски классом подходишь? т.е. классами 98-118, указанными там как допустимые. странный диапазон кстати, т.к. профы на 76 уровне идут с 88, а не с 98.

Зависит от хроник - в новых можно использовать просто байпас вида "url http://google.com/", а в старых же "url !XXXX" где вместо "ХХХХ" ставится ид из SysString клиента, с строкой адреса. Но в насколько старых хрониках это работает - я хз, насчет того что в том же интерлюде уже есть такое - не уверен.

А как оно дружит с другими прозрачными текстурами, накладываемыми поверх иконки? Ну там рамка для пвп-оружия/брони и т.п.

если у него вобще исходники то есть

да ему не только systemmsg менять надо - у него вобще system не того протокола - по скринам же видно что структуры некоторых пакетов от сервера клиенту не подходят. ТС, погляди какой протокол у сервера, оыбчно в конфиге задается минимальный/максимальный а так же глянь какой протокол у клиента: l2.exe -l2pv