Gaikotsu

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

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