Gaikotsu

можно и без войса, я конечно хз какие у ТС хроники, но как минимум с ХФ, а может и раньше, есть вот такая вот вещица связанные пакеты ShowPCCafeCouponShowUI (сервер) и RequestPCCafeCouponUse (клиент) и есть предметы-купоны как раз - вешаем на него хэндлер, вызывающий серверный пакет, а в клиентском разбираем и обрабатываем то что игрок ввел в диалог и отправил.

Я что-то в упор не вижу в сообщении ТСа каких либо упоминаний об интерлюде.

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

я может чего не понимаю, но что не так то?

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

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

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

хоть корректно слияние делал? с правильными коррекциями всех uid персов, предметов и т.д. с базы из которой переносил в основную базу?

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

Эй археолог, ты слишком глубоко копаешь.

пробел то перед width убери и делать конкатенацию строк через "+" - это не есть гут, если этого много и вызывается часто, ибо там на каждую такую операцию создается новый объект-строка. юзай StringBuilder в таких случаях.

И что тут может быть непонятного?... Неужели знания английского вобще на полном нуле? Ясным и понятным же языком написано что пытается считать числовое значение из конфига, но в качестве входных данных получает неподходящую для конвертирования в число строку - в данном случае пустую строку. Если есть исходники, то смотри какой параметр пытается прочесть из конфигов на строке 3418 класса Config.java и уже от этого пляши дальше.

я конечно не знаю как там в этой сборке, тем более автор так и не сказал что это за сборка, но как варинт может так sendPacket(new SystemMessage(SystemMessageId.YOUR_KARMA_HAS_BEEN_CHANGED_TO_S1).addNumber(karma));

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

Ну или допиливай сам процесс крафта + хранение данных о том что можно скрафтить

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

вижу в пвсофт все традиционно делается через жопу...

Видимо с запретом использовать точеные вещи или например вещи выше определенного грейда

тоже даю свое разрешение на правку

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

в клиенте вобще-то потребление мп/хп всеми скиллами указано, в SkillGrp

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

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

ИМХО из бд вобще все хранение статики есть смысл выпиливать и переводить на хранение в XML ибо это банально удобней в плане той же расширяемости и т.д. Расширяемости в плане добавления к примеру новых свойств тех же спавнов например. В случае с бд к примеру это потребует добавления еще столбцов в таблицу, даже если новые свойства нужны будут не очень большому количеству нпс/мобов. Можно конечно извратиться и вместо добавления новых столбцов в таблицы спавнов писать отдельные аи для нужных нпс/мобов и там задавать нужные свойства, но как быть в случаях когда для части спавнов свойства должны быть одни, а для части - другие? Можно конечно городить условия в аи, определяя по координатам конкретные спавны, но это же изврат... Тогда как в XML при желании можно тонко настраивать отдельные спавны одного и того же нпс, и он в зависимости от этого будет вести себя по разному. Чисто для примера - 4 спавна одного и того же нпс (невидимого нпс 18919 вобще любят корейцы использовать в куче мест, как контроллеры различных событий в локациях), действующего по разному в зависимости от конкретного спавна: <spawn count="1"> <npc id="18919"> <set name="ai" value="superion.EnhancedBossController" /> <set name="index" value="1" /> <set name="normal_boss_id" value="26137" /> </npc> <point x="191960" y="56420" z="-7630" /> </spawn> <spawn count="1"> <npc id="18919"> <set name="ai" value="superion.EnhancedBossController" /> <set name="index" value="2" /> <set name="normal_boss_id" value="29006" /> </npc> <point x="17740" y="109670" z="-6480" /> </spawn> <spawn count="1"> <npc id="18919"> <set name="ai" value="superion.EnhancedBossController" /> <set name="index" value="3" /> <set name="normal_boss_id" value="25772" /> </npc> <point x="-114712" y="150450" z="-13870" /> </spawn> <spawn count="1"> <npc id="18919"> <set name="ai" value="OmegaGolemSpawner" /> <set name="targetable" value="false" /> <set name="undying" value="true" /> </npc> <point x="199482" y="84497" z="-191" /> </spawn> А насчет "сложностей массового изменения данных" в XML я даже не парюсь - мне не сложно в том же пхп по быстрому накорябать скриптик, который мне все что необходимо в хмлке поправит, благо хмлку в пхп загрузить в память в виде объекта, с которым после этого можно делать что угодно, можно буквально одной строчкой. Обратное сохранение измененного в виде хмл тоже особой сложности не составляет - уж один раз написать функцию сохранения этого самого объекта в файл как небходимо написать несложно...

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