Gaikotsu

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

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

вобще результат расчетов в моем коде - это целое число от 0 до 4, т.к. в пхп тут производится неявное приведение типов к целому типу

<? $x = 2.5; $x = $x % 5; if ($x >= 0 && $x <= 2) echo "Green\n"; else if ($x == 3) echo "Yellow\n"; else echo "Red\n"; ?> набросаный за минуту простейший код на похапе на нужный язык уж сам переведешь, добавив ввод данных и т.д.

2TC: покопайся на форуме руоффа - там выкладывали таблицу с лимитами многих параметров. данные конечно от ГоД, но как основа сойдут. ссылку на тему там к сожалению не помню

Блин, я вот даже хз что написать, если тс даже не понял что скачал и поставил себе IPB с внедренной дырой (шеллом) через который его может поиметь любой желающий, и еще и спрашивает " что мне делать то?"... что делать, что делать? найти и снести нахрен этот шелл...

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

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

ему нужно вводить новый тип срабатывания, что-то типа ON_AFTER_CASTED/ON_AFTER_ATTACKED, вызываемый после каста скилла/атаки, а не перед ними. по сути если есть исходники ядра, то это реализуется в 2-3 строки - если конечно там хоть сколько-то вменяемая реализация триггеров.. Просто я хз как там с этим в люцере, но в том же овере добавление обработки нового триггера реально реализуется добавлением всего 2 новых строк в ядро - добавить в энум, с перечислением всех типов триггеров, новый тип триггера и в нужное место воткнуть строку с его вызовом. и все.