Got it. The second issue is solvable on library level.

Yea, that's solvable but that means all those pop-ups have to be remade. Nothing similar can be done in ERA like the OnAdvMapTileHint event?

Assuming the answer is negative. Can you give some hints about manipulating the Witch Hut RMB pop-up, like where to hook and how to replace the original hint?

Nope, any solution will lead to code rewrite. You cannot force authors to use new API instead of unique IF:M/Q/Custom dialog popup.
Doesn't CM:R work for witch huts?

Seer huts mod works only partially in 3.9.5. Dialog with huts and border gates shows fine, seer huts work as their position is stored in v6-v8 but border guards position is stored in v1-v3 and gets corrupted, no idea why...

I will try to change variables, but I don't remember very well how I coded the whole thing, was years ago
Note to myself, always put detailed comments to scripts for 50 years later.

Would help to know what changed, is v1-v3 handling different now? I am not even sure it is about those variables, maybe something else. Works fine on 3.0. Is it possible that when closing a DL now changes v1-v3?

v1 is used heavily for external function calls (SN:F, SN:E store result in v1). I would start trying to change v1..v3 to v2..v4 or v600.v602. Paste here of piece of code if it does not work.

Berserker, about pyramid's WoG objects
0040C577 - Lohook here for hint
00414F3C - hook here for rmc

Or just HiHook both hint handlers and create new Triggers
Cause the native hints works with better way imo

(07.07.2023 02:27)Berserker Wrote:  v1 is used heavily for external function calls (SN:F, SN:E store result in v1). I would start trying to change v1..v3 to v2..v4 or v600.v602. Paste here of piece of code if it does not work.

Well, from my tests closing the dialog corrupts v1-3. Here is the part of script storing quest guards coordinates



v1-v3 are not used in any of the additional actions, then when I close the dialog


I used debug messages and v1-v3 changes exactly when I press close dialog. Those scripts were modified now to v6-v8 and that fixed it. However now I should check all the mods using DL, unless there is another explanation which I can't find.

You close the dialog by pressing "Enter" key, which generates OnKeyPressed event. Any script, using v1..v3 may scree them. I thought we had "keyboard fixed.erm" script in many of your mods, saving v1..v10(?) before the first OnKeyPressed handler and restoring after.

There is a small issue with IF:D/E receivers

Many WoG scripters wrote their script by using 0 as the parameter for "nothing", like this one from the Emerald Tower script:
Sometimes they put nothing in it (Espionage script):

Most of the time these are ok. however, when you have another IF:D/F/E dialogue using the same dialogue ID, the problem comes. For example, execute this before the emerald tower script:
and you will see the Emerald Tower dialogue corrupted because both this script and Emerald Tower use the same dialogue ID 3.

This should not happen in ERA 3! We are free from remembering the used variable index, so should dialogue IDs.
I suppose ERA should support "0" or "nothing input" in IF:D/F for clearing the cache created in the previous erm executions.

Quote:Doesn't CM:R work for witch huts?

It does but when I have two IF:M from two different scripts, I can't disable one by CM:R0. Anyway think I have a solution.

Afair, there is no «cache». IF:D/F settings are just stored in global static arrays. Thus valid code should either use high level API or clear/overwrite the whole 16 parameters before showing dialog.
I would use ID = 1 in ERM Api, like it's done in RadioDlg_Show. Or, maybe, if GET syntax is supported, higher level API should save/restore DLG 1 settings.

See how RadioDlg_Show is implemented in EEF.

Quote:IF:D/F settings are just stored in global static arrays. Thus valid code should either use high level API or clear/overwrite the whole 16 parameters before showing dialog

Yup. If I understand your idea correctly, these examples from WoG Scripts can be fixed by:
It's fixable in the erm. Yet kinda clumsy in syntax. As I see those WoG scripters already treated 0 as a valid initialization. It would be good to support that usage.

As far as I see from erm.cpp and service.cpp the first time you call IF:D/F for certain dialog ID changes that dialog ID from UNSET to SET. The first time 0 works as empty string, the second time as "do not change".

Both IF:D3 and IF:F call the same function, but IF:F passes the first 10 arguments as 0. Because IF:F is called after IF:D, dialog is initialized and 0 is treated as "do not change".
I recommend something like:


Otherwise implement higher level api.

Well then I've already replace those with 0 with ^^ in scripts to make sure they don't have compaitiblity issue.

Any finding for SN:R replacing def frame with given png?

Bersy, I finished test, all fine. Would it be possible to add to the package Igrik's 2 plugins for battle replay -and battlesave)? I uploaded them here :

https://easyupload.io/rq0te9

I will wait for a link to final 3.9.5 then I will create a second link on my side too. Thanks

Quote:Bersy, I finished test, all fine.

Great news!

Battle Replay plugin usually needs ERM support for complex scripts/mods (special events like OnBeforeBattleReplay were added) because !?BA trigger handlers usually change global variables, which are not reverted by plugin. igrik, daemon_n and Archer fixed many wog scripts to support replays. So your custom maps logic may be broken after the first replay. I think BattleSave plugin is much safier.