[mod] DBC_Patcher
При работе с DBC часто выясняется, что данные в них не всегда правильные.
Так как на клиенте во многих случаях достаточно правильно отобразить урон, вероятность и т.д. , то другие параметры заклинаний разработчикам были не важны, их корректности никто не добивался. Т.к. Mangos использует данные DBC как основные, получается что некорректные данные не могут быть "стандартно" реализованы через обработчики эффектов заклинаний , либо требуют отдельного кода для реализации. Некоторые заклинания легко могут быть починены заменой эффектов, значений, масок и т.д. Патч изменяет значения в памяти после загрузки DBC. Размер всех в структуре SpellEntry (DBCStructure.h) кратен 4 байтам, поэтому проще всего патчить типом данных uint32. Патч реализован на уровне идеи, не реализована проверка ошибок. Код:
diff --git a/src/shared/Database/DBCFileLoader.cpp b/src/shared/Database/DBCFileLoader.cpp Код:
CREATE TABLE spell_patch( В патче 3.3.2 перестало работать заклинание 69412 (Abyssal Shatter). По данным spell_works в данных пропал предмет, который создается при использовании Abyssal Shatter. Код:
ID - 69412 Abyssal Shatter () Код:
ID - 69412 Abyssal Shatter () Меняем значение 0 на 49640 по смещению 113. Заклинание начинает работать. Талант Ebon Plaguebringer(51161) вешает дебафф Ebon Plague (51735) который должен увеличивать урон от болезней и от всего магического урона. В заклинании используется спелл 65142, о котором ничего не известно. Код:
ID - 51735 Ebon Plague () Код:
ID - 47865 Curse of the Elements (Rank 5) Код:
ID - 46857 Trauma (Rank 2) |
Мне кажется проще уж тогда просто править DBC.
|
Цитата:
|
Нуу как-бы начнем с того что мы правим их у себя а не в клиенте.
А если уж на то пошло то и извлечение DBC файлов можно подогнать под нарушение лицензии. |
Кроме уже указанных правовых проблем, есть еще и другие сложности. Править DBC не так просто, по крайней мере мне так показалось. При правках нужно будет вести список изменение, чтобы не забыть что и где правилось. Откатить одно изменение будет невозможно. Необходимо будет доставать "чистый" файл и править его заново. Задача мода - свести спелы к уже написанному и работающему коду, чтобы не писать исключения и "хаки" в коде. Хаки тут будут через базу.
|
Код:
В заклинании используется спелл 65142, о котором ничего не известно. |
У Insider42 есть патч. Там вообще таблица имеет полный вид дбц спеллов - ну функциональнее ли он в таком случае?
|
Цитата:
|
Цитата:
|
Цитата:
Заклинание стоит пробовать патчить если: 1. использует\должно использовать уже имеющиеся в ядре эффекты, но некорректно работает из-за того, что в SpellEntry данные не позволяют это делать; 2. не требуются дополнительные проверки, которые необходимо реализовывать в ядре; 3. существуют и нормально работают заклинания(или другие ранги заклинаний) с теми же эффектами, а конкретное не работает. Как я понимаю, основная цель - сделать чтобы заклинание работало как на "оффе". Участники\разработчики проекта mangos решают эту задачу. Разработчики mangosa принимают решение , вписывается ли предложенный вариант реализации в проект. Если реализация понятна, очевидна, то она принимается. Получается, что на этот вопрос каждый раз дают ответ разработчики (MaNGOS Dev). |
Цитата:
added Неправильно понял ваш патч - функциональность таже, но несколько иная реализация - более компактная. Но не учитывает наличие не существующих спеллов, которые можно сделать в патче, что у Инсайдера42. Основная цель вовсе не сделать как на оффе, а обучится коду и коду правильному. Делать правильно. Если бы разработчики просто хотели бы сделать "всё как на оффе" - всё давно было бы сделано хаковыми методами, однако, основная цель проекта - обучающая. Обучающая реализовывать правильно. Ну а вообще - такой мод имеет право на жизнь - расположен там где следует. |
Идея с созданием таблицы для спеллов в базе возникает не первый раз, но в ядро не принимается, что можно расценивать как хаковое решение.
В сниффах приходят спеллы, которых нет в дбц. Возможно, еще больше спеллов не приходят вообще ни в каком виде. Если делать реализацию через базу, то можно установить приоритет на ее стороне, т.е. в первую очередь берутся данные из базы, а потом уже из Spell.dbc. В таком случае можно не плодить однотипный код, когда у спелла есть, например, эффект думми (каст спелла) без каких-либо дополнительных условий или требуется изменить тип цели. Вместо описания думми в ядре можно просто добавить запись в базу с указанием нужного спелла, целей и прочих необходимых параметров. В этом случае можно будет реализовывать не только отсутствующие в дбц спеллы, но и править существующие, если не требуется дополнительная обработка. В свою очередь это принесет не только дополнительные возможности, но и определенные неудобства, т.к. надо будет учитывать приоритетность данных. В любом случае конечное слово за разработчиками ядра. Если они не приняли подобные патчи, значит, не все так просто, как нам кажется. |
Получается , можно изменить и дисплей Ид , и тип силы и все?
|
Можно все, но не все нужно.
|
Текущее время: 19:16. Часовой пояс GMT +3. |
ru-mangos.ru - Русское сообщество MaNGOS