(25.08.2024 06:03)Berserker Wrote:  По идее пустые подсказки (нулевой адрес) вообще не должны быть.

Не должно, но я уже потерялся в догадках, почему код era.dll не работает аналогично воговскому коду на добавление подсказки. Саму переменную в стеке, где хранится адрес подсказки, Тифон никак не меняет. Значение из переменой уходит на функцию AddHint(iid,hint); и доходит до эровского хука, а дальше... после эры Body->Hints[i].Text превращается в тыкву

(25.08.2024 06:03)Berserker Wrote:  В коде вога проверка:
if(hint[0]!=0) AddHint(iid,hint);

Да, игра бы здесь сразу вылетела, недоходя до хука эры, если бы вместо адреса был 0.

(25.08.2024 06:03)Berserker Wrote:  Ты передаёшь нулевой? Я тогда сделаю нулевой адрес аналогом #0.

Нет, 0 может зайти только с загрузчика текстовика шаблона диалога, но там тоже не может быть 0. Остаётся только то, что команда Utils.CopyMem(NewHintSize, NewHint, NewHintCopy); из ЭРЫ на Windows 2003 тупо не работает или команда Heroes.MemAlloc(NewHintSize) из ЭРЫ не может выделить память под динамические массивы (возможно, что эровские динамические массивы вместе с ERA+ не работают вообще никак, т.к. они в ERA+ никогда не использовались).

Если что и можно - добавить в era.dll проверку на true после выполнения Heroes.MemAlloc(NewHintSize), в случае false выполнять полный аналог воговского кода, который был подменён хуком. Т.к. похоже, что в ERA+ Heroes.MemAlloc(NewHintSize) всегда заканчивается неудачей и хук на выгрузку просто не может выгрузить нулевую память после неудачной Heroes.MemAlloc.

Loading a savegame from battle locks the animation of neutral creatures permanently

This issue was introduced with the new implementation of the existing game in ERA (3.9.x).

If you attack a neutral stack and load the save game using the following script:

You would find the attacked neutral stack permanently stuck at its attacked frame (avwattak.def).


While this is barely noticeable in the original game, it is a more serious problem in mods that added new creatures. We usually use the "twin sword graphics" for avwattak.def in these mods (originally from MoP?). When the bug happens, you will see the swords on the adventure map, which is quite funny.

Suggestion: VR:R (double parameters syntax) to get the current random seed should be supported

We currently have VR:R double parameters syntax to set the random seed.

But it seems this syntax is not supported yet

We have to use

It would be very convenient if VR:R to get the current random seed can be supported, so we don't have to memorise the memory address of the seed

Archer30, PRNG state can be of any size. 128 bytes for Mersenne Twister, afair. Thus it's not valid to expect it to fit integer. PRNG state is equal to its seed only for simple generators.

Quote:Loading a savegame from battle locks the animation of neutral creatures permanently

I confirm the bug. Got even random crash in one test. Seems like some game structures remain in dirty state if exception is raised.

(25.08.2024 07:09)XEPOMAHT Wrote:  после эры Body->Hints[i].Text превращается в тыкву

Могу попробовать сделать тестовый билд с отладочным сообщением старой и новой подсказки.

Berserker, that's new to me. That means my attempt to generate random numbers without affecting the seed isn't entirely correct?

Archer30, right. You change the state of C simple linear congruent generator. Era uses its own generators, thus your code does nothing ) Era has API to get/restore generator state, but state size (array of bytes) is not guaranteed to be 4. And it will not work in multiplayer battle, for instance.

H3 developers didn't bothered about it and used rseed before every battle or hero level up. Where do you need fixed seed and could you use SplixMix32 generator instead for this purpose?

Berserker, so a player has been complaining about Mortal Heroes (ES option) generating the same specialty (which is generated by a set of VR:Rs) whenever he spams battles in the same location. For example, getting his hero killed - got a new specialty and - recruit - get his hero killed in the same spot again.
What this script does:


This has only become a problem since ERA introduced the more stable random number generation mechanism.

Links:
The report and discussion
The exact spot a new specialty is generated (this and some following VR:Rs)
My solution to prevent same specialty generating

Bascially, what my fix (in My solution to prevent same specialty generating) is:
- Fetch and store the seed
- Change the seed according to how many times a new specialty has been generated (new seed = current seed + counter for specialty generated)
- Generate specialty (VR:Rs)
- Restore the seed

I did it this way (instead of replacing VR:R to VR:T) because I wanted my VR:R to generate relatively stable results (for example when you Save & Load, you will still get the same new specialty generated)

But according to you, my attempt to restore the seed after my VR:Rs is futile. I guess I can deal with it. What I lose here without seed restoration is that the second and any specialty after (in the same battle location) is completely random, and changeable by Save & Load.

Archer30, in which trigger is VR:R called multiple times? Does it occur in multiplayer PvP battle only?

Berserker, OnAfterBattleUniversal, when the battle is concluded. It occurs in SP/MP

Does it happen before/after hero level up? Only if here level ups?

Berserker, well, the script is called "Mortal Heroes" and does the thing in the description: Reset and regenerate a new specialty for the defeated hero.

The timing of reset/regeneration is OnAfterBattleUniversal, which take place after OnHeroGainLevel

Archer30, I ask about it because H3 code calls srand (seed rand) in OnHeroGainLevel, afair, to make skills selection more predictable. And that's why right after level up VR:R may have the same value.

One possible solution is to seed generator with int32 random value.

This script must have quite big priority like 1000 to influence the other scripts.


Another solution is to use VR:T for this purpose which is perfectly valid.

Your proposed script is changing the seed, making OnAfterBattleUniversal scripts completely random, which I am not sure is appropriate yet.

I think my solution is good. I changed the seed based on the current one, and it's not VR:T (reproducible from Save & Load).

You change the seed based on the garbage. The value you read is not real generator seed. Era uses Xoroshiro128 now, which has 16 byte state.

Use VR:T for this purpose. You do not need anything else.