Gaikotsu

там же в папке 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%. На последнем скрине вроде так у тебя и описано и должно работать.

геодата то хоть включена?

Не помню как там в пвсофт, но в ядре должен быть класс с именем типа Stats, в котором обычно все статы перечислены и там в обявлениях стат могут быть явно заданы лимиты. Если там нет, то тогда опять же искать в коде по имени нужных стат и смотреть где в расчетах с ними применяется лимит. Опять же общий класс расчета скорее всего назвается StatFunctions или типа того.

ТС - активные эффекты вобще-то в пассивных скиллах не работают обычно. сделать можно да, но требуется основательная допилка работы со скиллами в ядре. судя по виду хмлки скилла у тебя овер или что-то похожее вот не помню, были ли в оригинальом овере типы триггеров ADD/REMOVE, срабатывающие при добавлении/удалении скилла игроку если есть то на их основе можно сделать - добавить в пассивку триггеры, вызвающие уже вполне нормальные активные скиллы на вызов/отзыв кубика типа так <skill id="80000" levels="7" name="Summon Vampiric Cubic"> <table name="#cubicLevel">1 2 3 4 5 6 7</table> <table name="#magicLevel">43 49 55 60 64 68 72</table> <set name="icon" val="icon.skill0022"/> <set name="magicLevel" val="#magicLevel"/> <set name="target" val="TARGET_SELF"/> <set name="skillType" val="BUFF"/> <set name="operateType" val="OP_PASSIVE"/> <triggers> <trigger id="22" level="#cubicLevel" type="ADD" chance="100" /> </triggers> </skill>

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

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

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

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

Лучше уж "раздутые" хмлки, чем изврат в виде хранения кучи статики в бд

Ну по дефолту иногда вполне может быть поведение что если задействован вариант, который вскоре удалят - завершать работу с предупреждением, чтобы не игнорировали проблему по принципу "потом как нибудь поправлю". Но в данном случае да - это вроде как не должно вызывать закрытие - у себя вот ради интереса на 8 яве вызывал это же самое предупреждение и при этом сервер продолжал нормально запускаться. Кстати с названием параметра попутал - убирать надо если что -XX:+CMSIncrementalMode для исчезновения этого предупреждения.

используется режим сборщика мусора, который в используемой версии явы объявлен устаревшим поправь опции запуска в батнике запуска гейма (вроде как -XX:+UseConcMarkSweepGC), ну или запускай под более старой явой.

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

А вобще есть же те же мастери на копья, которые так же увеличивают количество целей для копья, типа этой <!-- Владение Древковым Оружием / Polearm Mastery --> <skill id="216" levels="45" name="Владение Древковым Оружием"> <table name="#magicLevel">20 24 26 28 30 32 34 36 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74</table> <table name="#pAtk">4.5 7.3 8.9 10.7 12.8 15.1 17.7 20.5 23.7 25.4 27.1 29 30.9 32.9 35 37.1 39.4 41.7 44.1 46.6 49.2 51.9 54.6 57.5 60.4 63.3 66.4 69.5 72.7 76 79.3 82.7 86.1 89.6 93.1 96.6 100.2 103.8 107.5 111.1 114.8 118.4 122.1 125.7 129.3</table> <table name="#targetCount">5 5 5 5 5 5 5 5 10</table> <stat name="icon" value="icon.skill0216" /> <stat name="magicLevel" value="#magicLevel" /> <stat name="target" value="SELF" /> <stat name="skillType" value="BUFF" /> <stat name="operateType" value="OP_PASSIVE" /> <for> <add order="0x40" stat="pAtk" value="#pAtk"> <using kind="Pole" /> </add> <add order="0x40" stat="targetCount" value="#targetCount"> <using kind="Pole" /> </add> </for> </skill> Посмотреть вот как в опентиме эта пассивка описана и сделать по аналогии

Решение - добавить/поправить в пассивку 3599, обычно добавляемую пикам, стату увеличивающую количество одновременно поражаемых целей Если такая стата конечно в опентиме есть, а не тупо захардкодено в ядре количество целей для пики. Ну типа чет такое <!-- Алебарда Мультиатаки / Polearm Multi-attack --> <skill id="3599" levels="1" name="Алебарда Мультиатаки"> <!-- Дает возможность атаковать несколько целей одновременно. --> <stat name="icon" value="icon.skill0216" /> <stat name="magicLevel" value="1" /> <stat name="target" value="SELF" /> <stat name="skillType" value="BUFF" /> <stat name="operateType" value="OP_PASSIVE" /> <for> <add order="0x40" stat="targetCount" value="2"> <using kind="Pole" /> </add> </for> </skill>

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