Вылет на моде 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.

Continue from stack exp flag ability canceling the ability of creatures own

I agree that this is not a bug according to the Wog source.

However,
- I don't see a scenario canceling the flag ability of a creature by stack exp ability is needed
- Part of the WoG Team wasn't aware of this feature.
For example, for the No Retaliation ability of Darkness Dragons. The values of the ability were set as
But for the Flying ability of Imps, it was set as
I don't see why they should be set differently. Likely, some guys writing crexpbon.txt weren't aware of the difference between setting 0 and 2 here.

Thus, I propose to disable the feature of cancelling ability by stack exp
I will add it to GEM if everyone's happy.

HE:C (without parameter #4/#5 for stack exp) is counterintuitive in exp management

If you use
to multiply the number of creatures of slot 0#, you would find that the stack exp of this stack is halved.
This is because ERA tries to keep the total exp of this stack, and thus, the exp of each unit is recalculated after the HE:C execution.

It makes sense to some extent, but it is counterintuitive. Judging from existing scripts in the old WoG Scripts mod, nobody realised how HE:C works. These are happening now:
- After choosing a henchman for your hero, the stack number of the chosen stack is reduced by 1, yet the total exp increases.
- After sacrificing a few creatures in Emerald Towers, the sacrificed stack has increased stack exp for each unit

The better implementation for HE:C (without parameter #4/#5 for stack exp) is, when it sets the stack number, simply just set it and keep the stack exp for each unit the same before and after setting. This suits every script I've seen in multiple mods.

Archer30, wog native behavior was if you add some creatures to a stack, the exp per creature should be dropped. It's default behavior for adding newbie creatures. I totally agree, that removing creatures or changing their number to a new value leads to counterintuitive results. As I understand, it's the most simple solution to keep int32 stack exp value unchanged by default, otherwise any change should involve whole stack exp recalculation.

Berserker, just to make sure we are on the same page - we have a full set of stack exp management with HE:C commander by using the #4/#5 parameters. The discussion is about the scenarios when these two parameters aren't presented.

Quote:wog native behavior was if you add some creatures to a stack, the exp per creature should be dropped.

Yes, this is correct and expected.

Quote:As I understand, it's the simplest solution to keep int32 stack exp value unchanged by default; otherwise, any change should involve whole stack exp recalculation.

So, keeping the total exp of a slot is coding-wise easier?
Well, wog team implemented tools to keep the stack exp for each unit. For example, the line for taking out one creature for henchmen is:
It can be changed to
in order to keep the same stack exp for each unit.

My idea is, it would be better to have "keeping same stack exp for each unit" as the method for HE:C without #4 and #5 parameters. The current implementation is quite unexpected and multiple scripts have used it in a wrong way.

Archer30, I got your point and faced the same issue during writing old project. But most scripts will simply ignore stack exp when, for instance, adding new creatures in growing armies script. It's so easy just to modify counter without even remembering, that stack exp system exists. Another issue is backward compatibility. If you insist on new behavior, let it be for version 4.x.