• 0

    posted a message on Scanning tooltips and interface lockup
    Here is the original code for reference, with the function in question highlighted:
    https://github.com/dpatti/AllTheLittleThings/blob/d3a93d36b1878a736b696a6d5c118aae846561e2/modules/rewards.lua#L132

    I created a small addon whose purpose is to alter the coloring on the quest rewards further based on armor proficiency and a custom stat filter. After writing it, I noticed that each time you get a new quest, the UI locks up for a fraction of a second and then all the icons and names of the rewards display. I assume this is because the items are not in my cache yet and it had to get them in order to scan the tooltips.

    My confusion is how this exactly works. My first revision used a for loop over each of the items in the quest rewards window and scanned each one. I execute this loop in a post-hook for QuestInfo_ShowRewards. This worked, but as I said, it came with a small period of interface lockup. My second solution was to wrap the inside of the for loop with:

    self:ScheduleTimer(function()
        -- ...
    end, 0)


    using AceTimer-3.0 (commit here). To my surprise, this worked fine but left no noticeable interference with the interface. Sure, there was sometimes a slight delay in applying the extra markings, but everything was still usable. I simply don't understand why this difference changes anything. My thought was that AceTimer would just execute all the code on the next frame since the time was set to 0, so it would have the same effect as my original method. If anyone could clear this up for me, I would be grateful.

    In addition, if anyone has any better ideas on how to implement this, I would love to hear it. I feel like throwing a timer in is ugly at best.
    Posted in: Lua Code Discussion
  • 0

    posted a message on LibDataBroker Rift Port
    Quote from myrroddin
    Why should the file be called "LibDataNroker-1.0.lua" instead of "LibDataBroker-1.0.lua"?

    He was pointing out that it has no .lua extension in the zip file you posted.
    Posted in: Lua Code Discussion
  • 0

    posted a message on Calling LoadAddOn in OnEnable breaks some ADDON_LOADED calls?
    Okay, once more. I need to work on my explanations.

    The event is never registered at all. This is especially troubling with AceEvent, because after it thinks it registered it, it will not try again for any subsequent addons yet it will never receive any calls to pass on to the addons.

    And also remember that this is not necessarily in your addon. If you are registering the event and someone else is loading the addon and you both use Ace, there is a chance that you will be affected.
    Posted in: Lua Code Discussion
  • 0

    posted a message on Calling LoadAddOn in OnEnable breaks some ADDON_LOADED calls?
    Yeah, basically IsLoggedIn() returns true before PLAYER_LOGIN fires, which means an ADDON_LOADED event can trigger the enabling of addons, and while this probably doesn't matter 99% of the time, it makes a difference here for whatever reason.

    There is no real solution (unless Ace3 removes IsLoggedIn() completely and instead sets a flag when the PLAYER_LOGIN event fires), but there are easy ways to prevent it, such as registering ADDON_LOADED in OnInitialize only or not using LoadAddOn anywhere in OnInitialize or OnEnable.
    Posted in: Lua Code Discussion
  • 0

    posted a message on Calling LoadAddOn in OnEnable breaks some ADDON_LOADED calls?
    Ah, okay, I was under the assumption that GetTime() only updated once every frame. Using your script it appears that they both fire on frame 0 regardless of how many addons are loaded, which makes sense.

    Be that as it is, the order in the chat log always prints:

    Enabling Addons (IsLoggedIn() returned true)
    PLAYER_LOGIN fired
    Posted in: Lua Code Discussion
  • 0

    posted a message on Calling LoadAddOn in OnEnable breaks some ADDON_LOADED calls?
    Okay, I think I finally resolved it after cutting down AceAddon bit by bit.

    Firstly, my summarized description of the bug:
    If you call LoadAddOn() before PLAYER_LOGIN has fired, any frames that attempted to register ADDON_LOADED in the execution path before the LoadAddOn() call will silently fail to register.

    And here's the reason why I observed it in AceAddon:
    For some reason, IsLoggedIn() is reporting true before PLAYER_LOGIN fires. Doing a simple print during both the iteration of the enablequeue and when PLAYER_LOGIN fires, you can note that the enablequeue is done first with a difference in GetTime(), which likely means they're at least 1 frame apart. In most cases this difference of API and event might not matter, but as far as I can tell this is what is causing the above bug.
    Posted in: Lua Code Discussion
  • 0

    posted a message on Calling LoadAddOn in OnEnable breaks some ADDON_LOADED calls?
    I'm not sure what you just asked there.

    I think the bottom line is that registering is pretty safe in OnInitialize, since AceAddon should usually (always?) only initialize one addon at a time.

    However, another surprising note that I didn't investigate too thoroughly yet. When I run this code in contrast to the code in the original post, it works. As far as I know, this is simulating the OnEnable in AceAddon (only as far as which events trigger which functions), but for some reason it is different:
    local aceFrame = CreateFrame("Frame")
    local addonFrame = CreateFrame("Frame")
    
    -- Simulating Ace framework
    aceFrame:SetScript("OnEvent", function(self, event, ...) 
        addonFrame:OnEnable(...)
    end)
    aceFrame:RegisterEvent("PLAYER_LOGIN")
    
    -- Simulating addon
    addonFrame:SetScript("OnEvent", function(self, event, ...) print("addonFrame:", ...) end)
    function addonFrame:OnEnable(...)
        self:RegisterEvent("ADDON_LOADED")
        LoadAddOn("Blizzard_AuctionUI") 
        -- ADDON_LOADED is successfully registered and prints as expected
    end


    I thought it might have something to do with the safecall, but even removing that in AceAddon does not change it. It sounds like there is something in between this example and the first one I posted that causes this bug.
    Posted in: Lua Code Discussion
  • 0

    posted a message on Calling LoadAddOn in OnEnable breaks some ADDON_LOADED calls?
    Like I said, I'm not loading anything. Another Ace addon is though, and it is conflicting with my RegisterEvent().
    Posted in: Lua Code Discussion
  • 0

    posted a message on Calling LoadAddOn in OnEnable breaks some ADDON_LOADED calls?
    One more thing to report. If you iterate over GetFramesRegisteredForEvent() after the code I initially posted, you will note that none of the frames are listed, including AceEvent30. If you have another AceEvent-3.0 addon that registers ADDON_LOADED earlier and successfully, obviously all other Ace3 addons will work fine. However, if the addon that registers ADDON_LOADED first fails, no other addon will get dispatches from AceEvent because it thinks it is already registered.

    I should also note that anything registered after the LoadAddOn() is called will still be successful. Only ADDON_LOADED registrations before a LoadAddOn call in the same execution path will fail.
    Posted in: Lua Code Discussion
  • 0

    posted a message on Calling LoadAddOn in OnEnable breaks some ADDON_LOADED calls?
    Actually, now that I tested it, I can confirm that the problem persists. For example, change the above code from OnEnable to OnInitialize and the exact same thing happens.

    That said, this might still fix the original problem where the LoadAddOn call is in another addon. For example, if we moved both the RegisterEvent and LoadAddOn calls to OnInitialize in each addon, it would work fine.

    Printing out the loading steps in AceAddon-3.0 proves this, I think. Each time the "onEvent" function is called, it processes the queues for initialize and enable. Through printing, you can note that each addon is initialized in a (usually?) different event call, while at the end, all addons are enabled at the same time. My theory then, is that for some reason, using RegisterEvent("ADDON_LOADED") and LoadAddOn() in the same event execution path will cause it to not correctly register.
    Posted in: Lua Code Discussion
  • 0

    posted a message on Calling LoadAddOn in OnEnable breaks some ADDON_LOADED calls?
    Maybe I wasn't clear, but it doesn't fire for any future ADDON_LOADED events, not just the one that was specifically being loaded. Visiting the guild bank or opening the achievements pane for the first time will not produce anything like they should.

    And you're right, moving it to OnInitialize would work fine, but I am mostly curious what is going on, as it doesn't seem intended.
    Posted in: Lua Code Discussion
  • 0

    posted a message on Calling LoadAddOn in OnEnable breaks some ADDON_LOADED calls?
    I can't fathom what is going on at all here. I isolated the problem down to this sample addon. These few lines of code plus the latest Ace3 are the only two addons I have running right now.

    local core = LibStub("AceAddon-3.0"):NewAddon("Test", "AceEvent-3.0")
    local frame = CreateFrame("Frame")
    frame:SetScript("OnEvent", function(self, ...) print("CustomFrame:", ...) end)
    
    function core:OnEnable()
        print("Test OnEnable")
        self:RegisterEvent("ADDON_LOADED", function(...) print("AceEvent:", ...) end)
        frame:RegisterEvent("ADDON_LOADED")
        LoadAddOn("Blizzard_GuildUI")
    end
    


    Here I have two event handlers set up: one using AceEvent-3.0 and one using a custom frame with a SetScript. If you run this script, you should see output for each addon that is loaded, but the only thing that prints is "Test OnEnable". Neither event handler receives an ADDON_LOADED event. If you move the RegisterEvent() call out of OnEnable, it will work correctly. Even stranger though, if you comment out the LoadAddOn call, once again everything works fine.

    I discovered this problem when someone used one of my addons that registered ADDON_LOADED in OnEnable with an unrelated addon that called LoadAddOn in its OnEnable handler, causing my event to never fire.

    What is going on here?
    Posted in: Lua Code Discussion
  • 0

    posted a message on NewModule help?
    http://www.wowace.com/addons/ace3/pages/ace-config-3-0-options-tables/#w-common-parameters

    This is a good resource for learning how to use AceConfig. As you can see, there is a common parameter "hidden" which can take a function. So something like:

    ActionBars = {
    	name = "ActionBars",
    	type = "group",
    	hidden = function() return not db.ModuleActionBars end,
    	...
    }


    And then you can make a toggle to turn on/off db.ModuleActionBars.
    Posted in: Lua Code Discussion
  • 0

    posted a message on Registering for a custom event?
    I believe you are looking for:

    function ABS:WOWLUA(event, name)
            print ("ABS: MPS loaded!!")
            print (name)
    end
    
    ABS:RegisterMessage("Profiles_Macros_loaded", "WOWLUA")


    The registration doesn't need to know about the arguments about to be passed. What you pass to SendMessage will be recieved in the registered callback.
    Posted in: Lua Code Discussion
  • 0

    posted a message on Hide Target/Focus Buffs+Debuffs
    /dump MAX_FOCUS_DEBUFFS returns nil for me, while the other two globals you use return integers. This strikes me as odd, though, as it looks like a global variable is set on line 1 of FocusFrame.lua?
    Posted in: Lua Code Discussion
  • To post a comment, please or register a new account.