Gaikotsu

Пакеты для этих диалогов и т.д. есть уже как минимум в ХФ. Возможно и ниже есть, но я лично не смотрел. З.Ы. ShowPCCafeCouponShowUI + RequestPCCafeCouponUse

я конечно через JS куки не выставлял, но почему для кук при выставлении в $.cookie не задается их время жизни?

и которая строка тут 129?

<sarcazm> Спасибку кинет разрабу, хватит ему и этого за работу. </sarkazm>

ну как бы логично - метод giveItems не может принимать в качестве второго параметра массив, а только одиночный объект типа ItemHolder хочешь чтобы понимало - дорабатывай оный метод, к примеру перепиши это protected void giveItems(PlayerInstance player, ItemHolder holder) { giveItems(player, holder.getId(), holder.getCount()); } на это protected void giveItems(PlayerInstance player, ItemHolder... holder) { for (ItemHolder h : holder) giveItems(player, h.getId(), h.getCount()); }

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

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

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

ну в основе тут реальный птс хф, а экст чисто для расширения функционала, типа автолута, оффтрейда и т.п.

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

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

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

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."

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

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