База данных IDA от void17

Работа над NH3API продолжается.
Теперь контейнеры поддерживают стандартные алгоритмы (<algorithm>) каждого из поддерживаемых компиляторов.
Добавлены макросы для поддержки легаси-кода(такие как PtrAt, MemCpy, _dword_ и прочие)
Релиз будет со дня на день.

Пока я готовлюсь к релизу, опишу нововведения, которые ждут вас в NH3API:
1. Сегодня добавил в patcher_x86.hpp "новый" вид хуков - jmp-лоухук, JmpHook. Интерфейс примерно такой:

Код: Выделить всё

// Сид RMG всегда будет = 1337.
CREATE_JH(JH_SetRandomSeed1337, edi, { mov eax, 1337 }); 
  // ... //
 p->WriteJmpHook(0x53662C, 0x536637, JH_SetRandomSeed1337);

По-сути это аналог WriteAsmHook, но чуть быстрее при инициализации Patcher-a.
Особенность в том, что он супербыстрый и меняет только те регистры, которые нужны. Таким образом его очень хорошо вставить, например, в цикл. Обычный лоухук будет долго сохранять старые регистры а потом восстанавливать, и все ради буквально одного изменения регистра. Это можно теперь избежать.. Для небольших изменений в коде jmp-лоухук подходит идеально.

2. Поддержка трёх компиляторов.
Планируется поддержка всех версий Microsoft Visual C++ начиная от VS 2008. А так же MinGW-w64 и Clang.
Таким образом это в т.ч. и поддержка стандартов от C++98 до C++23.

3. Поддержка легаси-кода. Те самые воговские макросы _dword_, _ptr_, MemCopy, MemZero будут в положении deprecated, но всё ещё будут поддерживаться.

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

5. Отсутствие .cpp файлов. Для кого-то это плюс. Тем не менее, для удобной интеграции NH3API с вашими проектами с разными библиотеками это хорошо.

6. Скорее всего, я сделаю многие функции weak-символами. Таким образом можно будет их переписывать в своём проекте и не трогать исходники NH3API.

7. Удобный интерфейс в отношении работы с функциями экзешника. К сожалению для сохранения обратной совместимости с C++98 CALL_ макросы придется оставить, но в NH3API уже будут многие функции, необходимые для удобной разработки мода. Так, например, ключевые функции по типу operator new, operator delete, atexit будут иметь приставку exe_

Цитата:

Таким образом это в т.ч. и поддержка стандартов от C++98 до C++23.

Хватило бы и одного C++98. Остальное - QoL или - в простонародье - плюшки. Поясню: потенциальный автор плагинов - это не профессиональный программер и, вероятно, не программер по образованию. Теоретически это, конечно, здорово.

Цитата:

3. Поддержка легаси-кода. Те самые воговские макросы _dword_, _ptr_, MemCopy, MemZero будут в положении deprecated, но всё ещё будут поддерживаться.

Вот это важно, ибо весь код популярных плагинов писался на homm3.h. Будет здорово, если он "заведётся" с минимальными правками.

Цитата:

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

Плюс, конечно. Но SoD 3.2 давно стандарт де-факто.

Цитата:

7. Удобный интерфейс в отношении работы с функциями экзешника. К сожалению для сохранения обратной совместимости с C++98 CALL_ макросы придется оставить, но в NH3API уже будут многие функции, необходимые для удобной разработки мода. Так, например, ключевые функции по типу operator new, operator delete, atexit будут иметь приставку exe_

atexit многие в глаза не видели. Не считая меня и ещё пары человек Сам перфекционист, но считаю, что новому API будет достаточно обеспечить удобную работу с основными классами (game, hero, town, диалоги, спрайты). Я не верю, что кто-то будет хукать служебные функции. Хорошо если это в 1% случаев пригодится.

Не хвалюсь, но мой плагин NewSpells, вероятно, самый большой (если считать строки кода) из всех ныне написанных Было бы здорово, если бы он "завёлся" с минимумом правок кода на новом API.

Цитата:

завестись

По идее должен. Главное его раскидать на разные файлы, модульный подход организовать.

Цитата:

Хватило бы и одного C++98. Остальное - QoL или - в простонародье - плюшки. Поясню: потенциальный автор плагинов - это не профессиональный программер и, вероятно, не программер по образованию. Теоретически это, конечно, здорово.

Ну тот же std::bit_cast, лямбды, мув семантики, и std::mem_fn и std::function очень упростят жизнь в разработке. Не утверждаю что без них никак если что. Просто лично мне например будет удобно. Да и современные компиляторы(тот же clang) генерирует код в разы лучше, чем старый добрый VS 2008

Цитата:

Я не верю, что кто-то будет хукать служебные функции

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

Я дико извиняюс что так медленно работаю над API, болею без конца.

Привет! Перед релизом(я надеюсь звёзды сойдутся и у меня найдется свободное время) Я думаю над тем, как изменить название классов hero, town, army, game для удобства.
Оставить всё как есть или изменить на hero_t, town_t, army_t и game_t соответственно?
В пользу первого варианта тот факт, что это оригинальные названия и они соотносятся с теми, что в базе данных.

Я считаю, что нужно оставить оригинальные названия классов. Кстати, интересно, как именовались экземпляры этих классов самими разработчиками. town* Town, hero* Hero?

currTown, currHero, local_hero, enemy_hero, примерно так.

Ну вообще вкусовщина, но учитывая что к нам(надеюсь) подтянутся моддеры из Era, которые пишут в основном на ERM и Delphi, привыкшие к PascalCase для функций и переменных, для них назвать переменную Hero это норм. Для меня не норм, я лучше напишу currHero или enemyHero или ещё как нибудь.

Заметил несогласующиеся поля классов type_AI_combat_parameters и type_AI_attack_hex_chooser в функции combatManager::choose_melee_target():

Код: Выделить всё

_estimate.awake_enemy_value = v57.best_hex;
_estimate.enemy_combat_value = v57.best_attack_time;