Вылет на моде Human AI. Вижу некорректный код. Пересылаю автору.

CM:H may return incorrect hero Id(s) when Scholar is triggered before hero meeting screen, when there is another hero nearby

Okay this may sound confusing. Let's reproduce the bug step by step.

1. Get 3 heroes next to each other

2. Give Scholar to one of the heroes, also give this hero all the spells
3. Save the game
4. Use this hero who have Scholar to visit another hero to trigger Hero Meeting Screen
5. Close the Scholar dialogue and enter Hero Meeting Screen
6. Use the testing script to check out whether any of the hero Ids returned from CM:H are wrong.
7. If nothing goes wrong, reload the save game saved in #3 and try again from #4.

Save game for testing (test from step #4 with it)
and video

Note:
- It doesn't matter which hero has Scholar (no matter left or right)
- The hero with scholar can be in any position among the 3 heroes

Archer30, the reason is simple, I suppose. The trigger remembers hero IDs on click event only. KeyPress event was not supported. I agree, that it's better to initialize those variable before showing dialog, but original implementation handles clicks only:

{0x5B02DD,0,DP(MouseClick2Hero)}

Yeah I suspect that's the reason when I posted. But what's the ideal way to obtain the left/right hero on Hero Meeting Screen? Apparently, we need an universal erm command instead of CM:H.

(04.02.2025 07:50)Archer30 Wrote:  But what's the ideal way to obtain the left/right hero on Hero Meeting Screen? Apparently, we need an universal erm command instead of CM:H.

Добавь у себя в плагине хук где-нибудь сразу после конструктора диалога, например в 5AEAEEh, и выполни в нём этот код:


Чтобы ВоГ запомнил номера героев ещё до непосредственного открытия диалога митинга героев, а не после того, как уже произошёл клик.

Если не хочешь ставить хук, то НЕ используй кастыльную команду CM:H, а получай номера героев из менеджера встречи героев напрямую с помощью UN:C. Хотя можно без особых хлопот добавить новую ERM-команду получения данных из менеджера встречи героев в самой era.dll, но придётся уговорить Берсеркера.

Yeah I believe this is a frequent used feature and has better to be managed by ERA itself.

Okay I will just use swap manager before any change is made.
I believe this should replace the current CM:H implementation or become a function in EEF.

Archer30, thanks, I agree with you totally. Thanks for the solution.

Critical issue of game-saving feature in new ERA

This happens only occasionally but the damage is huge. It's started to be observed by players after ERA 3.9.13, after we implemented this dialogue:


What I encountered:
- Testing stuff, load and save a save game several times
- Terminate ERA process to get some food
- Restart ERA and found the save game I used earlier cannot be used, said that the version mismatched

This is so weird...I immediately have several questions:
- Why didn't the game tell me the version was mismatched before I restarted the ERA instance? It worked just fine earlier.
- Why would it mismatch anyway? I am 100% sure this save game was made in ERA 3.9.21.

Here's the save game and debug folder. The debug is generated after the issue's popped so no script inside.
Download

It's a save game using TUM R, you will need the mod to load, probably
TUM R

I would suggest to disable ERA save game version check to load my save game and see if there is any issue.

Some code prevented WoG SaveManager or WoG LoadManager functions to save or load correctly WoG data of static size. To be more precise, the issue is with SaveMapMon or LoadMapMon function from Monsters.cpp.