Gaikotsu

значит ковыряй скилтайп SWEEP если конечно исходники ядра есть

ну если в сервере есть поддержка таких кондишнов, то почему нет то?

радиус срабатывания то не забываешь указать?

комбинируй при помощи логических условий and, not, or. ну что-то типа такого - могут одеть только персонажи женского пола, профессии которых не указаны в списке classId <cond msgId="ид сообщения из systemmsg-e.dat"> <and> <not> <player classId="Профессии которым нельзя одеть" /> </not> <player sex="FEMALE" /> </and> </cond>

ну если есть описания в хмлках, то наверняка есть возможность задавать кондишны, типа таких к примеру (в примере указывается что можно использовать только заданным классам) <cond msgId="113"> <player classId="88,114,152,153,154,155,156,157" /> </cond> необязательно так может кондишн называться в твоей сборке. если мне память не изменяет то статы и т.п. вещам можно задавать в хмлках находящихся в data/stats/

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

по оффу - это нормально распарсенный и расписанный option_data и работа именно с ним уже, как в овере к примеру. к тому же большую часть этих данных можно взять из птс скриптов фрейи (файлик optiondata.txt), а в дальнейшем туда не так уж много было добавлено - остатки записей можно и вручную внести. ща вот смотрю - в optiondata.txt от фрейи записи до ид 24964, в клиентском файле OptionData_Client-e от хф записи до 24985, т.е. по сути просто распарсить optiondata.txt фрейи и потом вручную добавить еще 21 запись и все. а те файлы, что ты выложил - это большей частью костыли, работа с которыми уже фиг знает сколько времени кочует из сборки в сборку почти без изменений. я вот на днях серьезно как раз этим делом занимался и в итоге вобще почти все эти файлы просто удалил за ненадобностью, остался лишь skills map, да и то в сильно усеченном и упрощенном виде.

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

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

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

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

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

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

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

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

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

в датапаке, ищи хмлки с описаниями скиллов и там меняй.

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

зависит от сборкигде-то группы есть чисто формально - они есть, но распределение шансов в них сделано не по оффу - они лишь отвечают за то чтобы с моба падало не больше одного вида предмета из каждой группы и ничего более. где-то группы есть и работают именно так как они работают на оффе - к примеру так в овере и в производных от овера сборках. вот пример правильного дропа с группами <!-- Wilderness Protector / Дикий Хранитель --> <npc id="23353" name="Wilderness Protector" title=""> <rewardlist type="RATED_GROUPED"> <group id="1" chance="70.00000"> <reward item_id="57" min="2853" max="6656" chance="100.00000" /> <!-- [70.00000%] Adena / Адена --> </group> <group id="2" chance="5.35000"> <reward item_id="36557" min="1" max="1" chance="84.11215" /> <!-- [4.50000%] Accessory Gem / Самоцвет для Аксессуара --> <reward item_id="36558" min="1" max="1" chance="15.88785" /> <!-- [0.85000% | 1/118] Accessory Gem (Mid-grade) / Самоцвет для Аксессуара Среднего Качества --> </group> <group id="3" chance="1.01200"> <reward item_id="36759" min="1" max="1" chance="49.40711" /> <!-- [0.50000% | 1/200] Recipe: Immortal Sigil (60%) / Рецепт: Символ Бессмертия (60%) --> <reward item_id="36748" min="1" max="1" chance="49.40711" /> <!-- [0.50000% | 1/200] Recipe: Immortal Shield (60%) / Рецепт: Щит Бессмертия (60%) --> <reward item_id="36918" min="1" max="1" chance="0.59289" /> <!-- [0.00600% | 1/16667] Recipe: Weapon Fragment (Mid-grade) - Upgrade / Рецепт: Фрагмент Оружия Среднего Качества - Повышение --> <reward item_id="36907" min="1" max="1" chance="0.29644" /> <!-- [0.00300% | 1/33333] Recipe: Adamantite Wire - Upgrade / Рецепт: Адамантитовый Трос - Повышение --> <reward item_id="36867" min="1" max="1" chance="0.29644" /> <!-- [0.00300% | 1/33333] Recipe: Adamantite - Downgrade / Рецепт: Адамантит - Понижение --> </group> <group id="4" chance="0.27500"> <reward item_id="9549" min="1" max="1" chance="90.90909" /> <!-- [0.25000% | 1/400] Wind Stone / Руда Ветра --> <reward item_id="9555" min="1" max="1" chance="9.09091" /> <!-- [0.02500% | 1/4000] Wind Crystal / Кристалл Ветра --> </group> </rewardlist> <rewardlist type="SWEEP"> <reward item_id="36517" min="1" max="1" chance="65.70000" /> <!-- [65.70000%] Leather / Кожа --> <reward item_id="36518" min="1" max="1" chance="13.12000" /> <!-- [13.12000%] Durable Leather / Толстая Кожа --> <reward item_id="36884" min="1" max="1" chance="0.30000" /> <!-- [0.30000% | 1/333] Recipe: Synthetic Braid - Upgrade / Рецепт: Синтетическая Веревка - Повышение --> <reward item_id="36883" min="1" max="1" chance="0.30000" /> <!-- [0.30000% | 1/333] Recipe: Synthetic Braid - Downgrade / Рецепт: Синтетическая Веревка - Понижение --> </rewardlist> </npc>

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

я правильно понял - геймсерверу выделены всего навесго жалкие полгига памяти?

делать разные стэктайпы для этих скиллов

dropChance = dropChance % L2DropData.MAX_CHANCE; в результате остается остаток от деления dropChance на L2DropData.MAX_CHANCE dropChance = Math.round(dropChance); просто отбрасывается вся не целая часть. если хочется получить ближайшее большее или меньшее целое число, то используй Math.floor или Math.ceil

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

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