Gaikotsu

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

объявить для своего инстанса наследный класс от Reflection и делать в нем что хочется - там есть методы onPlayerEnter и onPlayerExit, вызывающиеся при входе и выходе игрока в инстанс. пример инстанса, имеющего свой особый класс - в нем при входе игроку показывают сценку на дивжке игры package instances; import l2p.gameserver.enums.Scene; import l2p.gameserver.model.Player; import l2p.gameserver.model.entity.Reflection; /** * @author Gaikotsu */ public class AdventOfDelusion extends Reflection { @Override public void onPlayerEnter(Player player) { super.onPlayerEnter(player); player.showScene(Scene.BLOODVEIN_OPENING); } } ну и естественно создавать и входить в инстанс с этим самым наследным классом, а не с базовым Reflection, т.е. так к примеру ReflectionUtils.simpleEnterInstancedZone(player, new AdventOfDelusion(), izId); ну а для того, чтобы сразу же при выходе из инстанса убрать игрока из списка посетивших его - надо его удалить из списка _visitors в этом самом методе onPlayerExit _visitors.remove(player.getObjectId());

int izId = reflection.getInstancedZoneId();

а ты уверен что на момент повторной попытки входа старый инстанс у тебя еще существует? т.к. у тебя в его свойствах указано что он уничтожается уже через минуту как его покинули все игроки if(reflection.getName() == "PVP") нельзя так делать, ибо строки в яве на эквивалентность так не сравниваются сравнивать надо так if(reflection.getName().equals("PVP")) или так if(reflection.getName().equalsIgnoreCase("PVP"))

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

не знаю как в лосте, но в оригинальном овере наличие существующего инастанса с заданным izId можно проверить так if (ReflectionManager.getCountByIzId(izId) > 0) System.out.println("found"); ну а вытащить список всех инстансов с заданным izId можно через ArrayList<Reflection> list = ReflectionManager.getAll(izId);

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

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

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

эти методы возвращают объект созданного инстанса - эти объекты храни и с ними и работай, если тебе надо в те же самые инстансы еще кого-то переместить после первого вошедшего в них игрока. каждая созданная копия инстанса имеет свой уникальный reflectionId, с которым и можно манипулировать. например телепортировать в уже существующий инстанс: player.teleToLocation(x, y, z, reflectionId); блин, это же все самые основы... далеко с такими куцыми знаниями программирования ты не уйдешь...

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

ReflectionUtils.simpleEnterInstancedZone(player, izId); или ReflectionUtils.simpleEnterInstancedZone(player, refClass, izId); если инстанс имеет свой класс refClass, наследный от Reflection

Ты что? Некогда же - халявные плюсики ждать не будут.

нестандартный крипт - найди для начала чем криптануто я подозреваю что смарткриптом -

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

лол, в тред ворвался специалист (нет)

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