But useful garbage? As I understand, it is part of the seed still?

No, garbage means not useful. Era does not use C native PRNG state and the address original code used. So garbage is garbage ) And you don't need it at all. You want VR:T, something not predictable on reloading. Exactly the case. Just be sure, that this event will not influence multiplayer.

Berserker, no, I want it reproducible (possible to repeat result with Save & Load)
Check out the report, with a video. The issue we experience here without seed management is that every random specialty generated after a hero's defeat is the same when you spam battles (initiate the battle, defeat, recruit a new hero in the tavern and repeat) in the same location.

According to you, what I did is that I fetch garbage and set seed. However, for some reason, this satisfies what I need:
- When you spam battles in the same location, you get different specialties every time
- These results are reproducible when you Save & Load before the first battle you spam

VR:T doesn't have the second feature of my method.

I still do not understand the source of the issue. Better enable random generator tracking in heroes3.ini (console mode) or insert VR:R checks in onafterbattle. The solution seems to be "hacky" and "lucky". Normally VR:R shout be random in OnAfterBattleUniversal. We should report it as bug it it's not so.

For deterministic but quite random results you can use coordinates, current day and attacking hero ID and attacking hero move points to generate seed and then use it in script.

I have something working at the moment so I won't complain, we can leave it later

Critical issue: Interaction between !!EA (use on negative stack id) and Battle Replay

This is a critical issue in scripting that if a stack is set with !!EA and kill and transform into another stack, its stats will remain the ones after its transformation after battle replay.

Ok I understand this doesn't sound understandable. Let me show you my testing script:

And my testing video

In this video, I used raw ERA + GEM (for battle replay) + my testing script (see above). I picked a random fight and ran my script.

As you can see in the video,
- The gnoll had a standard HP stats initially
- It got killed with script, with (MON_FLAG_SUMMONED) added
- An Azure Dragon was summoned, due to the vacancy left by the Gnoll, it occupied the killed Gnoll's stack Id
- Set any !!EA on the summoned Azure Dragon
- Killed the Azure and Summoned again (optional)
- Ended the battle and replayed
- Found the Gnolls had 1000 HP

My guess is that !!EA for stack id has some cache that needs to be reset on Battle Replay. However, I don't know where to find them. I don't know how to fix.

Currently, the mechanism corrupts "Metamorph" script's behaviour.

Archer30, thanks for perfect detailed bug report. Seems like BattleReplay does not call CrExpoSet::StartAllBF(G2B_MArrA,G2B_MArrD) on replay.
It's inside Monsters.cpp (function G2B_Prepare)

Berserker, I've got the temporary solution thanks!

I want to know that when you restart ERA and launch the code above, does your speaker makes some funny noise when the stack is killed by pressing "K"? It happens to me and I don't know what to do except for temporarily setting the volume of H3 to 0. Like

____

Btw, any chance of releasing 3.9.16 in the near future?

Quote:Berserker, I've got the temporary solution thanks!
!?FU(OnBeforeBattleReplay);
!!SN:E7500058/(CALLCONV_CDECL)/42229972/42149936;

This is incorrect. The "solution" leads to a crash on battle replay. A new solution is still being researched....

(14.10.2024 21:26)Archer30 Wrote:  

Quote:Berserker, I've got the temporary solution thanks!
!?FU(OnBeforeBattleReplay);
!!SN:E7500058/(CALLCONV_CDECL)/42229972/42149936;

This is incorrect. The "solution" leads to a crash on battle replay. A new solution is still being researched....

1. Содержимое переменных для начала стоит извлечь, т.к. на функцию подаётся их содержимое, а не адреса.
2. При рестарте битвы адреса структур атакующих и защищающихся армий надёжнее всего брать из структуры баттлменеджера, т.к. при перезагрузке менеджера данные тоже перезагружаются в памяти, при этом содержимое воговских переменных может устареть и не соотвестствовать действительности.

XEPOMAHT, thanks, so
Looks good?

I assume igrik has put correct attacking/defending heroes' pointers into the 2 addresses (28460D4 and 2832830) upon battle replay.

(22.10.2024 02:02)Archer30 Wrote:  I assume igrik has put correct attacking/defending heroes' pointers into the 2 addresses (28460D4 and 2832830) upon battle replay.

Туда подаются стартовые армии, вне зависимости, пренадлежат они герою или нет. Получать адреса стартовых армий надёжнее всего из менеджера битвы:


Сама структура менеджера битвы хранится в 699420h.

So the safest way would be
Thanks, XEPOMAHT.

Archer30, does it fix the issue?

It does

(22.10.2024 15:00)Archer30 Wrote:  So the safest way would be

1. !?FU(OnBeforeBattleReplay)&i^battle_isVisible^;
2. !!UN:C(COMBAT_MANAGER)/4/?(cmbMgr:y);
3. !!UN:C(cmbMgr)/21700/4/?(atkStruct:y);
4. !!UN:C(cmbMgr)/21704/4/?(defStruct:y);
5. !!SN:E7500058/(CALLCONV_CDECL)/(atkStruct)/(defStruct); 72711A

Thanks, XEPOMAHT.

Updated. It is required to check i^battle_isVisible^.
A battle replay after quick combat corrupts stack exp data with this script. Checking i^battle_isVisible^ (making sure the battle was visible) avoids this situation.
Alternatively, you can use !?FU(OnBattleReplay). But I suspect we need to fix stack exp data at an earlier timing like !?FU(OnBeforeBattleReplay) so scripters can do their jobs with ease.