Ok, thanks for info.

Np

Reporting a critical bug of igrik's quest dialog plugin:

If you visit a Guard that is only available to another player, for example, Green player visits a Guard that can only be passed by Red, the Quest log is permanently locked, resulting in a CTD every time clikcing on it.



Save game for testing

Berserker, please remove SeerHut.txt from hmm35wog.pac in order to solve the problem above.

In ERA 3, this text file was added with meaningless edits, resulting in the buggy quest guard event written in Quest Log. That's the culprit for CTD opening quest logs. igrik's plugin has nothing to do with it.

Credit:
Cruel Tomato and Hawaiing for identifying the actual cause of the problem.

Archer30, ok, thanks. I don't remember the origin of this file.

Berserker, no problem. It was a pure coincident the guys found the actual cause of the problem without many tests.

I don't fully get the idea of the new VR:C syntax. Was trying to create an array of the new combination artifacts.


It looks like I am not allowed to re-declared my newCombiArtPieces with a new length.
Here I tried to set newCombiArt to 1, yet my newCombiArtPieces array has still got the size "4" from the its declaration when newCombiArt = 0.

Is this the intended behaviour?

That's because !#VA arrays are static arrays, while you need dynamic array here. If array size differs on conditoin, then use dynamic array.

!!VR:C is not related to issue it all.

But you can also declare largest possible set array like artPieces[16] and declare numPieces:y var separately. Thus you effectively emulate dynamic array without any memory allocation/deallocation.

By dynamic you mean SN:M series?

Getting confused again, how to declare numPieces:y seperately?

I ended up converting my code to SN:M


Is there any chance this code can be using VR:C array instead? Or any better implementation?

It is rather interesing that HE:A2 not working as expected under OnEquipArt. HE:A2 doesn't count the artifact being equipped (v998), which makes my code longer than expected.

Something like that:

Berserker, I get the idea, thanks!

Is it true that usually VR:C arrays are preferred than SN:M, as they use fewer system resources?

Archer30, it is true)

Archer30, if you don't use arrays in heavy loops, use whatever is simplier for your task. For heavy loops (100000+ iterations every turn, for instance), you MAY use static arrays in the most significant and most often called functions.

The task above is easily solved using static array and array index access syntax is quite readable numCombiArtPieces[i]. In complex cases use trigger local dynamical array. It's easy to create, fill, sort, pass to another function, etc.

Static arrays are for really simple tasks.

Огромная просьба не использовать это в era.dll (проверял с версией 3.9.3)


Т.к. в ERA+ данная таблица не используется, в итоге новые эровские ERM-команды Берсеркера, пытающиеся читать $7B4C40, читают мусор и скрипты работают с Ашибками.

Базовый адрес на данную таблицу находится в 679C80h. Используйте базовый адрес в режиме реального времени, а не копируйте его куда-то заранее, до того, как таблица будет перемещена, получая в итоге неправильный адрес!!!

XEPOMAHT, а нельзя ли в OnAfterStructsRelocations получить конечный адрес по базовому?

(23.11.2022 13:34)Berserker Wrote:  а нельзя ли в OnAfterStructsRelocations получить конечный адрес по базовому?

Не рекомендуется, т.к. таблица может быть перемещена в любой момент времени, например маппер может создать собственную таблицу специализаций в ассоциативной памяти эры и подключить её к игре с помощью базового адреса в инструкции карты. Тифон патчит структуры после AfterWoG уже после всех патчей ЭРЫ в AfterWoG, а эровская обработка OnAfterStructsRelocations происходит имеено в эровском AfterWoG, а не где-то позже, из-за чего ЭРА не воспринимает данные из OnAfterStructsRelocations полностью (те же самые глюки со структурой монстров, где вперемешку используется и старый и новый адреса из-за позднего OnAfterStructsRelocations).