igrik, а заплатка no_underground_at_underground.bin? Или в вог/куда-то еще пойдет?
igrik, не заметил, спасибо!
igrik, thanks for your work!
Might be a problem or might not, but I noticed an unexpected change of game_bug_fixes.
Hero info panel is not shown immediately until the msg box on day 1 from the map is closed
If you start Arrogance the first map of SoD
With game bug fixes:
Hero info panel is empty
Without game bug fixes:
Hero info panel is ready immediately
It is completely fine either way. I just mention it here in case it is a sign of something else's wrong.
Fixed!
Update the info panel has been corrected. It is updated only when the adventure map is active.
I did it on purpose. I've always been infuriated by updates inside the city or the hero's screen, or battles, etc. (watch the screenshot)
Для добавления в game bug fixes extended.
Есть визуальный баг, или скорее недочёт, связанный со штрафом препятствий.
Если двухгексовое существо стоит справа за стенами при осаде, то при некотором расположении стрелков слева от стен, стрельба по переднему гексу может быть со сломанной стрелой, а по заднему - с прямой, или наоборот. Причем урон в обоих случаях одинаковый. Связано с тем, что при определении штрафа здесь 0x43B713 и здесь 0x443999 в функцию передается гекс, на котором стоит существо (для 2-гексового - задняя часть), и урон рассчитывается по нему. А вот отображение прямой и сломанной стрелы здесь 0x476106 как раз зависит именно от гекса, на который наведён курсор.
Визуализация бага
На мой взгляд достаточно сделать одинаковым отображение прямой/сломанной стрелы для обоих гексов, нежели пересчитывать урон.
В ХотЕ, кстати, баг тоже присутствует.
igrik, зачем нужна данная строчка из TownHeroesMeet.cpp из wog_native_dialogs.era?
Code:
if ( *(int*)((int)o_ExecMgr +4) != (int)o_WndMgr )
Т.к. адреса менеджера o_ExecMgr в базе нет, поэтому я понять не могу что это, а узнать всё же желательно, т.к. пришлось перенести весь твой код из TownHeroesMeet.cpp в Тифон для того, чтобы открывать диалог встречи героев по хотовской кнопке в городе.
Потому что в 90% случаев возникал баг с зависанием игры.
Баг заключался вот в чём:
1) Стартуем игру (новый запуск из винды, это важно! НЕ простая перезагрузка карты, а прям перезагрузка игры)
2) Заходим в город и вызываем диалог обмена героев. Важно НЕ проводить встречу вне города, до этого момента
3) После закрытия диалога встречи игра закрывает и диалог города тоже, и появляется визуальный баг (позже скину скрин)
Т.е. игра показывает основную карту, но без героев и городов. на мышь реакции нет, реакция есть на F4, F5 и всё
Этот код решал эту проблему в 99% случаев путём правильной перетасовки менеджеров
Code:
if ( *(int*)((int)o_ExecMgr +4) != (int)o_WndMgr )
Вот небольшое объяснение причины бага: т.е. на момент вызова диалога обмена в городе описание плохого и хорошего расположнения менеджеров в структуре o_ExecMgr
Замечание: в коде Хоты и в Моп я подобного кода (да и вообще упоминания такой проблемы) не видел. Не понимаю, если честно - почему у меня такая проблема нарисовывалась и почему в других версиях этого не было.
(13.04.2024 00:17)igrik Wrote: [ -> ]Потому что в 90% случаев возникал баг с зависанием игры.
Ну я давно в курсе (именно по-этому данная кнопка в старых версиях ERA+ ничего не делает). Как я понял из кода игры, программисты из NWC схитрили и чтобы окно города всегда было открыто, то нужно, чтобы из под дочернего окна была видна хоть какая-нибудь часть диалога города, например полоска ресурсов (очередные содовские костыли). Если не видно ничего, то движок игры думает, что окно перекрыто и принудительно не показывает его. Но после закрытия дочернего возврата к показу родительского уже нет и у меня не получилось найти решение как заставить игру думать, что после уничтожения менеджера встречи героев активным становится менеджер города, а не менеджер карты приключений (т.к. диалог встречи героев отвязывается от менеджера карты приключений только костылями, возможно хотовцы сделали как-то без костылей, но этого мы никогда не узнаем).
(13.04.2024 00:17)igrik Wrote: [ -> ]Этот код решал эту проблему в 99% случаев путём правильной перетасовки менеджеров
Code:
if ( *(int*)((int)o_ExecMgr +4) != (int)o_WndMgr )
Мне хотелось узнать что контретно делает эта строчка. Т.к. и без неё почему-то работает. Конкретнее - что такое o_ExecMgr, т.к. я не нашёл его в вого-базе IDA.
(13.04.2024 00:17)igrik Wrote: [ -> ]в коде Хоты и в Моп я подобного кода (да и вообще упоминания такой проблемы) не видел. Не понимаю, если честно - почему у меня такая проблема нарисовывалась и почему в других версиях этого не было.
В MoP в городе диалог встречи героев не используется, насколько помню. Да и сам вызов Мастер модифицировал, добавив туда воговский триггер например.
А исходные коды HoA с этой кнопкой есть только у HotA Crew, т.к. по рукам бродят только коды от старых версий, где этой копки ещё нет.
(13.04.2024 01:28)XEPOMAHT Wrote: [ -> ]Мне хотелось узнать что контретно делает эта строчка. Т.к. и без неё почему-то работает. Конкретнее - что такое o_ExecMgr, т.к. я не нашёл его в вого-базе IDA.
Эта строчка проверяет, является ли o_WndMgr текущим менеджером (т.е. на верху дерева иерархии) или нет.
ExecMgr = это класс загрузки и управления базовыми менеджерами игры. Например он же загружает битву каждый раз, и каждый раз её выгружает. Так же и с диалогом города.
Буду дома - скину его структуру (то что я когда-то ещё разобрал)
(13.04.2024 01:28)XEPOMAHT Wrote: [ -> ]В MoP в городе диалог встречи героев не используется, насколько помню. Да и сам вызов Мастер модифицировал, добавив туда воговский триггер например.
Как это? Нажми кнопку "Home" в городе с двумя героями. Я про MoP 3.07 и позднее
(13.04.2024 01:28)XEPOMAHT Wrote: [ -> ]А исходные коды HoA с этой кнопкой есть только у HotA Crew, т.к. по рукам бродят только коды от старых версий, где этой копки ещё нет.
Ну так я тоже за счёт реверса смотрел. Но я не увидел у них там этих танцев с бубном.
(13.04.2024 00:17)igrik Wrote: [ -> ]Замечание: в коде Хоты и в Моп я подобного кода (да и вообще упоминания такой проблемы) не видел. Не понимаю, если честно - почему у меня такая проблема нарисовывалась и почему в других версиях этого не было.
Была она, была. Именно поэтому при входе в экран города функция обновления экрана карты приключений самым грязным способом глушится намертво, а при выхода из экрана города - восстанавливается.
А я себе голову ломал "почему всё норм", когда смотрел код MoP. Теперь понятно. Спасибо за инфу
Code:
struct _ExecMgr_; // Размер: 16
#define o_ExecMgr (*(_ExecMgr_**)0x699550)
// Менеджер работы с другими менеджерами (размер - 16)
NOALIGN struct _ExecMgr_ : _Struct_
{
_Manager_* previous;
_Manager_* next;
_Manager_* current;
_Manager_* field_C;
_Manager_* RunManager() { return CALL_1(_Manager_*, __thiscall, 0x4B0BA0, this); }
_byte_ CallManager(_Manager_* mgr) { return CALL_2(_byte_, __thiscall, 0x4B09D0, this, mgr); }
_int32_ PushManager(_Manager_* mgr) { return CALL_2(_int32_, __thiscall, 0x4B0770, this, mgr); }
_int32_ AddManager(_Manager_* mgr) { return CALL_3(_int32_, __thiscall, 0x4B0880, this, mgr, -1); }
void RemoveManager(_Manager_* mgr) { return CALL_2(void, __thiscall, 0x4B0950, this, mgr); }
};
// * размер 0x38h (56 байт) // первые 56 байт всех менеджеров в игре.
NOALIGN struct _Manager_ : _Struct_
{
struct {
_dword_ managerConstructor; // 0x44D200
_dword_ managerDestructor;
_dword_ managerUpdate;
} *h3ManagerVTable;
_Manager_* previus; // parent
_Manager_* next; // child
_int32_ id;
_int32_ priority;
char name[28]; // 0x14
_int32_ nameEnd; // 0x30
_int32_ isActive; // 0x34
void SetPreviousManager(_Struct_ *prevMgr) { previus = (_Manager_*)prevMgr; }
void SetNextManager(_Struct_ *nextMgr) { next = (_Manager_*)nextMgr; }
_Manager_* ActivateManager() { return CALL_1(_Manager_*, __thiscall, 0x4B0BA0, this); }
void SetManagers(void *mgr1, void *mgr2)
{
previus = (_Manager_ *)mgr1;
next = (_Manager_ *)mgr2;
}
};
Code:
// это
if ( *(int*)((int)o_ExecMgr +4) != (int)o_WndMgr )
// то же самое, что и это
if ( o_ExecMgr->next != (_Manager_*)o_WndMgr )
(13.04.2024 07:49)MOP Wrote: [ -> ]Именно поэтому при входе в экран города функция обновления экрана карты приключений самым грязным способом глушится намертво, а при выхода из экрана города - восстанавливается.
Тифон так же пишет вместо структуры менеджера карты приключений 0, не давая ему обновляться - там так же добавлена проверка на 0 при попытке любого обновления.
(13.04.2024 11:05)igrik Wrote: [ -> ]
Code:
// это
if ( *(int*)((int)o_ExecMgr +4) != (int)o_WndMgr )
// то же самое, что и это
if ( o_ExecMgr->next != (_Manager_*)o_WndMgr )
Добавил эту штуку в Тифон и... феаноровский плагин Emerald при повторном открытии диалога встречи героев начал выдавать утечки памяти, приводящие к вылетам на ровном месте, хотя тот же самый код Игрика Emerald почему-то не роняет, т.е. под Emerald патч в Тифоне на ротацию менеджеров придётся выполнять всегда, т.к. в самой игре патч вроде ничего не ломает. То ли плагин Emerald настолько кривой (который я когда-нибудь точно заменю собственым плагином на новые артефакты), то ли я что-то неправильно переписал с исходников (СИ тяжело читать).
(13.04.2024 12:23)XEPOMAHT Wrote: [ -> ]... то ли я что-то неправильно переписал с исходников (СИ тяжело читать).
Так декомпилируй WND и напиши по декомпилированому.
А вообще, если хардкодно блочишь обновление экрана карты приключений, то зачем эти танцы с бубуном
Code:
int __stdcall sub_10013580(int a1, int a2, int a3)
{
int (__thiscall *v3)(int); // eax
int result; // eax
int v5; // ebx
int v6; // eax
int v7; // ecx
int v8; // edi
int v9; // esi
int v10; // eax
int v11; // edx
int v12; // edi
v3 = (int (__thiscall *)(int))(*(int (__stdcall **)(int, int))(*(_DWORD *)a1 + 44))(a1, a3);
result = v3(a3);
v5 = result;
inTownDlg = 0;
if ( result && *(_DWORD *)a3 == 1 && *(_DWORD *)(a3 + 4) == 18 )// if (msg->type == MT_KEYDOWN && msg->subtype == HK_E)
{
v6 = MEMORY[0x5FF5B0](*(_DWORD *)(a3 + 280), 7001);// _DlgTextEdit_* editText = (_DlgTextEdit_*)tm->dlg->GetItem(7001);
if ( !v6 || *(_BYTE *)(v6 + 112) ) // if (!editText || editText->enteringText)
{
return v5;
}
else
{
v7 = *(_DWORD *)(a3 + 56); // int heroU_id = tm->town->up_hero_id;
if ( *(_DWORD *)(v7 + 12) != -1 && *(_DWORD *)(v7 + 16) != -1 )// if ( tm->town->down_hero_id != -1 && heroD_id != -1)
{
v8 = MEMORY[0x699538];
v9 = sub_10001540(MEMORY[0x699538]);
v10 = sub_10001540(v8);
v11 = *(_DWORD *)(MEMORY[0x699550] + 4);
v12 = v10;
inTownDlg = 1; // inTownDlg = true;
if ( v11 != MEMORY[0x6992D0] ) // if ( *(int*)((int)o_ExecMgr +4) != (int)o_WndMgr )
{
*(_DWORD *)(MEMORY[0x69954C] + 4) = MEMORY[0x6992B8];// (int*)((int)o_TownMgr +4) = (int)o_AdvMgr;
*(_DWORD *)(MEMORY[0x69954C] + 8) = MEMORY[0x6992D0];// *(int*)((int)o_TownMgr +8) = (int)o_WndMgr;
//
*(_DWORD *)(MEMORY[0x6992B8] + 4) = 0;// *(int*)((int)o_AdvMgr +4) = NULL;
*(_DWORD *)(MEMORY[0x6992B8] + 8) = MEMORY[0x6992D0];// *(int*)((int)o_AdvMgr +8) = (int)o_WndMgr;
*(_DWORD *)(MEMORY[0x6992D0] + 4) = MEMORY[0x69954C];// *(int*)((int)o_WndMgr +4) = (int)o_TownMgr;
*(_DWORD *)(MEMORY[0x6992D0] + 8) = MEMORY[0x6992B0];// *(int*)((int)o_WndMgr +8) = (int)o_MouseMgr;
}
*(_DWORD *)sub_10015900() = 1; // hdv(_bool_, "HotA.SwapMgrCalledFromTown") = 1;
MEMORY[0x4A25B0](v9, v12);
MEMORY[0x4AAA60](MEMORY[0x6992B8], v9, v12);// o_AdvMgr->SwapHeroes(heroU, heroD);
*(_DWORD *)sub_10015900() = 0; // hdv(_bool_, "HotA.SwapMgrCalledFromTown") = 0;
MEMORY[0x5D5930](MEMORY[0x69954C]); // o_TownMgr->UnHighlightArmy();
MEMORY[0x5D5810](MEMORY[0x69954C]); // o_TownMgr->Redraw();
inTownDlg = 0; // inTownDlg = false;
}
return v5;
}
}
return result;
}
XEPOMAHT, it looks like
Prima didn't patch Mana Vortex. When a hero has Knowledge at above 127, Mana Vortex won't be activated.
Map for testing
Suggesting address to patch: 0x5BDD24
(Click to View)