Gaikotsu

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

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

Это тупо серверный пакет 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 или т.п.? А то для антивируса обычно это еще один довод на тему того что это что-то подозрительное.

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

Сборка не указана нифига, так что хз как у ТСа. Но в многих сборках то что зарегано на шорткатах у новосозданного перса тупо захардкодено в пакете CharacterCreate. И да - это в ядре если что, так что без исходников никак. У меня у самого это все вынесено в дп в виде хмл и легко настраиваемо, но мало кто на такое заморачивается ради такой мелочи.

ну кто так темы называет? У меня при первом взгляде на ее название была мысля "как связаны птичья задница и все сопутствующее с линейкой?"

В самом простом варианте: 1. добавляешь 3-й элемент в описания того что можно получть, т.е. - ид, количество, шанс 2. перед user.getPlayer().addItem(...), добавляешь if (Rnd.chance(pair[2])) [не забудь в импорты прописать класс с Rnd, хз где он там у тебя в сборке] Если же хочется более вменяемой распаковки, т.е. сумма шансов получаемых предметов равна 100%, можно гарантировано всегда получить только один из предметов, соответственно его шансу - то такой вариант потребует более основательных правок.

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