Gaikotsu

исправил

ты вобще не те скиллы показываешь точнее ты показываешь вызваемые скиллами подготовки баффы вот те что нужно pts skill_begin skill_name = [s_battle_stance1] /* [배틀 스탠스] */ skill_id = 426 level = 1 operate_type = CA5 magic_level = 77 special_level = 0 magic_critical_rate = 5 change_skill_id = 0 self_effect = {} effect = {} end_effect = {} tick_interval = 2 attached_skill = {[s_attach_battle_stance1]} operate_cond = {{target_my_party;except_me}} is_magic = 2 is_double = 0 mp_consume2 = 0 mp_consume_tick = 15 cast_range = 400 effective_range = 600 skill_hit_time = 15 skill_cool_time = 0 skill_hit_cancel_time = 0.5 channeling_start = 3.6 reuse_delay = 30 activate_rate = -1 lv_bonus_rate = 0 basic_property = none abnormal_instant = 0 irreplaceable_buff = 0 attribute = {attr_none;0} trait = {trait_none} effect_point = 1 target_type = others affect_scope = single affect_limit = {0;0} next_action = none abnormal_visual_effect = {ave_none} debuff = 0 ride_state = {@ride_none;@ride_strider;@ride_wyvern;@ride_wolf} multi_class = 0 olympiad_use = 1 skill_end skill_begin skill_name = [s_spell_stance1] /* [스펠 스탠스] */ skill_id = 427 level = 1 operate_type = CA5 magic_level = 77 special_level = 0 magic_critical_rate = 5 change_skill_id = 0 self_effect = {} effect = {} end_effect = {} tick_interval = 2 attached_skill = {[s_attach_spell_stance1]} operate_cond = {{target_my_party;except_me}} is_magic = 2 is_double = 0 mp_consume2 = 0 mp_consume_tick = 15 cast_range = 400 effective_range = 600 skill_hit_time = 15 skill_cool_time = 0 skill_hit_cancel_time = 0.5 channeling_start = 3.6 reuse_delay = 30 activate_rate = -1 lv_bonus_rate = 0 basic_property = none abnormal_instant = 0 irreplaceable_buff = 0 attribute = {attr_none;0} trait = {trait_none} effect_point = 1 target_type = others affect_scope = single affect_limit = {0;0} next_action = none abnormal_visual_effect = {ave_none} debuff = 0 ride_state = {@ride_none;@ride_strider;@ride_wyvern;@ride_wolf} multi_class = 0 olympiad_use = 1 skill_end Hide скиллы, накладывающие другие скиллы во время своего произношения. к примеру 426 скилл, через 3.6 секунды (channeling_start = 3.6) после после начала каста с периодичностью в 2 секунды (tick_interval = 2) начинает класть скилл 5104 (attached_skill = {[s_attach_battle_stance1]}) и так пока не кончится время каста. Так же возможно с каждым тиком увеличивает уровень наложенного скилла 5104, но это я не выяснял, т.к. мне это не нужно было - в GoD+ эти скиллы уже не используются.

Ну а что ты хотел то - сравнил древний клиент оригинального интерлюда и клиент классика, по совместительству являющийся клиентом актуальных хроник. Да-да, если ты был не в курсе, то для новых хроник и для классика юзается один и тот же клиент - просто при работе используются разные датники + некоторые карты локаций различаются. Разработка клиента же не стоит на месте - корейцы уже столько свистоперделок понапихали в его графический движок, чтобы он выглядел посовременней, что от оригинального движка UE2, которому, хочу заметить уже больше 10 лет, мало что осталось. И само собой все эти изменения потребляют больше ресурсов компа - притом зачастую намного больше, т.к. вопросами оптимизации работы корейцы то не особо и страдают, к сожалению. И чистить "лишнее" в клиенте особого смысла нет, разве что в целях сам объем клиента чуть уменьшить. А так - если что не используется, то это же просто не грузится в память и т.д., а значит и тормозов вызвать не может. З.Ы. речь в теме надеюсь и правда шла про реальный L2 Classic, а не про сборки/клиент для работы с доисторическим интерлюдом, просто с классическими настройками, без всякого изврата с разными дополнениями.

ну если думать логически, то увернулся = не получил удар = ни к чему и считать эту попытку

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

ну его править только патчингом клиента, притом это все вроде где-то в дллках

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

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

Как вариант в расчетах пути движения мобов в их AI

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

тут добавить что только при условии first == true а для доп проверок в нужный момент, не в начале и не в конце, надо будет завести отдельный таск, запускаемый в момент начала каста и срабатываемый через нужное время и именно в нем проверять эту самую видимость и т.д. ну и прерывать каст там же по необходимости

параметр first в checkTarget - true при проверке в момент начала каста и false при проверке в момент окончания каста просто в методе, в проверке на видимость цели учитывай и этот параметр

эй, а чего адика забыл? без него никак.

несовместимые с друг другом L2Font-e.utx/L2Font-ru.utx и gly-файлы в system - в gly описаны не те размеры текстур с буквами, что есть в наличии, в итоге клиент некорректно нарезает текстуру с шрифтом на отдельные символы

1. Map/HashMap и т.п. 2. есть 3. можешь 4. да как хочешь, к примеру private Location _loc; public void setLoc(Location loc) { _loc = loc; } public Location getLoc() { return _loc; } и не забывай проверять на null значение возвращаемое getLoc, т.к. по умолчанию новосозданный объект равен null.

ну к примеру в стандартном овере/лосте тип инстанса определяется по количеству игроков что могут в него войти, т.е. по данным из хмлки, описывающей свойства этого инстанса - так что обычно достаточно там просто убавить количество до одной пати. но к примеру я у себя давно доработал работу с инстансами в этом плане и у меня инстанс может быть одновременно как для пати, так и для кк, или к примеру для одиночного игрока или пати хотя я вобще хорошо так перелопатил оригинальный оверовский формат хмлок с данными по инстансам -------------------------------------------------------------------------------- --- Описание структуры файлов, описывающих инстансы --- --- Местонахождение: data/instances/*.xml -------------------------------------------------------------------------------- Нода instance: id - идентификатор инстанса. name - название инстанса. Так же может содержать в себе следующие субноды: params, return, teleport, spawns, doors, zones. Субнода params: Содержит в себе субноды param, с атрибутами name и value - название параметра и его значение. Допустимые параметры и их значения: entryType - тип инстанса. Допустимые значения: SOLO - для одного игрока, PARTY - для группы, COMMAND_CHANNEL - для командного канала. Можно перечислить несколько типов через точку с запятой. Если параметр не задан, то он определяется автоматически по параметру "players". Если перечисляется несколько типов входа, то для корректной работы желательно перечислять типы в следующем порядке: COMMAND_CHANNEL, PARTY, SOLO. levels - лимит уровней игроков. Строка вида "minLevel;maxLevel". Если не задан максимальный уровень, то он равен максимально достижимому уровню. Значение по умолчанию - 1;110. players - лимит количества игроков. Строка вида "minCount;maxCount". Если не задано максимальное количество, то оно равно минимальному количеству. Если не задан явно параметр "entryType", то именно от значения этого параметра зависит то, какой тип выставится инстансу (соло, для пати, для КК): минимальное количество равно 1 - соло; минимальное количество от 2 до 7 включительно и максимальное количество не больше 7 - для пати; максимальное количество больше 7 - для КК. Значение по умолчанию - 1;1. timeLimit - лимит времени инстанса, в минутах. Если значение больше 0, то при создании инстанса активируется задача, закрывающая этот инстанс через заданное время. Значение по умолчанию - 0. maxChannels - лимит одновременно существующих инстансов данного вида. Указывает, сколько инстансов этого вида может существовать одновременно на сервере. Значение по умолчанию - 20. collapseIfEmpty - через сколько минут закрыть инстанс, если его покинули все игроки. При значении равном -1 функция отключается. Значение по умолчанию - 0. collapseIfPartyDismiss - через сколько минут закрыть инстанс, если группа игроков, находящаяся в нем, была распущена. При значении равном 0 функция отключается. Значение по умолчанию - 1. collapseIfCommandChannelDismiss - через сколько минут закрыть инстанс, если командный канал игроков, находящихся в нем, был распущен. При значении равном 0 функция отключается. Значение по умолчанию - 0. kickIfDead - через сколько минут выбросить мертвого игрока из инстанса, если его никто за это время не воскресил. При значении равном 0 функция отключается. Значение по умолчанию - 1. dispelBuffs - снимать или нет все баффы с игроков при заходе в инстанс. Значение по умолчанию - false. timerMode - режим показа таймера, находящимся в инстансе игрокам. Допустимые значения: NONE - не показывать время, ELAPSED - прошло времени, REMAINING - осталось времени. Значение по умолчанию - NONE. timerTime - с какого значения, в секундах, начать отсчет времени на таймере. Значение по умолчанию - timeLimit * 60. removeItem - предметы, проверяемые у игроков при попытке входа в инстанс и удаляемые при успешном входе в него. Строка вида "itemId,itemId ... itemId;count;removeType". Если задано несколько разных предметов, то необходимо наличие хотя бы одного из них. Если количество предметов не задано, то оно равно 1. Значение removeType отвечает за то, у кого будут удалены требуемые предметы: 0 - у всех входящих в инстанс; 1 - только у лидера группы/КК. Если значение removeType не задано, то оно равно 0. Значение по умолчанию - 0;0;0. requiredItem - предметы, проверяемые у игроков при попытке входа в инстанс и не удаляемые при входе в него. Строка вида "itemId,itemId ... itemId;count". Если задано несколько разных предметов, то необходимо наличие хотя бы одного из них. Если количество предметов не задано, то оно равно 1. Значение по умолчанию - 0;0. giveItem - предметы, выдаваемые игрокам при входе в инстанс. Строка вида "itemId,itemId ... itemId;count". Если количество предметов не задано, то оно равно 1. Значение по умолчанию - 0;0. geodata - сектор геодаты, в котором находится инстанс. Необходим в инстансах с дверями, т.к. без указания сектора в таком инстансе будут проблемы с проходом через открытые двери. Значение по умолчанию - сектор не задан. requiredQuestId - идентификатор начатого или выполненного квеста, который должен быть у игрока для входа в инстанс. При значении равном 0 наличие квеста не проверяется. Значение по умолчанию - 0. onlyStartedQuest - дополнительное условие для предыдущего параметра. Если равно true, то проверяются только начатые квесты. Значение по умолчанию - true. resetReuse - ближайшее время, в которое сбрасывается ограничение на вход в инстанс. Задается строкой в формате Cron. Значение по умолчанию - "* * * * *" (можно сразу же повторно зайти в инстанс). setReuseUponEntry - устанавливать или нет реюз при входе в инстанс. Если значение равно false, то реюз по необходимости необходимо выставлять игрокам вручную. Значение по умолчанию - true. sharedReuseGroup - общая группа реюза. У всех инстансов с одинаковой группой, со значением больше 0, будет выставляться одинаковый реюз. Значение по умолчанию - 0. removeVisitor - Удалять или нет вышедшего из инстанса игрока из списка посетивших этот инстанс. Может пригодиться для статичных инстансов, которые существуют после создания до выключения сервера. Значение по умолчанию - false. Кроме того, можно задавать и свои параметры, читая их потом через метод getParams() инстанса. Для параметров removeItem и requiredItem, кроме обычных предметов можно так же указывать очки PC Cafe (-100), славу (-300) и рейдовые очки (-500) - в скобках указаны их идентификаторы. Субнода return: loc - координаты, в которые перемещаются игроки при закрытии инстанса или выходе через SOE/смерть. Субнода teleport (можно задавать несколько таких субнод): loc - координаты, в которые перемещаются игроки при телепорте в инстанс. Субнода spawns: Может содержать в себе субноды group и spawn. Субнода group может иметь следующие атрибуты: name - название группы спавна. spawned - должна ли группа спавнится сразу же после создания инстанса. Значение по умолчанию - false. Субнода spawn может иметь следующие атрибуты: id - идентификаторы нпс. Строка вида "npcId;npcId ... npcId". count - количество нпс для спавна. Значение по умолчанию - 1. respawn - время респавна в секундах. При значении равном 0 респавн отключается. Значение по умолчанию - 0. respawnRnd - разброс времени респавна в секундах. Значение по умолчанию - 0. type - тип спавна. Может принимать следующие значения: 0 - точечный, в каждой указанной точке; 1 - один точечный спаун в рандомной точке; 2 - локационный. Значение по умолчанию - 0. Так же данная субнода имеет субноды coords, в которых описываются точки спавна или территория, внутри которой будут заспавлены нпс. Субнода doors: Может содержать в себе субноды door, описывающие двери в инстансе. Субнода door может иметь следующие атрибуты: id - идентификатор двери. opened - начальное состояние двери. При значении равном true - открыта. Значение по умолчанию - false. invul - неуязвима или нет дверь. Значение по умолчанию - true. Субнода zones: Может содержать в себе субноды zone, описывающие зоны в инстансе. Субнода zone может иметь следующие атрибуты: name - название зоны. active - начальное состояние зоны. Значение по умолчанию - false. Скрыть

если ты объявляешь их в датапаке, то из ядра будет достаточно сложно к ним обратиться. вобще, можешь сделать листенер на запрос воскрешения, зарегать в своем эвенте и дергать его в RequestRestartPoint т.е. первым делом дергается листенер и если он не отработал (обработка должна возвращать к примеру true/false как признак того что что-то сделано/не сделано), то только тогда обрабатываются стандартные варианты воскрешения. еще как вариант, заведи в классе Player сессионные переменные, в которых можно будет хранить любые данные до перезахода в игру - чисто в памяти, без сохранения в бд. т.е. по сути аналог кукисов в вебе - таким образом можно будет обмениваться любыми данными между датапаком и ядром. сделать это в виде обычной мапы <String, String> или <String, Object> к примеру. и вот туда можешь к примеру положить координаты, а потом в любое время взять обратно по ключу мапы. для примера, моя реализация сессионных переменных /** * -------------------------------------------------- * Работа с временными переменными, хранящимися в памяти и удаляющимися при выходе игрока из игры * -------------------------------------------------- */ private final Map<String, String> _sessionVars = new ConcurrentHashMap<>(); public Map<String, String> getSessionVars() { return _sessionVars; } public String getSessionVar(String name) { return _sessionVars.get(name); } public String getSessionVar(String name, String def) { String val = getSessionVar(name); return val != null && !val.isEmpty() ? val : def; } public int getSessionVar(String name, int def) { String val = getSessionVar(name, null); return val != null ? Integer.parseInt(val) : def; } public long getSessionVar(String name, long def) { String val = getSessionVar(name, null); return val != null ? Long.parseLong(val) : def; } public double getSessionVar(String name, double def) { String val = getSessionVar(name, null); return val != null ? Double.parseDouble(val) : def; } public boolean getSessionVar(String name, boolean def) { String val = getSessionVar(name, null); return val != null ? !val.equalsIgnoreCase("false") : def; } public void setSessionVar(String name, String val) { _sessionVars.put(name, val); } public void setSessionVar(String name, int val) { setSessionVar(name, Integer.toString(val)); } public void setSessionVar(String name, long val) { setSessionVar(name, Long.toString(val)); } public void setSessionVar(String name, double val) { setSessionVar(name, Double.toString(val)); } public void setSessionVar(String name, boolean val) { setSessionVar(name, Boolean.toString(val)); } public void unsetSessionVar(String... names) { for (String name : names) _sessionVars.remove(name); } вобщем по сути аналог стандартных setVar/getVar, просто без работы с бд.

добавить свою обработку воскрешения и перемещения в пакет RequestRestartPoint ну или сделать проще - если игрок в режиме участия в пвп-эвенте, то вобще игнорировать от него запросы на воскрешение, а просто ресать самому с определенной задержкой. вот к примеру у меня в эвенте Team DeathMatch так сделано @Override public void onKill(Creature actor, Creature victim) { if (actor == null || victim == null || getStatus() != EventStatus.BATTLE || actor.getPlayer() == null || !victim.isPlayer()) return; EventMember killer = getMember(actor.getPlayer()); EventMember killed = getMember(victim.getPlayer()); if (killer == null || killed == null || killer == killed || killer.getPlayer() == null || killed.getPlayer() == null || killer.getTeam() == killed.getTeam()) return; if (killer.getTeam() == TeamType.RED) { incScore(TeamType.RED, getConfig().getPointsGive()); decScore(TeamType.BLUE, getConfig().getPointsLose()); } else { incScore(TeamType.BLUE, getConfig().getPointsGive()); decScore(TeamType.RED, getConfig().getPointsLose()); } addRewards(killer.getPlayer(), ActionType.KILL); ThreadPoolManager.getInstance().schedule(new PvPEventTasks.ActionTask(this, killed.getPlayer(), ActionTaskType.REVIVE_AND_BUFF), getConfig().getTimeToRevive() * 1000L); showMessage(killed.getPlayer(), "Вас убили. Через несколько секунд вы будете возрождены."); if (getConfig().getPointsCount() > 0 && (getScore(TeamType.RED) >= getConfig().getPointsCount() || getScore(TeamType.BLUE) >= getConfig().getPointsCount())) endBattle(); } вот эта строчка ThreadPoolManager.getInstance().schedule(new PvPEventTasks.ActionTask(this, killed.getPlayer(), ActionTaskType.REVIVE_AND_BUFF), getConfig().getTimeToRevive() * 1000L); указывает что надо через определенное время после смерти воскресить (с перемещением в заданную точку) и бафнуть З.Ы. onKill - это из листенера OnKillListener, так что само собой надо этот листенер объявлять и регистрировать у участников в начале боя, а в конце убирать обратно.

ну дак это все как раз и проверяется в выше указанном методе и связанных если хочешь реализовать свою привязку к командам, то тебе и надо добавлять в этот и другие методы на эту тему свои проверки именно твоей привязки. вот к примеру у меня как идут проверки на эту тему в методе isCtrlAttackable класса Playable (у меня не лост, а овер, но это по сути то же самое - просто чуток более старое) if (player.getPvPEventMode() > 0 || pcAttacker.getPvPEventMode() > 0) { if (player.getPvPEventMode() != pcAttacker.getPvPEventMode()) return false; if (player.getPvPEventMode() == 2 && player.getTeam() == pcAttacker.getTeam()) return false; } метода getPvPEventMode() в стандартном овере нет (это я у себя уже вводил для разных проверок по аналогии с методом isInOlympiadMode()), но думаю сам смысл этих проверок тебе понятен. тут у меня проверяется что если атакующий или атакуемый в данный момент учатсвуют в пвп-эвенте, то: - если участвует только один из них - атаковать нельзя - если пвп-эвент отрядный и атакующий и атакуемый в одном отряде - атаковать нельзя подобные проверки имеются так же и в методе checkTarget класса Skill, чтобы во время эвента нельзя было кастовать плохие скиллы на свою команду и бафать/лечить чужую команду.

проверки возможности атаковать, находятся в ядре - метод isAttackable в Playable и т.п. вот туда и пихать свои доп. проверки на возможность атаки цели

в датапаке, в scripts/npc/model/ есть целая куча персональных классов-инстансов для определенных неписей, так что примеров тебе там целую кучу найти можно

это происходит из-за того, что onPlayerEnter вызывается как раз в процессе телепорта в инстанс и само собой в то же время еще раз телепортироваться нельзя. можешь раскидывать по командам и перемещать на требуемые координаты с определенной задержкой, запуская задачу с этим в onPlayerEnter к примеру так - действия через 5 секунд после входа ThreadPoolManager.getInstance().schedule(new RunnableImpl() { @Override public void runImpl() throws Exception { // здесь назначаем команду и делаем телепорт } }, 5000); но вобще по уму надо сделать так как я выше писал - для телепортирующего в инстанс непися объявить свой инстанс и в нем обрабатывая байпас на вход перед самим входом обрабатывать игроков - давать им нужный отряд и задавать куда их телепортировать, в какие координаты.

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

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

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