Maybe this?
Assumes that mouse click will have the same result with mouse hint wait it won't
Nope, click is click, hint is hint. You can add to both events to be able to differentiate hints for active and non-active player.
Archer30, great. Now it will be much easier to add check. Will add to Era log too.
What's about hotseat? Seems like we should check game type for network gaming or at least add check for hotseat too.
hotseat, battle against AI => true if non-AI active
hotseat, human vs human => always true
single player => true if non-AI active
network battle => true if this PC player active
Code:
[+] Added the following global variables to Era Erm Framework:
i^battle_isThisPcActive^: bool. Used in battle hint and battle click events to allow GUI interaction or display action hint for active GUI user.
Single player, Hot seat => TRUE if active side is human
Multiplayer => TRUE if active side is this PC human
Logic looks great. Script is ready?
Will send you soon updated EEF.
I propose to add a new function to be added in EEF.
A simple function to check if a monster is disabled in most events like a random monster encounter in Souting II events.
The default monsters to be disabled are those that should never appear in the hero army slots plus emissaries.
The function result can be modified by mod makers. They can define their disabled monsters, usually some boss creatures that should not appear elsewhere.
This function can help build mod compatibilities. For example, to disable a new monster added by typhon to appear in all those WoG Scripts events, we only need to change the result here, and then it applies everywhere.
(18.05.2024 19:16)Archer30 Wrote: [ -> ]This function can help build mod compatibilities. For example, to disable a new monster added by typhon to appear in all those WoG Scripts events, we only need to change the result here, and then it applies everywhere.
Привязка к номерам монстров - чудовищные костыли. Так ещё и плюс к несовместимости с ERA+ заработаете с помощью ERM. Почему не можете посмотреть в коде игры содовский способ проверки генерации случайного монстра?
Игра проверяет мин. и макс. количество монстров на карте и если там нули, то монстр не генерируется. Так же точно можно проверять генерируемость монстра с помощью ERM.
Archer30, I agree with Heromant, that universal checking of MinAdvMap and MaxAdvMap values is better (if commanders and emissaries have proper zero values)
I would call the function something like MonsterIsAdvMapGeneratable.
The function is meant to be used by different scripts/mods so we don't have to deal with checking again and again.
And you can initiate the fancy check in this function as well.
It only gives a standard so everyone can use the same function to check. If the function returns the positive (disabling) result, it means one of the mod components doesn't want a monster to appear in most events, and thus other scripts can respect the result here.
___
Well, assuming all those monsters we don't want to use have the correct MinAdvMap and MaxAdvMap values, I think my proposal is abundant. We have a handful of mods, I will try to go through each of them and see if they are correct.
____
Well, just rethink about it, and I feel the idea of MinAdvMap and MaxAdvMap values is not perfect. There was a time I set MinAdvMap and MaxAdvMap values to 0, and then players came back and said they found it weird - when they put such a creature on the map by map editor, the quantity of it is 0 by default (when they attack it in the game).
If ERA introduces a mechanism to correct the adv stack number with <=0 to 1, I can set MinAdvMap and MaxAdvMap values to 0 without worry.
In conclusion, two ways:
- Use MinAdvMap and MaxAdvMap values as a reference, correct all the existing mods, ERA should set adv creature number at least 1
- Intorduce a function in EEF and use it to check if a monster should be ignore
Is there a list of era hooks placed in the game, especially for different era triggers (events)?
Somewhere from era source?
I reckon this would be handy:
Apart from what we have in ...\Debug, attach a most recent save game in this folder (save the last loaded save game filename in the memory beforehand, and copy the save game file to this folder when the game crashes or F11).
This can be helpful when players are not experienced in bug reporting. Sometimes when the save games are in different names (.CGM for campaigns, .GMx for single-player scenarios), this helps save the exact save game we need.
What do you think?
Latest savegame may be not responsible for the bug if older savegame is loaded. Moreover, BattleSave plugin makes new savegame right before each battle, while it may be better to load original savegame before hero moving. Additionally, bug reports will grow in size. Do you think it will simplify bug reporting greatly without false positives?