Gaikotsu

Так вроде по простой логике делать: - для первой вариэйшн делаешь одну группу с шансом 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%, можно гарантировано всегда получить только один из предметов, соответственно его шансу - то такой вариант потребует более основательных правок.

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

Может изменили просто формат отдаваемых серверу данных.

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

Речь про то чтобы в коммунке выводить информацию прохождении квестов, с ссылками в нужные локации что ли?

Чисто вот как пример - AI для нпс, на время своего существования создающий вокруг себя круглую зону с листенером, который при входе в эту зону вешает определенный скилл, а при выходе - снимает его. Я таких нпс юзаю для работы тотемов дающих бафф, ну тех что можно юзать у Антараса/Валакаса. package ai; import l2p.commons.collections.StatsSet; import l2p.commons.geometry.Circle; import l2p.gameserver.ai.DefaultAI; import l2p.gameserver.data.holder.SkillHolder; import l2p.gameserver.enums.ZoneType; import l2p.gameserver.holders.world.ZoneTemplate; import l2p.gameserver.listener.zone.OnZoneEnterLeaveListener; import l2p.gameserver.model.Creature; import l2p.gameserver.model.Territory; import l2p.gameserver.model.World; import l2p.gameserver.model.Zone; import l2p.gameserver.model.instances.NpcInstance; import l2p.gameserver.model.skills.Skill; import l2p.gameserver.utils.Strings; /** * AI, создающее на время круглую зону, при вхождении в которую на игроков накладывается заданное умение, а при выходе - снимается. * Радиус зоны берется из накладываемого умения. * * @author Gaikotsu */ public class CastSkillZone extends DefaultAI { private Skill _skill = null; private Zone _zone = null; private ZoneListener _listener = null; public CastSkillZone(NpcInstance actor) { super(actor); } @Override public boolean isGlobalAI() { return true; } @Override protected void onEvtSpawn() { super.onEvtSpawn(); NpcInstance actor = getActor(); i_ai0 = actor.getParameter("lifeTime", 0); i_ai1 = actor.getParameter("castPeriod", 0); addTimer(1001, i_ai0 * 1000L); addTimer(1002, i_ai1 * 1000L); String[] skill = actor.getParameter("castSkill", "0,0").split(","); if (skill.length != 2) return; _skill = SkillHolder.getInstance().getSkill(Integer.valueOf(skill[0]), Integer.valueOf(skill[1])); if (_skill == null) return; int radius = _skill.getAffectRange(); Circle c = new Circle(actor.getLoc(), radius); int z = actor.getLoc().getZ(); c.setMaxZ(z + radius); c.setMinZ(z - radius); StatsSet set = new StatsSet(); set.set("name", Strings.EMPTY); set.set("type", ZoneType.dummy); set.set("territory", new Territory().add(c)); _listener = new ZoneListener(); _zone = new Zone(new ZoneTemplate(set)); _zone.setReflection(actor.getReflection()); _zone.addListener(_listener); _zone.setActive(true); } @Override public void onEvtDespawn() { super.onEvtDespawn(); _zone.setActive(false); _zone.removeListener(_listener); _zone = null; } @Override protected void onEvtTimer(int timerId, Object arg1, Object arg2) { NpcInstance actor = getActor(); if (actor == null) return; if (timerId == 1001) { actor.deleteMe(); } else if (timerId == 1002) { if (_skill == null) return; World.getAroundPlayables(actor, _skill.getAffectRange(), _skill.getAffectRange()).stream().filter(cha -> cha != null && !cha.isDead()).forEach(cha -> _skill.getEffects(actor, cha, false)); addTimer(1002, i_ai1 * 1000L); } } private class ZoneListener implements OnZoneEnterLeaveListener { @Override public void onEnter(Zone zone, Creature actor) { if (!actor.isPlayable()) return; if (actor.getEffectList().checkEffectsBySkill(_skill)) return; _skill.getEffects(getActor(), actor, false); } @Override public void onLeave(Zone zone, Creature actor) { if (!actor.isPlayable()) return; if (!actor.getEffectList().checkEffectsBySkill(_skill)) return; actor.getEffectList().stopEffect(_skill); } } }

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