Gaikotsu

не stackOrder, а stackType

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

Судя по названиям классов с cond-ами ничего подходящего готового нет. Допиши по аналогии с имеющимися - это не сложно. Пример такого cond-а для овера. package l2p.gameserver.stats.conditions; import l2p.gameserver.model.Player; import l2p.gameserver.stats.Env; public class ConditionPlayerClassId extends Condition { private final int[] _classIds; public ConditionPlayerClassId(String[] ids) { _classIds = new int[ids.length]; for (int i = 0; i < ids.length; i++) _classIds[i] = Integer.parseInt(ids[i]); } @Override protected boolean testImpl(Env env) { if (!env.character.isPlayer()) return false; int playerClassId = ((Player) env.character).getActiveClassId(); for (int id : _classIds) if (playerClassId == id) return true; return false; } }

только правкой ядра, классов где идут расчеты дропа.

если про cond-ишны, то таких скиллов наваломвот к примеру

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

значит не записываются корректно в бд данные по добавленым так вещам.

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

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

как вариант в NpcInfo шлется некорректный модификатор для скорости атаки - предполагаю он применяется к анимации атаки, чтобы она успевала визуально воспроизводиться до конца. у меня вот с таким расчетом вроде проблем не было, даже если суммон под гм хастом, т.е. со скоростью атаки в 1500. public final double getAttackSpeedMultiplier() { return 1.1 * getPAtkSpd() / getTemplate().getBasePAtkSpd(); }

проверка некорректна if (enchantScroll.getGrade().extOrdinal() <= item.getGrade().extOrdinal()) { player.sendPacket(EnchantResult.CANCEL); player.sendPacket(SystemMsg.DOES_NOT_FIT_STRENGTHENING_CONDITIONS_OF_THE_SCROLL); player.sendActionFailed(); return; } надо проверять на "не равно" - !=

:рукалицо:

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

player.sendPacket(new InventoryUpdate().addModifiedItem(item)); и все такое

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

вот для кого блин сделаны на форуме тэги спойлера?

под ЛВ подразумевается лостворлд? если да то смотри класс GameObjectTasks в ядре, есть там задача DeleteTask - она подйдет как раз для этого

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

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

А что, в этом вашем акисе нет таких банальных вещей как листенеры на изменение уровня?

это точно - не поможет. в интерлюде, в самих серверных пакетах для передачи количества используется поле d типа, т.е. int 32bit signed и взять и поменять на Q (long) не получится - это испортит структуру пакета и клиент его просто не поймет. с каких хроник стал использоваться long я уже не помню - в ХФ уже он точно есть, в фреее вроде тоже был, а вот насчет грации и ниже уже не помню. таким образом, если вобще ни в жисть но надо сделать, то кроме всех мест где производятся действия с количеством еще и придется в клиенте всю работу с пакетами, в которых задействовано количество вещей, переделывать - править их структуру. оно вам надо, такой гемморой на свою задницу? результат просто не стоит тех усилий, какие придется на это затратить.

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

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

случаем не на этом базирующийся https://github.com/VISTALL/game-updater ?