Wake of Gods Forum | Форум Во Имя Богов

Full Version: Ошибки, баги и недочёты ERA
You're currently viewing a stripped down version of our content. View the full version with proper formatting.
Напишу тут. Модераторы переместят куда надо.

Вылет на ходе ИИ. Почему - даже не догадываюсь. Такие вылеты уже были на ходе случайных героев ИИ, с нулевым уровнем прокачки и раскаченные на максимум, с войсками и артефактами и без оных.

Разбирайте, изучайте и напишите в чём ошибка и где конкретно.

P.S. Половина файлообменников недоступна по дури нашего(и не только) руководства, так что дополнительной информации и файлов предоставить не могу.
Continue from Messing up wog immunity checks

Not entirely sure what I am doing, but I think this script fixes Ghost Dragons' Age spell (from stack exp) casts on spell-immune targets.
This is a series of bugs of the original Heroes 3

Messy stack quantity calculation and battle result
When you cast a spell that creates a new stack, for example, Summon Water Elemental or Clone, the game will:
- Check if the current stack quantity is <20 by checking the value in Combat Manager->54BC (Example: 0x59EFE8 when summoning elemental)
- look for the first available stack id and use it for this new stack.

If a stack has the flag Summoned and Killed (This happens when a clone is killed), the stack id will be marked as available, and when you summon another stack in the battle, this stack id will be occupied by the new summoned stack. Here we have some inconsistency:
1. Despite a Summoned/killed stack id can be used for a new summoned stack, yet when checking the current stack number, the game uses Combat Manager->54BC. This value isn't updated when a summoned stack is killed, thus, it is possible that there is still vacancy left in the battlefield, yet the game tells you "already 20 stacks and you can't summon any more units".
Here I provide 2 videos:
Video 1 - current stack quantity not updated when summoned unit killed
The stack id number in Combat Manager->54BC, after a summoned stack is killed, still shows the current stack quantity as 18 (should be 17), and when a new stack was summoned, the killed summoned unit's stack id was occupied and the current stack quantity was also 18.
Video 2 - once reaches 20, no longer possible to summon even if the summoned unit killed
Once we reach 20 units on the battlefield, it would not be possible to summon more units even if a summoned unit is killed.

Testing script in the video:

2. Since the game recycles Summoned/killed stack slots, some data would be overridden when a new stack is summoned and uses a stack id that previously belonged to a summoned creature. This creates a new issue that we no longer have the data of the previously killed summoned stack, which is reflected in the battle result screen.
Video 3 - the killed summon unit is not shown in the battle result once another unit uses its stack id
As you see from the video, the casualty is none (the killed Earth Elemental stack isn't shown). But if I didn't summon a new Earth Elemental stack, the killed Earth Elemental would be shown there.

My thought:
1. The stack quantity at Combat Manager->54BC should be updated immediately after a summoned stack is killed. This avoids the fake message claiming the battlefield is full after reaching 20 stacks for once.
I could probably finish this task on my own.
2. When a stack is summoned and uses a stack id that is previously occupied by a summoned stack, the previous stack info should be saved somewhere and use when showing battle results.
Haven't tried but I probably need some help with this task.
Thanks for the report. As I see, current implementation serves the purpose of valid post-battle casualities screen at the cost of multiple stack ID reusage. I would fix it by allowing ID reusage, but such summoned stack would not still be seen in casualities screen (otherwise it could require up to 200+ unique creature images in casualities screen in the worst case).
Вообще-то оригинальный SoD не позволяет призывать больше 1 типа монстров в бою. Призванный тип монстра так же пишется в структуру боя, который игра потом и проверяет, чтобы не было вышеописанных глюков. К сожалению, ВоГ вместе с командирами и охраной сант ломает содовский принцип призыва монстров, т.к. в WoG Team возможно этого не знали/наплевали, используя содовскую функцию призыва без дополнительных проверок. В ERA+ призванные монстры не должны показываться в итогах боя, т.к. по правилам боя ERA+ с ними драться необязательно (ИИ в ERA+ так же нападает на них, когда нападать больше не на кого, а если разница в суммарном AI-value отрицательная - пройдёт мимо и побежит в сторону непризванного вражеского отряда).
(13.01.2025 18:15)Berserker Wrote: [ -> ][*] Обновлен плагин "erm_hooker.era", отражающий изменения в движке Era.
[*] Обновлен плагин "buttons.era", отражающий изменения в движке Era.
[*] Обновлен плагин "wog native dialogs.era", который более терпим к неподдерживаемым типам изображений для диалогов IF:E.

Опять систему хуков в era.dll поменяли??? Кто же оставшиеся плагины обновлять будет? В прошлый раз проблема с плагином Video playback in BIK format.dll (к которому ERA+ уже привязана наглухо) много крови попило, и вот опять совместимость со старыми плагинами обнулили:

Image: image.png

Т.к. Тифон принудительно запускает bink версии 1.8, то патчи и хуки из Video playback in BIK format.dll жизненно необходимы, иначе будет это:

Code:
Failed to read data at 374.
EIP: Ntdll.34019. Code: C0000005

> Registers
EAX: 00000374 (int: 884)
ECX: 00229B58 (int: 2267992, pint: 0x00000000)
EDX: 00000000 (int: 0)
EBX: Kernel32.1ADB (int: 2088770267, pint: 0x8B55FF8B)
ESP: 00229B40 (int: 2267968, pint: 0x7FFDFBF8 = 2147351544)
EBP: 00229B44 (int: 2267972, pint: 0x00229B60 = 2268000)
ESI: 00000375 (int: 885)
EDI: 00000374 (int: 884)

> Callstack
Kernel32.2C056
Kernel32.1AE8
Binkw32a.101A3
H3era.0044D5D8
H3era.0044DA2A
Typhon.C0EC

поэтому новая версия era.dll вместе с ERA+ увы не работает, обновлять ЭРУ пока нельзя!
Автор не поделился исходниками, но изначальный подход привязки к внутренней кухне переходников/перехватчиков не надёжный.
(14.01.2025 02:10)Berserker Wrote: [ -> ]изначальный подход привязки к внутренней кухне переходников/перехватчиков не надёжный.

Нельзя ли этот 1 несчасный эровский хук устанавливать старым эровским способом для сохранения совместимости с Video playback in BIK format.dll ? Т.к. появится ли на форуме автор плагина - не известно 105
Автор есть в вк https://vk.com/myoffice91
Пусть на OpenBik ставит splice-хук из патчера или хотя бы HiHook. Всё остальное от лукавого.
I've just encountered the most challenging bug in my career (as an ERA bug fixer).
Edit: Just a second thought, can this be related to the change in ERA 3.9.1x?
And yes. This didn't happen in ERA 3.9.13.

Enchanters can cast massive spells for the wrong side
For example, casting Haste for their enemies.

To reproduce:
- Initiate a battle with anything, like a neutral stack
- Cast Hypnotize on any of the stacks (must make sure the stack id is the same with Enchanters encountered in the next battle)
- Win the battle
- Initiate a battle with an Enchanters stack (or fight against an Enchanter dwelling)
- Defend until the hostile Enchanters cast
- You will find that they cast Massive Friendly spells on your troops

Video and testing map:
Download

Things I have tested:
- Reset Hypnotize spell info from stack structure (stackStructure->0x288 = 0), it doesn't seem to have any effect
- Checked out sides data in the Enchanter function (0x447D00), everything seems to be correct
- Used only raw ERA without Game Bug Fixes Extended, didn't help
- The bug doesn't exist in Complete/Hota (but I haven't checked them without HD, the game didn't launch)
- The bug doesn't exist in WoG 3.58f without HD mod
Fixed, thanks.
За каким ..ухом в lua51.dll из последних обновлений ЭРЫ добавили принудительную загрузку vcruntime140.dll, которой нет в старых виндовозах??? В итоге последнюю версию ЭРЫ можно запустить только с помощью подмены lua51.dll на версию от 2017 года, что вызывает проблемы при установке чистой версии ЭРЫ на вёдрах и сливных бачках.

Так же в архив с ЭРА зачем то положили msvcp140.dll, которая, наоборот, нигде не используется. Может перепутали или чего-то не понял я?

Так же в составе последней версии ЭРЫ лежит странный h3era.exe, у которого нет иконки, и который не понимает HD-мод из-за несовпадения размера с exe WoG T1, в итоге HD-мод пытается запускать h3era.exe как h3sod.exe и у него ничего не получается - совместимость с HD-модом можно получить если только использовать старый h3era.exe соотвествующего воговского размера.
XEPOMAHT,

1) lua51.dll

- Это собранный мной из исходников 32-битный вариант LuaJit 2 OpenResty. Попробую найти способ собрать без зависимости, но не могу обещать, что выйдет.

2) h3era.exe уже давно такой. Иконка там присутствует (феникс), приложения её видят, современные версии hd-мода тоже. И этому файлу уже не один год, разве что я заменил ddraw.dll на zdraw.dll для запуска игры в оконном режиме без hd мода.
Вот lua/luajit 2 openresty для старых пк: https://dropmefiles.com/M3BqR
ребята специалисты. разберитесь чот это за вылет из игры. Во время хода ИИ. Я когда играл на красном цвете так вылетало чаще. На зеленом цвете меньше. Но вылетает на определлом дне и всё. Незнаю есть ли какая то в это связь.
    Даже если откатится на неделю назад, вылетит игра всеравно

архив с дебагом по ссылке
link arhive debug ERA
Reference URL's