Thanks, notnear!

I get what you're saying now. Even when I port into Cyrodil, the skill doesn't become unblocked until I move to a different zone. I guess I assumed that a zone change event would be triggered just by the act of porting into Cyrodil/IC

I should have just waited for Skill Blocker to eventually do the right thing as I moved to another zone, instead of checking immediately after entering Cyrodil/IC (and then just unblocking the skill myself altogether).

Thanks again for the explanation!

Hey notnear,

The following are the exact steps I used to reproduce the issue that I'm facing.

1. Exited game.
2. Told Minion to ignore updates for Skill Blocker.
3. Removed NearSkillBlocker folder from the AddOns folder.
4. Removed NearSkillBlocker.lua from the SavedVariables folder.
5. Installed Skill Blocker manually.
6. Started game and disabled literally every addon/library except for Near's Skill Blocker, LibSkillBlocker, and LibAddonMenu-2.0.
7. Logged into game in PVE zone (Vivec City).
8. Opened Settings->Addons->Near's Skill Blocker and set "Toggle block on PVP zones" to OFF.
9. Added Inner Light with the following settings:

• Block cast - ON
• Block recast - OFF
• Block in PVP - OFF

10. Inner Light is blocked as expected at this point.
11. Ported in to Imperial City Sewers.
12. Inner Light is still blocked at this point.
13. I ran reloadui and see that NearSkillBlocker.lua is created for the first time in the SavedVariables folder, with the following:

14. I opened up Settings->Addons->Near's Skill Blocker and saw that the settings have not changed. Strangely though, the Currently Registered list showed nothing.
15. However, Inner Light is no longer blocked in Imperial City Sewers.
16. I exited Imperial City Sewers and returned to Vivec City.
17. Inner Light remains unblocked.
18. I logged out of the game and log back in.
19. Inner Light is once again blocked in Vivec City.
20. I returned to IC Sewers and, again, Inner Light remains blocked.

Hi,

Thank you for this useful addon, and it has always worked as expected for me in PVE.
My issue has always been with PVP, where a skill would remain blocked in Cyrodil/IC even though I have "Block in PVP" turned OFF for that skill.

For example, these are my settings for Magelight:

and here I have "Toggle block on PVP zones" turned OFF:


Even with the above settings, Magelight would stay blocked even after I entered Cyrodil/IC. It would behave like this no matter how many times I changed "Toggle block on PVP zones" in the addon settings menu.

Today, I decided to finally assign a keybind to "Toggle PVP". Once I used the keybind to turn "Block in PVP" ON and then OFF (even in a PVE zone), Magelight remained unblocked as expected as I ported between Cyrodil and IC.

Unfortunately, I have to use the keybind to toggle "Block in PVP" ON then OFF each time I log into the game (or after a reloadui), since the addon appears to forget that "Block in PVP" is set to OFF when it reloads.

Hi, your savedvariables is not respecting the "server" and thus the same account on EU and NA server cannot have different settings.
Would have been cool if you add the GetWorldName() as 3rd param where currently the nil entry exists. This will create a subtable "NA Megaserver" or "EU Megaserver" or "PTS" instead if "Defaults" in the SV table.


Maybe a good time to do so now as you have reset the SV recently

Hi, great mod, works really well on sorcerer.
Is there a reason most of the self buff spells dont work on the dragon knight? i tested 3 spells (weapons, armor and the heart one) and only the armor buff spell worked.

Hi there, yeah my file hoster had some difficulties and I needed to reupload them and sync.
Here are the links again with the changes I did:
Skill Blocker - With global var fixes, LibAddonMenu LAM-PanelClosed callback and event filtering
https://drive.shadow.tech/s/LfTjbm7Q...n_Baertram.zip
LibSkillBlocker 1.0.7
https://drive.shadow.tech/s/45fHmXy3...cker_1_0_7.zip


Users reported me thought that it's still performance wise a mess with my version LibSkillBlocker_1_0_7 so 1_0_6 (which basically is the old 1_0_4) works best for the moment.
But AS this only seems to be a mess if "re Cast block" is enabled it's about your EVENT_EFFECT_CHANGED for sure, I'd say
So ths definately needs to improve and my event filters already helped there a lot I think -> only player effects tracked.

But maybe we can talk about that more in detail, to find out what other filters may help and how to improve this. And I'll also change LibSkillBlocker again and test what's the performance loss at the moment. Maybe the added "asserts" are, maybe other checks.

[quote=notnear]Hello Baertram, I'm taking a look at the things you listed but most of my code was while learning so I'll need some more help here.



All variables are global unless you define them as local, no matetr what the scope is (anonymous functions, outside of functions, within loops etc.). So ys, adding a local in front of the line fixes this as you only need the abilityId there I think, and the line where it's needed is within the same if ... end closure.

Making them local functions would be not the same as they would not be accessible from other addons then. But as you do not seem to need this it would be okay for your usecase! NEAR_SB is a global variable so all other addons would have acces to that table and it's contents, e.g. function NEAR_SB.EVENT_*whatever

Check my version, I've added an event filter on "player" already so only your own effect changes are tracked now and all ohers are skipped by C code already even ebfore it will be throwing any callback in lua code!
This definately makes a differenece as your code before was executed like every ms many times, for surround players buff changes, pets, companions etc. :-(

That's somethign you need to explain more in detail I think so I get the purpose. At best at gittereim/esoui, I saw you joined the channel. Will contact you there.

Hallelujah! I'm happy to see Baertram here because my game started performing horribly yesterday. At Alikr dolmens the frames would drop to zero and game would basically pause or black the screen until the dolmen was over. I started disabling addons and found this is the culprit! Hope you can fix it

Hi Notnear,

your addon is leakig many variables to the global namespace, and teh names of those are not unique, and should be fixed!
e.g.
All the variables buffName, timeStarted, timeEnding, _, stackCount, _, _, effectType, abilityType, _, abilityId, _, castByPlayer are global and overwrite other addons variables with the same name that way!

The other files also contain such global leaking ones.

Also your translation file en.lua contains strings like class, armor, weapon etc. which are provided by the game itsself already and thus are available in client languages de, en, es, fr, jp and zh via GetString constant: SI_SKILLTYPE1 to SI_SKILLTYPE6
If you change that you do not need to translate those anymore.


And your functions like OnPlayerActivatedAlive_EffectChanged should be added to your global variable NEAR_SB instead, OR at leasz contain some info where they origin from, like NEAR_SB_OnPlayerActivatedAlive_EffectChanged. At best add them to
NEAR_SB.OnPlayerActivatedAlive_EffectChanged instead of defining them globally like this. Makes no sense if you got 1 global where all shuld belong to, and one searches for.

Would be really happy if you could fix this.
Here is a version wtih those lines fixed/changed, and a German translation file de.lua adde.

It's UNTESTED so please test.

IMPORTANT - Performance:
I'm currentl checking why the version 1.0.5 of LibSkillBlocker drops FPS if your addon is enabled, even without actually blocking anything or wirhout pressing action buttons.
I think it's because your addon registers and unregisters LibSkillBlocker too often!

Currently if block recast is enabled it uses EVENT_EFFECT_CHANGED which will trigger for about EACH of your player buffs, and also buffs or group members, your pets, companins, and maybe even others (enemies)?
And in there, for each single buff update!, you call OnPlayerActivatedAlive_EffectChanged(), and this will recreate the functions buffs.class etc and update tables and then, each call!, will call your "addon:Initialize()" function which does the total LibSkillBlocker.Register and Unregister block again and again.

Imagine you got like 30 player buffs on you and that will trigger each second, or mabye more often this whole register and unregister?
Why is this needed for the skill blocks? Can't you change that to be more performant by any other way, like for AT LEAST only check the same buffId change every 1 second, or if the buffId is gained, and not if it's updated or fades away?
Maybe use event filter to only check your player buffs at least and only some of them?

This will speed it up a lot already:
https://wiki.esoui.com/AddFilterForEvent
with e.g. REGISTER_FILTER_ABILITY_ID and/or REGISTER_FILTER_SOURCE_COMBAT_UNIT_TYPE
Also 2nd parameter "changeType" could be checked against EFFECT_RESULT_GAINED etc.


Please find my changed files with example about the event filtering etc. here:
Skill Blocker Baertram with event filters and LAM panel close callback

And here is an updated version 1.0.7 of LibSkillBlocker with some more performance improvements. Hopefully it will fix the issues too somehow:
LibSkillBlocker 1.0.7

If you want to talk about it you can reach me/us here:
https://app.gitter.im/#/room/#esoui_esoui:gitter.im

Hope it will fix a bit the performance and help as currently it seems to just run the addon:initialize() function WAY too often
I'd improve that, if possible. Registering/Unregistering the abilityIds should only happen once they are added to the settings menu (and that as the settings menu closes so your addon:initialize() function onlyruns once and not for each added skill once! -> You can use LibAddonMenu's callbacks for that, there is the LAM-OnPanelClosed callback e.g.!) and once at the event_player_activated I'd recommand.

And if this skill recast block really needs to keep track of all effects (Wouldn't it be enough to track the abilityId at the action slot button pressed and if someone tries to press it again it forbids this? Maybe we can add another API function to LibSkillBlocker for that so that you just register a block, and the lib checks if you are trying to press the same action button again, where the same abilityId that last time was used is still available).

All, How come I am only able to block the recast of some skills and not others?

For example, Bladecloak can be blocked from recast but mystic orb will not be

does they type of skill matter ?