Gaikotsu

ну вот по процессам же видно что у тебя уже гейм запущен - процесс 3975

// код для спавна нужного нпс

По спавну нпс/моба в определенное время - пользуем связку Future/ScheduledFuture и SchedulingPattern. Первое непосредственнно для обявления самой задачи спавна, а второе для вычисления времени, через которое должна эта задача сработать. пример самой примитивной реализации ThreadPoolManager.getInstance().schedule(new Runnable() { public void run() { // код для спавна нужного нпс } }, new SchedulingPattern("0 16 * * sun").next(System.currentTimeMillis()) - System.currentTimeMillis()); в данном примере задача отработает в ближайшее воскресенье, в 16:00.

в ошибке же ясно написано что для ноды production надо для начала объявить что для нее допустим атрибут enchant. это в dtd делается, если что. пример <!ELEMENT production (#PCDATA)> <!ATTLIST production id CDATA #REQUIRED count CDATA #REQUIRED enchant CDATA #IMPLIED attr CDATA #IMPLIED time CDATA #IMPLIED augmentation CDATA #IMPLIED chance CDATA #IMPLIED>

причем здесь вобще текстуры? 2ТС: два варианта: 1. ругается какой-то скрипт, который обращается к необявленному ранее нпс. 2. ругается парсер нпс, на описание нпс, который ссылается на опять же не обявленного ранее другого нпс.

лишь бы ляпнуть 2ТС: все или почти все строки в подобных диалогах находятся в SysString-ru, если там нет, то тогда в SystemMsg-ru. ну а пустующее место в диалоге заполняется при получении одного из пакетов связанных с премиум шопом, каким конретно так с лету не скажу. сам я шоп этот домучивал лишь до некоторого уровня, чтоб не критовал и не вис клиент при обращении к нему, а не полноценно - т.к. все равно в планах его использования нет.

более информативно было бы увидеть текст ошибки.

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

SysString-e

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

речь не об этой кодировке, а об кодировке текста - win1251, utf8 и т.д.

можно и гланды через задницу удалять, но зачем?

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

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

держи l2on_drop_and_spoil_lindvior.zip

http://www.html5canvas.ru/

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

копать reduceCurrentHp в классе RaidBossInstance метод и название класса может отличаться, но в большинстве сборок оыбчно так и зовется. сделать там обработку типа такого и все: @Override public void reduceCurrentHp(double damage, double reflectableDamage, Creature attacker, Skill skill, boolean awake, boolean standUp, boolean directHp, boolean canReflect, boolean transferDamage, boolean isDot, boolean sendMessage) { super.reduceCurrentHp(1, reflectableDamage, attacker, skill, awake, standUp, directHp, canReflect, transferDamage, isDot, sendMessage); }

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

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

ни сборки, ни хроник... автор, ты форумом ошибся - тебе однозначно к экстрасенсам.

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

еще один основатель "супер тимы по разработке сервера"...

по моему во всех нормальных сборках эта проверка уже изначально встроена в парсер мультиселов.

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