--oqueue fix
--from 24329
  local i, p ;
  for i,p in pairs( frame._ilevels ) do
    if (is_on == 1) then
      frame:Show() ;
    else
      frame:Hide() ;
    end
  end
 
--from 24450
    for k=1,5,1 do
        if (p) then
          if (p.gem) and (p.gem[k]) then
            if (#p.gem <= k) then
                p.gem[k].texture:SetTexture(nil) ;
                p.gem[k]:Hide() ;
            end
          end
        end
    end

--from 24384
    if (#p.gem <= n) then
        p.gem[n]._ilink = enchant_text or "" ;
            if (e_id == 0) then
                p.gem[n].texture:SetTexture( OQ.ENCHANT_SLOT[1] ) ;
                p.gem[n].texture:SetAlpha( 0.4 ) ;
            else
                p.gem[n].texture:SetTexture( OQ.ENCHANT_SLOT[1] ) ;
                p.gem[n].texture:SetAlpha( 1.0 ) ;
            end
            p.gem[n].texture:Show() ;
            p.gem[n]:Show() ;
            return 1 ;
    else
        return 0
    end

--24360
    if (#p.gem <= n) then
        p.gem[n]._ilink = ilink ;
            if (p.gem[n]._ilink == nil) then
                if (color) then
                  p.gem[n].texture:SetTexture( OQ.EMPTY_GEMSLOTS[ color ] ) ;
                else
                  p.gem[n].texture:SetTexture( OQ.EMPTY_GEMSLOTS[ "unk" ] ) ;
                end
            else
                p.gem[n].texture:SetTexture( select( 10, GetItemInfo(p.gem[n]._ilink)) ) ;
            end
            p.gem[n].texture:SetAlpha( 1.0 ) ;
            p.gem[n].texture:Show() ;
            p.gem[n]:Show() ;
    end

 

well, less fixed, and more just made it go away until you fix it

i have no idea how it's even possible to get into a situation where the core table is nil... but i put in the checks.

thx!

look for the updates in 1.8.6a

btw, if you can figure out what's making memory usage move around, i'd be very grateful

as far as i can tell, i'm recycling all tables as best i can.  yet it seems the memory keeps tweaking.

i've wondered if its an artifact on how blizz does it's strings. 

hmmmm, ill look, but, no guarantees lol

oh and i love this addon :)

Yeah, its been a while since the last post, but i still haven't really looked through much.

I'm assuming you know this already, but its the only thing i can think of for tables being inexplicably empty.

if i were to hazard a guess; as far as the main table, or any table, being nil with no apparent reason, is because the wipe function wipes all connected tables.

so say you did.

t = {a,b,c}
t2 = {aa,bb,cc}
t3 = {t, t2}

wipe(t3)

t and t2 would also get wiped out too. and i dont just mean that t3 would be nil, but the a,b,c in t and the aa,bb,cc in t2 would also be nil, so you would end up with

t = nil
t2 = nil
t3 = nil

so, i try not to use that function

if you have tables within tables and you only want just one inner table changed. i usually setup a temp table, populate it with the data from the table within a table, manipulate the temp table, then replace the data in the main container table with the temp table data.

t1 ={1,2,3}
t2 ={1,2,3}
t3 ={1,2,3}

main = {t1,t2,t3}
temp = main[1]
local i

for i = 1, #temp do
temp[i] = blah
end
main[1] = temp
temp = {}

------------
the result would be:
t1 = {blah,blah,blah}
t2 = {1,2,3}
t3 = {1,2,3}
------------

also, using for loops that iterate to a maximum value of a table is better than using static numbers imo. then, in the event of a miscalculation somewhere along the lines, the addon wont come to a hard stop and makes the whole thing more fluid. for example: instead of coding for just 2 gems or 3 gems, if wow ever decided to add 100 gems... its just a matter of a few code tweaks vs a major overhaul.

the safest way to wipe a table and ensure that only the specified table gets cleared is

temp = {}