Gaikotsu

ну... тот же fernflower никто не отменял. хотя конечно же если чисто интересно посмотреть то, как реализовано та или иная вещь - для повторной компиляции то уже не очень получившееся подходит.

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

докатились блин, уже и офф баги воспроизводить...

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

ну значит пусть в мануалы переносят модеры

Думаю все в курсе, что в Lindvior ввели Beauty Shop (салон красоты), предназначенный для изменения внешнего вида персонажей (прически, цвета волос, лица). Ну и собственно в данном руководстве я хочу более-менее подробно описать, как реализовать данное дело в сервере, в частности на сервере основанном на оверах. Итак, поехали: Первым делом создадим 3 новых поля в таблице characters, аналоги полей face, hairStyle и hairColor - назовем их к примеру newFace, newHairStyle и newHairColor. Объяснять как читать и писать в эти поля, а так же как добавить новые переменные и геттеры/сеттеры для них в класс Player я не буду - это самые основы знания Java, не знать такое просто грешно. Может сразу возникнуть вполне закономерный вопрос - а почему бы не использовать существующие поля для хранения информации о внешности? Ответ прост - в некоторых ситуациях нам потребуется знать и то, каким была внешность до посещения салона красоты, к примеру для функции отмены изменений в том же самом салоне, или же для фестиваля хаоса - новые прически на фестивале не отображаются (правда насчет этого информация неподтвержденная, но так написано в патчноутах). Далее озаботимся хранилищем данных о допустимых прическах и т.д., а так же загрузкой этих данных при запуске сервера. Хранить данные мы будем в xml-файле следующей структуры: И для примера фрагмент xml с данными Внимательные могут сразу же заметить избыточность данных в файле - для каждой расы/пола в общем-то данные одни и те же. Я это знаю, просто обычно предпочитаю реализовывать многое с учетом того, что может быть сейчас и все одинаково для любой расы/пола, но кто их корейцев знает - могут и изменить в будущем эту ситуацию. Так что в принципе если вам такая избыточность не нужна - это легко все дорабатывается до одного единственного набора данных для любой расы/пола. Опять же это делать вам самим, тем более что это легко - ломать не строить. Далее добавляем в ядро сервера парсер этих данных и хранилище для них. Парсер: Хранилище: Структуры для хранения данных: В парсере вы можете заметить для чтения значений используется некие методы c названием Util.parseValue( ... ) - приводить их код я не буду, т.к. и так понятно как и что они делают - можете просто написать свою реализацию их или же использовать уже что-то готовое (методы, выполняющие примерно те же функции, насколько помню вроде как были и в оригинальном овере). Далее нам необходимо внести мелкие изменения в пакеты UserInfo, CharInfo и GMViewCharacterInfo, для корректного отображения новой внешности. Изменения простейшие, типа таких: Ну и напоследок самое главное - все пакеты, связанные с салоном красоты. Объяснять их содержимое думаю нет смысла - они достаточно просты и по их коду и так все понятно. Но сначала не забудем добавить в GamePacketHandler обработку необходимых клиентских пакетов: Ну и непосредственно сами пакеты. Клиентские: И серверные пакеты: И опкоды этих пакетов: Ну вот собственно и все. Если я что и не описал или не пояснил - это в основном мелочи, до которых вы сами сможете без проблем додуматься.

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

нафиг мне к нему обращаться?1-е - я интерлюдом не занимаюсь, 2-е - у меня своя сборка есть.

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

смотреть в reduceCurrentHp, а конкретно проверку isDamageBlocked() - добавить в нее или непосредственно в сам reduceCurrentHp доп проверки на то, откуда приходит дамага - извне или от лица самого объекта под бессмертием.

ясно же из ошибки видно что попытка обратиться к несуществующему объекту (и в результате NPE) и даже строка в классе указана, где конкретно ошибка возникла - что еще то нужно для ее решения?

ну в любом случае пихать подобные вещи в пакеты не очень хорошо. лучше уж повесить слушатель на вход в игру и там все подобное обрабатывать вот к примеру как у меня сделана отсылка запроса на начало квеста пробуждения через слушатели (при входе в игру, изменении уровня или класса - все в одном флаконе): package listeners.players; import l2p.gameserver.instancemanager.AwakingManager; import l2p.gameserver.listener.actor.player.OnClassChangeListener; import l2p.gameserver.listener.actor.player.OnLevelChangeListener; import l2p.gameserver.listener.actor.player.OnPlayerEnterListener; import l2p.gameserver.model.Player; import l2p.gameserver.model.actor.listener.PlayerListenerList; import l2p.gameserver.model.base.ClassId; import l2p.gameserver.scripts.ScriptFile; public class AwakingRequest implements ScriptFile { private static PlayerEnterListener _playerEnterListener; private static LevelChangeListener _levelChangeListener; private static ClassChangeListener _classChangeListener; @Override public void onLoad() { _playerEnterListener = new PlayerEnterListener(); _levelChangeListener = new LevelChangeListener(); _classChangeListener = new ClassChangeListener(); PlayerListenerList.addGlobal(_playerEnterListener); PlayerListenerList.addGlobal(_levelChangeListener); PlayerListenerList.addGlobal(_classChangeListener); } @Override public void onReload() { PlayerListenerList.removeGlobal(_playerEnterListener); PlayerListenerList.removeGlobal(_levelChangeListener); PlayerListenerList.removeGlobal(_classChangeListener); } @Override public void onShutdown() {} private void sendRequest(Player player) { if (player.isAwaking() || player.getLevel() < 85 || player.getClassLevel() != 4 || player.getVar("GermunkusUSM", false) || player.getClassId() == ClassId.JUDICATOR) return; if (player.getActiveSubClass().isBase() || player.getActiveSubClass().isDouble()) AwakingManager.getInstance().sendReqToStartQuest(player); } public class PlayerEnterListener implements OnPlayerEnterListener { @Override public void onPlayerEnter(Player player) { sendRequest(player); } } public class LevelChangeListener implements OnLevelChangeListener { @Override public void onLevelChange(Player player, int oldLevel, int newLevel) { sendRequest(player); } } public class ClassChangeListener implements OnClassChangeListener { @Override public void onClassChange(Player player, int oldClass, int newClass) { sendRequest(player); } } }

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

да

в параметрах запуска есть данный параметр? -Dfile.encoding=UTF-8

вполне обычный прикол - скорее всего где-то вызывается System.exit(x) или Runtime.getRuntime().exit(x).типичный сюрприз для тех кто поимел сырцы не от разработчиков, а откуда-то еще. З.Ы. только не удали необходимые вызовы Runtime.getRuntime().exit(x), а то в серве они и для дела используются

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

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

покажите мне того "умника", который будет подобное пихать в EnterWorld, чтобы порекомендовать ему получше изучить структуру сервера и не пихать не в те места данное дело. З.Ы. такое лучше обрабатывать в методе, который и отвечает за разные действия при изменении уровня (к примеру в овере это метод levelSet из класса Player). или обрабатывать подобное в листенерах типа onLevelChange, котрые так же вызываются в levelSet.

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

просто если это вот это - http://forum.start-dev.16mb.com/ (а судя по всему это так и есть, т.к. фикслист один в один), то там уже аж ревизия 5600. З.Ы. если по количеству ревизий судить о продуктивности, то получается что я к примеру вообще ничего не делал - у меня с декабря прошлого года дай бог сотня ревизий в свн наберется. не любитель я каждый чих сразу же бежать и заливать в свн - фиксации туда я дай бог раз в одну-две недели делаю, сразу множества накопившихся фиксов.

количество ревизий конечно умиляет. неужели каждый "чих" идет отдельной ревизией?

еще может быть отдельная таблица в бд, где задаются параметры AI для мобов с определенным ид - все от сборки зависит. и нет - не надо писать 100 AI для 100 мобов с одним ид - AI для них будет один и тот же.

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

отдельное аи для моба и в аи добавить такое (метод может называться по другому, в зависимости от сборки - это пример для овера) @Override protected boolean randomWalk() { return false; } или же в хмл с параметрами моба прописать (опять же пример для овера) <ai_params> <set name="noRandomWalk" value="true" /> </ai_params>