Gaikotsu

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

Чисто вот как пример - 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); } } }

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

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

initial_delay - через сколько тиков после входа в зону в первый раз проверять наличие скилла на игроке unit_tick - с какой периодичностью в тиках проверять наличие скилла на игроке в зоне skill_prob - шанс наложения скилла при проверках выше тики могут быть разной длительности, в зависимости от сборки, но в основном используется период в 1с, но может быть и более близкий к оффу 666мс. --- Ну и наложение с снятием при выходе лучше всего делать через листенер, навешанный на нужные зоны и именно в нем делать наложение/снятие скилла при входе/выходе. Ну или вот как раз доработать, при наличии исходников ядра, обработку зон типа instant_skill, чтобы снимали скиллы наложенные при выходе из зоны

По моему в большинстве сборок такое "из коробки" не существует - есть обычно только вариант с переносом заточки один в один. Мне в свое время на овере такое пришлось самому дописывать, когда я решил сделать обмен футболок (ольф и т.д.) +8/+9 на футболки +10 через мультиселл. В целом там доработок требуется не сильно много, но само собой сделать их можно только если есть исходники. Работает кстати тоже через задание доп. параметров при обмене, типа так, т.е. если для ингредиента задан параметр "enchant" не равный 0, то в список попадают только те предметы у которых энчант не меньше и не больше заданного диапазона. а если этот параметр задан для продукции, то само собой выдается именно с заданным энчантом. <list> <config show_all="false" no_tax="true" npc_id="32378" /> <item> <ingredient id="21706" count="1" enchant="8;9" /> <!-- Футболка Ольфа [Ивент] / Power Shirt [Event] --> <ingredient id="57" count="500000000" /> <!-- Адены / Adena --> <production id="21706" count="1" enchant="10" /> <!-- Футболка Ольфа [Ивент] / Power Shirt [Event] --> </item> <item> <ingredient id="21580" count="1" enchant="8;9" /> <!-- Футболка Ольфа / Power Shirt --> <ingredient id="57" count="500000000" /> <!-- Адены / Adena --> <production id="21580" count="1" enchant="10" /> <!-- Футболка Ольфа / Power Shirt --> </item> <item> <ingredient id="23085" count="1" enchant="8;9" /> <!-- Футболка Ольфа [Ивент] / Power Shirt [Event] --> <ingredient id="57" count="500000000" /> <!-- Адены / Adena --> <production id="23085" count="1" enchant="10" /> <!-- Футболка Ольфа [Ивент] / Power Shirt [Event] --> </item> <item> <ingredient id="34732" count="1" enchant="8;9" /> <!-- Обменянная Футболка Ольфа / Exchanged Power Shirt --> <ingredient id="57" count="500000000" /> <!-- Адены / Adena --> <production id="34732" count="1" enchant="10" /> <!-- Обменянная Футболка Ольфа / Exchanged Power Shirt --> </item> <item> <ingredient id="37718" count="1" enchant="8;9" /> <!-- Сияющая Футболка Эйнхасад / Shiny Elemental Shirt --> <ingredient id="37723" count="1" /> <!-- Камень для Обмена Футболки / Shiny Elemental Shirt Exchange Stone --> <ingredient id="57" count="1000000000" /> <!-- Адены / Adena --> <production id="37718" count="1" enchant="10" /> <!-- Сияющая Футболка Эйнхасад / Shiny Elemental Shirt --> </item> <item> <ingredient id="46193" count="1" enchant="8;9" /> <!-- Футболка Отражения Атаки / Physical Reflect Shirt --> <ingredient id="37723" count="1" /> <!-- Камень для Обмена Футболки / Shiny Elemental Shirt Exchange Stone --> <ingredient id="57" count="1000000000" /> <!-- Адены / Adena --> <production id="46193" count="1" enchant="10" /> <!-- Футболка Отражения Атаки / Physical Reflect Shirt --> </item> <item> <ingredient id="46194" count="1" enchant="8;9" /> <!-- Футболка Отражения Магии / Magical Reflect Shirt --> <ingredient id="37723" count="1" /> <!-- Камень для Обмена Футболки / Shiny Elemental Shirt Exchange Stone --> <ingredient id="57" count="1000000000" /> <!-- Адены / Adena --> <production id="46194" count="1" enchant="10" /> <!-- Футболка Отражения Магии / Magical Reflect Shirt --> </item> </list>

это что за пипец такой? я надеюсь это просто так коряво декомпильнуло и в реальности нет такой жести в плане свитча по всем значениям от 1 до 99?

просто погугли по "режим отладки eclipse" или "режим отладки idea", в зависимости от того какое IDE думаешь использовать но для начала научись хотя бы основам работы с проектом в IDE, а это все уже потом

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

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

копать отсюда и далее if (getSubPledgeMembersCount(pledgeType) >= getMaxNrOfMembers(pledgeType))

А более элегантного решения не нашлось? К примеру юзать скиллы требующие мало хп разрешить юзать при любом уровне хп, но добавить в эти скиллы эффект снижения при касте этого самого хп до нужного процента, если он выше. Это бы выглядело более адекватно, как будто скилл кроме мп и хп для заюза потребляет, а в реализации не так уж и сложно...

Господи... какими только извращениями народ не страдает - уже и хп сбивать дестру войседами...

Может потому что не может найти указанных методов/классов? нэ?

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

в хмлках описывающих скиллы, как пример

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

параметр "activateRate" в конкретном скилле, иногда еще бывает назвается "chance"

1. потому что тэг button не поддеривает атрибут msg 2. если под диалогом подразумевается диалог с каким-то текстом и с кнопками "да"/"нет", то его можно показать при помощи серверного пакета ConfirmDlg и обработать ответ от него в одноименном клиентском пакете

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

ну я всвое время с офф скриптов и спарсил себе данные из freewayinfo + superpointinfo в хмлку со всеми маршрутами и его и юзаю для нпс/мобов

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

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

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

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