Today I decided to drop few of my UI addons and script my UI. I created all scripts into macros and it worked well, but pressing 15 or so macros every relog/log in is an overkill imo. Then I decided to create addon based on my scripts, most of my macros turned into addon super smooth - copy, paste, delete “/run”, done. But one of my working macros doesn’t work at all when turned into an addon, and another makes other addon not working properly.
working macro to scale my frames /run PlayerFrame:SetScale(1.13) /run TargetFrame:SetScale(1.13) /run FocusFrame:SetScale(1.13)
not working addon
local frame=CreateFrame("Frame");
frame:RegisterEvent("VARIABLES_LOADED");
frame:SetScript("OnEvent",function(self,event,...)
PlayerFrame:SetScale(1.13)
TargetFrame:SetScale(1.13)
FocusFrame:SetScale(1.13)
end);
working addon to move and scale objectives frame
local frame=CreateFrame("Frame");
frame:RegisterEvent("VARIABLES_LOADED");
frame:SetScript("OnEvent",function(self,event,...)
ObjectiveTrackerFrame:ClearAllPoints()
ObjectiveTrackerFrame:SetPoint("RIGHT", UIParent, "CENTER", 850, 230)
ObjectiveTrackerFrame.SetPoint = function() end
ObjectiveTrackerFrame:SetScale(0.9)
end);
But after using this one World Quest Tracker addon detaches from objectives frame and places itself in top right corner.
Any chance to make frame scaling addon to work and make WQT addon to stay atached to objectives frame even tho I use macro/addon to move and scale objectives frame?
Also if possible I’d like to make objectives frame hide during arena, bgs and maybe dungeons.
Have you tried using PLAYER_ENTERING_WORLD instead of VARIABLES_LOADED?
You could also try and put WorldQuestTracker (if that’s the folder name) as an optional dependency in the TOC file of your addon: ## OptionalDeps: WorldQuestTracker
Then your addon gets loaded after WorldQuestTracker.
You have to put it in the .toc file of your addon.
A safe but somewhat CPU time wasting method would be this:
local myCheckFrame = CreateFrame("Frame")
myCheckFrame:SetScript("onUpdate", function()
if IsActiveBattlefieldArena() or UnitInBattleground("player") ~= nil then
if someFrame:IsShown() then
someFrame:Hide()
end
else
if not someFrame:IsShown() then
someFrame:Show()
end
end
end)
lf you want to make this less CPU time wasting, replace onUpdate with onEvent and register all the events at which you want to check whether you are in arena/bg.
Thanks, it fixes the problem with WQT. I just noticed that moving my objectives frame makes it showing only 2 random quests from my whole quest log, however if I only change frame scale it still shows every quest i have.
Appreciated, I will test it, if that would consume too much power I will get rid of this one, but still good to know. Could that code work for party frames too? I mean if I’d change it a bit, could I reposition and rescale my party frames depending if I do arena, bg or m+?
You can put whatever you want in place of someFrame:Show() and someFrame:Hide().
If you use “onUpdate”, the code will be executed in every rendered frame (as in FPS) of the game. That’s why I meant it is safe, because you will definitely not miss showing or hiding your UI frames (not as in FPS) (or whatever you are doing). But this is obviously a lot more often than only executing it once upon the events of reloading or leaving/entering a battleground. You would have to find out what these events are (see below).
But also notice that “wastefully” executing this code in every frame is probably just taking a fraction of what your PC is doing to calculate a single pixel in the 3D engine. So you would not notice it in your electricity bill. Still it is better programming style to do it event-based.
You can learn about in-game events using WoW’s event trace.
To open it, type this into the console:
/eventtrace
You have to manually scroll down after the window first opens. Then you can use these commands to stop and start the logging:
/eventtrace stop /eventtrace start
If you want to get serious with the event trace, put these two commands into macros and keybind them, so you can stop and start quickly.
A list of all possible events can also be found here: https://wow.gamepedia.com/Events
I tried that script to hide objectives frame, and idk if that’s placebo or my wifi (yes i was testing on wifi not cable) but looks like the game wasn’t as responsive as before that script. I will test that again via cable connection, hope that solves my problem.
If addons are trying to squeeze in too many operations, the only effect should be an FPS drop. So if your FPS are still fine, the cause for reduced responsiveness must be something else.
FPS droped for like 10 FPS but looting mobs, NPC respond to talk/buy/sell was significantly slower. But that was during world boss and on wifi so that might cause the problem.
The only problem with working addon/script I encounter right now is notice poping up from time to time that interface failed because of an addon, mostly when I set focus target.
By “10 FPS drop” do you mean something like 240 down to 230 or rather 60 down to 50? The former is of course more likely to happen. But if an addon brings you a constant FPS drop of more than 5%, I would abandon it. I doubt, however, that the onUpdate script I gave you would cause something like that.
A lag of looting, NPC interaction etc. must be due to your connection with the server. There is nothing an addon could really break there, unless it is explicitly designed to do so.
Regarding “interface failed because of an addon”: this probably happens when you try to show() or hide() protected frames during combat. To check if a frame is protected you can use someFrame:IsProtected(). To prevent your script from trying these operations on protected frames, you can check InCombatLockdown() before doing the show() or hide().
“Interface failed because of an addon” could also happen, because a frame you modified is now “tainted” and therefore the stock UI of WoW also cannot work with it any more during combat. You should get the addons BugSack and BugGrabber which let you see more information about the causes of “Interface failed because of an addon” errors.
Still it is better programming style to do it event-based.
