Gaikotsu

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

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

кондишн на уровень в свойствах вещи и всея хз что у тебя за сборка, но в овероподобных это будет выглядеть например так - вот пример вещи, которую можно одеть только если основной класс и дуал класс игрока не ниже 87: <!-- Rising Shirt / Рубаха Восхода --> <armor id="36187" name="Rising Shirt"> <!-- Increases Speed by 7, STR by 1, and INT by 1. Can be used if the levels of main and dual classes are 87 or higher. Cannot be exchanged, dropped, or enchanted. --> <!-- Скорость +7, СИЛ +1, ИНТ +1. Можно носить, если основной и двойной классы выше 87-го уровня. Нельзя обменять/выбросить/модифицировать. --> <set name="icon" value="icon.dual_shirt1" /> <set name="type" value="NONE" /> <set name="ex_type" value="UNDERWEAR" /> <set name="crystal_type" value="NONE" /> <set name="weight" value="130" /> <set name="price" value="0" /> <set name="destroyable" value="true" /> <set name="dropable" value="false" /> <set name="sellable" value="false" /> <set name="tradeable" value="false" /> <cond msgId="113" addName="1"> <player dualLevel="87;87" /> </cond> <skills> <skill id="13409" level="1" /> <!-- Rising Shirt / Рубаха Восхода --> </skills> <equip> <slot id="UNDERWEAR" /> </equip> <for> <add stat="pDef" order="0x10" value="38" /> <enchant stat="pDef" order="0x0C" value="0" /> <enchant stat="maxHp" order="0x80" value="0" /> </for> </armor>

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

причем тут вобще JS?

ну для начала для вставки аугментации в оружие использовать не прямую запись в бд, а метод, который используется в обычной вставке ауги у кузнеца. не знаю как в твоей сборке он называется.к примеру в сервере на базе овера это делается так item.setAugmentation(augId1 * 65536 + augId2)); item.setJdbcState(JdbcEntityState.UPDATED); item.update(); во воторых, не стоит передавать напрямую в байпассе ид аугментаций и скиллы - слишком это уязвимо. лучше завести массив с ними, а в байпассе передавать нужный индекс из этого массива и по нему брать из этого массива нужные данные.

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

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

ИМХО самый качественный декомпил получается после декомпила при помощи Fernflower. Я к примеру его самого им декомпилил (да, да - он сам тоже на яве написан) и после мелкой правки одного класса (мелкая ошибка, из-за которой Fernflower некорректно обрабатывал некоторые вложенные классы) обратно компилил без всяких проблем. Но в любом случае будут искажения кода - невозможно получить при декомпиле код, идентичный тому что был изначально, разве что код был вообще примитивен с самого начала.

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

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

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

а код то обрабатывающий эти данные вобще в серве есть?

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

Ну ща то бесполезно уже что-то доказывать. Даже если и был изначально трой в проге, то почти 100% сейчас в ней его нет - файл заменить то если что недолго.

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

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

Не CharacterSelected, а RequestEx2ndPasswordCheck, RequestEx2ndPasswordReq и RequestEx2ndPasswordVerify. Ну и еще несколько серверных пакетов.

еще по другому можно спавнить, просто выбирая случайный спавн из всех имеющихся, т.е. тех где спавнятся любые монстры. сэмпл public static Location getRandomSpawnPoint() { ArrayList<Spawner> _spawns = new ArrayList<Spawner>(); for (Spawner spawn : SpawnManager.getInstance().getSpawners(PeriodOfDay.NONE.name())) { if (spawn.getReflection() != ReflectionManager.DEFAULT) continue; NpcInstance npc = spawn.getLastSpawn(); if (npc == null || !npc.isMonster() || npc.getLoc().getX() < -166168) continue; if (npc.isInZone(ZoneType.peace_zone) || npc.isInZone(ZoneType.siege) || npc.isInZone(ZoneType.water) || npc.isInZone(ZoneType.epic) || npc.isInZone(ZoneType.ssq_zone)) continue; _spawns.add(spawn); } Spawner _spawn = _spawns.get(Rnd.get(_spawns.size())); return _spawn.getCurrentSpawnRange().getRandomLoc(ReflectionManager.DEFAULT.getGeoIndex()); }

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

вполне логично что стэктайпы должны быть одинаковы или же содержать в списке стэктайпов одинаковый тип к примеру Harmony_of_Guardian;Harmony и Harmony_of_Berserk;Harmony

в самом тексте ошибки уже подсказка есть, так что как можно не решить то? ясно же написано что в таблице откуда считываются данные нет ожидаемого столбца access_level

ну значит по какой-то причине не броадкастится (или броадкастится не с теми параметрами) MagicSkillUse в нужных местах с информацией о том что скилл был скастован на такие-то цели - именно он отвечает за показ анимации.

на кого кастуется - вокруг того и будет анимация

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