Gaikotsu

Научишься не тому на старой и давно не поддерживаемой сборке и потом буешь мучительно переучиваться на работу с более актуальной

Кстати еще на тему более удобного вызова диалогов вставки/удаления ЛС я бы вобще так сделал - при простом клике на ЛС открывается диалог вставки, при клике с контролом - диалог удаления.

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

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

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

Можно конечно один класс чисто компильнуть и в jar заменить, но я задолбаюсь как это делать объяснять ибо это не так просто - в двух словах не объяснить. не нужно, после твоей правки все нпс что говорят через вызов Functions.npcSay уже будут говорить в общий чат. --- Вобще, изучи хотя бы основы программирования на java - намного проще тебе в итоге будет понимать что и как работает в сервере и правка таких мелочей уже не будет вызывать вопросов.

ну так в Functions.npcSay как раз и должно указываться в каком типе чата говорить к примеру у меня методы npcSay вызывают метод npcSayInRange, а в нем уже вызывает пакет NpcSay, в котором вторым параметром как раз и передается тип чата. Просто меняешь там в вызове ChatType.NPC_SAY на например ChatType.ALL и все. блин, это же все самые основы...

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

они скорее всего шлют в тип чата NPC_SAY (тип 22) [еще есть NPC_SHOUT (тип 23)] и вот я не помню была ли в хф возможность выключить в настройках именно эти типы чата. Под рукой сервера и клиента хф нет, но в более новых хрниках это вот это вот.

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

Исходники ядра то есть? Если да, то просто ищешь где там распарсивается enchant_items.xml и дальше уже там разбираешь все что там обрабатывается и какие варианты значений для параметров возможны. Ну и дописываешь что-то свое если чего не хватает. Если же исходников нет, то максимум можешь попробвоать декомпильнуть ядро и так же поизучать где и что. Но вот вносить уже свои правки - это проблемно без внесения потенциальных косяков из-за корявой декомпиляции.

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

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

Даже отсюда не качается? http://akumu.ru/lineage2/L2RU/P64/L2RU-P64-D20160630/

там же в папке sql есть батник установки... З.Ы. перед его запуском само собой в mysql_settings.bat надо указать параметры подключения к бд. ну и путь к mysql указать свой, если он отличается от того что указан в этом батнике

Исходники то есть? Если да, то изучай содержимое пакета RequestDropItem из ядра, на тему того что еще может там препятствовать выкидыванию предметов.

Ловите некрофила

Ну, как говорится, садомазо - дело добровольное.

Почему не воспользоваться тем же XAMPP, в котором все компоненты вполне актуальных версий, а сам по себе он тоже вполне просто управляем и настраиваем?

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

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

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

Если у тебя опции стандартные и ты их не менял, то что 16180-16199, что 16200-16340 - это все опции со скиллами. В итоге я не понимаю почему ты удивлен тому что тебе выпадает по 2 скилла...

вариаций должно быть всегда два - это и есть 2 ид опций из которых генерится конечное ид аугментации. на первом скрине у тебя уже ошибка - сумма групп в вариации у тебя выше 100%, а должна быть равна 100%. во втором у тебя ошибка в том что не может быть третьей, четвертой и т.д. вариаций. и как вобще связан шанс группы с суммой шансов опций внутри группы? сумма шансов всегда должна быть равна 100%, с какой стати ты решил что она должна быть равна шансу самой группы? И вобще, у тебя сервер матом должен в логе ругаться на подобное при загрузке - неужели простейшей защиты "от дурака" в плане возможных некорректных описаний ЛСов в парсер не додумались добавить? и вобще я не понимаю что может быть непонятного то? там вроде все логично и сложно не понять как сделать правильно... Вот для примера из моей сборки описание камня, в котором во второй вариации можно с вероятностью в 5% получить опцию с умением (конкретно тут это ид опций в диапазоне 32237-32373 в последней группе второй вариации) Не обращай внимания на чуток другой синтаксис - общий смысл и принципы реализации те же. Если непонятно почему у меня местаи идут по два ид разделенные двоеточием, то это я так для сокращения описаний задаю сразу диапазон ид, т.е. например <option id="30377:30451" chance="1.315" /> будет означать что перечисляются опции с 30377 по 30451, каждая с шансом в 1.315%. <!-- Камень Духа / Spirit Stone --> <stone id="45929" level="46" type="WEAPON"> <variations type="WARRIOR"> <variation part="1" chance="100.0"> <option id="30377:30451" chance="1.315" /> <option id="30452" chance="1.375" /> </variation> <variation part="2" chance="60.0"> <option id="30453:30511" chance="1.666" /> <option id="30512" chance="1.706" /> </variation> <variation part="2" chance="25.0"> <option id="30513:30522" chance="10.0" /> </variation> <variation part="2" chance="10.0"> <option id="30523:30587" chance="1.515" /> <option id="30588" chance="1.525" /> </variation> <variation part="2" chance="5.0"> <option id="32237:32372" chance="0.729" /> <option id="32373" chance="0.856" /> </variation> </variations> <variations type="MAGE"> <variation part="1" chance="100.0"> <option id="30377:30451" chance="1.315" /> <option id="30452" chance="1.375" /> </variation> <variation part="2" chance="60.0"> <option id="30453:30511" chance="1.666" /> <option id="30512" chance="1.706" /> </variation> <variation part="2" chance="25.0"> <option id="30513:30522" chance="10.0" /> </variation> <variation part="2" chance="10.0"> <option id="30523:30587" chance="1.515" /> <option id="30588" chance="1.525" /> </variation> <variation part="2" chance="5.0"> <option id="32237:32372" chance="0.729" /> <option id="32373" chance="0.856" /> </variation> </variations> </stone>

Так вроде по простой логике делать: - для первой вариэйшн делаешь одну группу с шансом 100%, в которой только опции дающие чисто статы - для второго вариэйшн 2 группы по 50%, в первой из которых опять же только опции дающие статы, а во второй только опции со скиллами Ну и само собой соблюдаешь правило, что сумма шансов всех опций внутри каждой группы должна быть равна 100%. На последнем скрине вроде так у тебя и описано и должно работать.