• 0

    posted a message on Does AceComm protect the receiving end too?
    Well, do you expect a response to your addon message? I.e. when you log on and emit your "hi there" message, will your addon (if every client uses it) cause an automatic reply? Then just think about big guilds (200+ members if they even exist). You log on and send 1 message and receive 200 message back, all at the same time. This could disconnect you.
    Posted in: Libraries
  • 0

    posted a message on Does AceComm protect the receiving end too?
    If too many clients all at the same time send messages to the same reciepient, then that recipient will most likely get disconnected to to having their receive buffer filled (or rather the servers send buffer to that client is full). So, if an addon is designed to e.g. send a message a new player logging on and everyone in a large guild does that, new players would probably get disconnected as soon as they log on. The addon need to spread out the "hi there" message so the clients wont be sending them at the same time (or find another way to accomplish the message).

    In GuildAds, this is handled by spreading out the messages in time (login "Hi there" message) and also in structure (clients A and B whisper C, clients D and E whisper F, clients C and F whisper G and G broadcasts a combined message. No clients is mass-messaged that way. Used for data searches.).
    Posted in: Libraries
  • 0

    posted a message on PeriodicTable-3.1
    Original function:

    function multisetiter(t)
        local k,v
        if iterpos then
            -- We already have a position that we're at in the iteration, grab the next value up.
            k,v = next(t[iternum],iterpos)
        else
            -- We havent yet touched this set, grab the first value.
            k,v = next(t[iternum])
        end
        if k == "set" then
            k,v = next(t[iternum], k)
        end
        if k then
            -- There's an entry here, no need to move on to the next table yet.
            iterpos = k
            return k,v,t[iternum].set
        else
            -- No entry, time to check for a new table.
            iternum = iternum + 1
            if not t[iternum] then
                return
            end
            k,v = next(t[iternum])
            if k == "set" then
                k,v = next(t[iternum],k)
            end
            iterpos = k
            return k,v,t[iternum].set
        end
    end
    For now I have fixed the function this way:

    function multisetiter(t)
        local k,v
        repeat
            if iterpos then
                -- We already have a position that we're at in the iteration, grab the next value up.
                k,v = next(t[iternum],iterpos)
            else
                -- We havent yet touched this set, grab the first value.
                k,v = next(t[iternum])
            end
            if k == "set" then
                k,v = next(t[iternum], k)
            end
            if k then
                -- There's an entry here, no need to move on to the next table yet.
                iterpos = k
                return k,v,t[iternum].set
            else
                -- No entry, time to check for a new table.
                iternum = iternum + 1
                iterpos = nil
            end
        until not t[iternum]
    end


    Want me to commit it? (if I can)
    Posted in: Libraries
  • 0

    posted a message on PeriodicTable-3.1
    The problem occurs in multisetiter as far as I can tell. The issue is with this part of the code:

    -- No entry, time to check for a new table.
            iternum = iternum + 1
            if not t[iternum] then
                return
            end
    With the current data, several sets in a row can be empty and that will trigger an early return in the above code. What it should do is loop until a non-empty set was found or there are no more sets to look at.

    Or the data should be fixed to not include empty sets.

    Edit: I am not sure what to fix (or if I should fix this at all?)

    Edit2: The above is probably not the reason for the early exit, but it seems to be in that function somewhere...
    Posted in: Libraries
  • 0

    posted a message on PeriodicTable-3.1
    Seems the issue is with the some local function in LibPeriodicTable-3.1.lua. The issue is a result of the new data in LPT-3.1-TradeSkillResultMats, or rather, the missing data, e.g.:

    ["TradeskillResultMats.Forward.Tailoring.Spellfire"]="",

    Such an empty set causes an early exit somewhere in LPT and I am not sure where yet.

    But is the code wrong or is it not "allowed" to push empty sets to LPT?
    Posted in: Libraries
  • 0

    posted a message on PeriodicTable-3.1
    I have hit an issue with the latest LPT. This used to work:

    for item, items, set in LibStub("LibPeriodicTable-3.1"):IterateSet("TradeskillResultMats.Reverse") do

    but this iterator doesn't iterate over anything anymore. Changing TradeskillResultMats.Reverse to TradeskillResultMats.Reverse.Alchemy does iterate over the Alchemy items, though. How do I make LPT iterate over all of TradeskillResultMats.Reverse?
    Posted in: Libraries
  • 0

    posted a message on wget function
    To get limited on-demand data loading you could create e.g. 10 addons that all are load on demand. Their toc file is read upon load, but the lua load is delayed until the addon is requested. You just can't signal out of wow that you want to load new content, but it could be on a timer (e.g. load new data every hour for the next 10 hours). This would need a timed file update for each of the 10 lua files.
    Posted in: Lua Code Discussion
  • 0

    posted a message on When are Glyphs ready to be read?
    Quote from Adirelle
    You can't. But the PLAYER_ALIVE event is fired anyway.


    PLAYER_ALIVE is not fired after a /reloadui.
    Posted in: Lua Code Discussion
  • 0

    posted a message on When are Glyphs ready to be read?
    Quote from watchout
    How about GLYPH_UPDATED ? I have not tried it, though it sounds like the thing


    I have tried listening for all GLYPH_* events but none are triggered upon login.
    Posted in: Lua Code Discussion
  • 0

    posted a message on When are Glyphs ready to be read?
    Glyphs appear to be available at the PLAYER_ALIVE event. But how do I detect if a session is caused by /reloadui or at clean login?
    Posted in: Lua Code Discussion
  • 0

    posted a message on When are Glyphs ready to be read?
    The problem is to determine if glyph information is available or not... ;-)

    I just tried this little script:

    local function glyphtest() 
        ChatFrame1:AddMessage("glyph changed");
    end
    
    local     frame = CreateFrame("Frame", nil, UIParent)
        frame:SetScript("OnEvent", glyphtest)
        frame:RegisterEvent("GLYPH_CHANGED")
        frame:RegisterEvent("GLYPH_ADDED")
        frame:RegisterEvent("GLYPH_REMOVED")
        


    I never get to see the message "glyph changed" in my chat window when I log in... it does fire upon talent spec change, though.

    I guess these events do not fire upon login and I therefore could use some other event to listen for...
    Posted in: Lua Code Discussion
  • 0

    posted a message on When are Glyphs ready to be read?
    Thanks. My problem is that I have 1 function to gather both talents and glyphs and store it as 1 string. I guess I have to break it into 2 functions somehow.
    Posted in: Lua Code Discussion
  • 0

    posted a message on When are Glyphs ready to be read?
    I have a problem with reading the Glyphs upon login. Currently I wait for either CHARACTER_POINTS_CHANGED or PLAYER_TALENT_UPDATE and then issue an 8 second timer after which I read the glyph information (using GetGlyphSocketInfo) but quite often, players using my addon experience that the glyphs are unavailable at that time (resulting in no glyphs recorded, no error it produced).

    So I wonder if anyone can let me know when the glyph information is ready to be read?
    Posted in: Lua Code Discussion
  • 0

    posted a message on Causing wow freeze, but only on XP
    Thank you for the hints. I am however not sure what animations SickOfClickingDailies uses and how the bug was walked around (if it even exists anymore).

    I do believe my issue is related to the channel management with GuildAds and as such I think I'll have to temporarily insert code to avoid function reentry. This should hopefully break infinite loops if they occur in GuildAds' code.
    Posted in: Lua Code Discussion
  • 0

    posted a message on Causing wow freeze, but only on XP
    I have finally received a report that the lockup also has occured on Vista and as such has to be a bug in my code and not the wow client itself. Vista/Win7 is just not triggering that bug very often seeing as I only have gotten one report.

    However, because of the need to kill wow, I can't store any data anywhere. And I can't print anything to the screen because wow locks up prior to printing anything. This makes this problem really hard to debug. :-(

    Any idea short of using a shotgun approach? (try to change stuff somewhere more or less random, test, change somewhere else, test, and so on).
    Posted in: Lua Code Discussion
  • To post a comment, please or register a new account.