ESOUI - V1.2.3 API Patch Notes & Change Log

ESOUI (https://www.esoui.com/forums/index.php)

- General Authoring Discussion (https://www.esoui.com/forums/forumdisplay.php?f=174)

- - V1.2.3 API Patch Notes & Change Log (https://www.esoui.com/forums/showthread.php?t=1865)

Cairenn

06/27/14 03:44 PM

V1.2.3 API Patch Notes & Change Log

1 Attachment(s)

Updated API Version to 100007

First off, this patch has introduced a few bugs that the development community has been very helpful in addressing. Thanks for your help; we apologize for any inconvenience the issues create. The main bugs are related to displayName not being set properly, which leads to saved variable table corruption as well as some Lua table serialization issues with long strings and improperly escaped character sequences. Both of those issues are in the process of being fixed now, and we hope to take care of them quickly.

While we work on new systems, you’ll notice new, non-functional APIs appear. This time we've been working on some upcoming features for the dye, guild heraldry, guild trader, and chat bubble systems. To support the features of systems that use dyeing, a new control type called TextureComposite was added. It supports rendering multiple layers of textures within a single control for optimization reasons.

Changed Globals

Unit reaction types have been changed to remove “dead” and “interact” and instead only include typical reaction types (friendly, hostile, neutral, etc.).
The ExperienceReason and VeteranPointReason enumerations have been consolidated into a single ProgressReason.
The ItemTypes enumeration has been updated to include some new types and to differentiate between enchanting rune types.
Added some new mouse cursor types in support of upcoming features. Some are already usable in-game (for things like Map Panning and Character Rotation).

Added Functions

Player reporting is improved with a new “quick report” feature. Bots and spammers can be reported from chat, mail, and in-world. When a quick report is filed against a player, they're added to a per-session filter that prevents their chat from appearing on your client. The per-session ignore list can be managed with:

SetSessionIgnore(playerName, isIgnored)
ClearSessionIgnores
SubmitSpamReport(userName, reason) can be used to report a player for behavior reasons.

Chat logging got a minor improvement with the following functions (ToggleChatLog has been removed):

SetChatLogEnabled(isEnabled)
IsChatLogEnabled()

To prevent too many guild store queries in a short period of time, there's a cooldown period on searches. Check it with GetTradingHouseCooldownRemaining(), which returns the number of milliseconds remaining until the next search is legal.

Added GetKeyboardLayout in case the system keyboard type changes. This is primarily a notification function; currently, only generic layout types that match ESO's supported locales are used.

EULA details can now be queried in-game (exciting, we know):

message, agreeText, disagreeText, hasAgreed = GetEULADetails(eulaType)
HasAgreedToEULA(eulaType)
AgreeToEULA(eulaType)
HasViewedEULA(eulaType)
MarkEULAAsViewed(eulaType)

The mail API has been extended to include:

displayName, characterName = GetMailSender(mailId)
numAttachments, attachedMoney, codAmount = GetMailAttachmentInfo(mailId)
unread, returned, fromSystem, fromCustomerService = GetMailFlags(mailId)

The progression API has been extended to include:

xpAmount = GetNumExperiencePointsInLevel(level)
vpAmount = GetNumVeteranPointsInRank(veteranRank)

Added/Modified Events:

EVENT_DISCOVERY_EXPERIENCE (areaName, level, previousExperience, currentExperience)
EVENT_EXPERIENCE_GAIN (reason, level, previousExperience, currentExperience)
EVENT_GROUP_MEMBER_IN_REMOTE_REGION (unitTag, isInRemoteRegion)
EVENT_LORE_BOOK_LEARNED_SKILL_EXPERIENCE (categoryIndex, collectionIndex, bookIndex, guildIndex, skillType, skillIndex, rank, previousXP, currentXP)
EVENT_LORE_COLLECTION_COMPLETED (categoryIndex, collectionIndex, guildIndex)
EVENT_LORE_COLLECTION_COMPLETED_SKILL_EXPERIENCE (categoryIndex, collectionIndex, bookIndex, guildIndex, skillType, skillIndex, rank, previousXP, currentXP)
EVENT_OBJECTIVE_COMPLETED (zoneIndex, poiIndex, level, previousXP, currentXP, rank, previousPoints, currentPoints)
EVENT_QUEST_COMPLETE (questName, level, previousXP, currentXP, rank, previousPoints, currentPoints)
EVENT_SKILL_XP_UPDATE (skillType, skillIndex, reason, rank, previousXP, currentXP)
EVENT_TRADING_HOUSE_OPERATION_TIME_OUT (responseType)
EVENT_TRADING_HOUSE_SEARCH_COOLDOWN_UPDATE (cooldownMilliseconds)
EVENT_VETERAN_POINTS_GAIN (reason, rank, previousPoints, currentPoints)
EVENT_INPUT_LANGUAGE_CHANGED

Added Controls
TextureComposite: This control type is used to draw several layers of textures in an efficient manner. See API notes for usage details.

Changed Control APIs (and updated XML control layouts):

The Texture and Line controls' GetTextureInfo member has been removed and replaced with a more fine-grained API to query individual Texture attributes.
Controls that render textures have all had SetPixelRoundingEnabled and IsPixelRoundingEnabled added. Pixel rounding determines how screen-space positioning works for controls. If enabled, the positions of the control's final screen rect are rounded to the next pixel value before being rendered (rather than letting the shader determine which pixels the control covers). This helps reduce jitter for animated controls, sometimes at the cost a legibility/blurriness

Source

zgrssd

06/27/14 04:02 PM

Worked the Trading House events into the Wiki.
Made a descirption for Cooldown Update.

Sephiroth018

06/27/14 04:42 PM

I already posted that on the official forum, but I'm adding that here too:

I think I may have found an issue with GetTradingHouseCooldownRemaining():
When browsing programatically through the guild store and using that function, I get an error after 5 (or was it 6? not 100% sure) searches: "Too many searches ...". Even if I add a second to the return value of the function, that error occurs. But if I use a fixed delay of 10 seconds, it works.
Is there some additional check like only doing so much request in total in some time? Anyways, the function is not really helpful with that bug.

Sephiroth018

06/28/14 05:23 PM

Quote:

Originally Posted by Sephiroth018 (Post 9900)

I have to correct that, GetTradingHouseCooldownRemaining() works as intended.
The problem comes from another undocumented change: Changing the active trading house guild now also triggers the cooldown.

zgrssd

06/29/14 06:09 AM

The ETA for patch 1.2.4 wich aims solve a bunch of issues is currently at 30th June. According to Known Issues Thread: http://forums.elderscrollsonline.com...nown-issues/p1
I asume they will be pushing it with the Regular Maintenances, so NA frst, then EU.

There is nothign explicitly addon related (especially no the saved var issues) planned for this patch.
But could be they have just not update the thread yet because they are not sure they have a reliable fix for any issue.

skyraker

06/29/14 06:41 AM

Quote:

Originally Posted by zgrssd (Post 9969)

Or, like with 1.2.3 they won't even bother telling us it is fixed. :D

Vuelhering

06/29/14 02:20 PM

Quote:

Originally Posted by Cairenn (Post 9897)

The main bugs are related to displayName not being set properly, which leads to saved variable table corruption as well as some Lua table serialization issues with long strings and improperly escaped character sequences.

:-/

Sounds like this is going to bite me.

katkat42

06/29/14 04:45 PM

Quote:

Originally Posted by skyraker (Post 9970)

Or, like with 1.2.3 they won't even bother telling us it is fixed. :D

I propose a new bit of Elder Scrolls slang:

Whenever ZO changes something and doesn't tell anybody, figuring out what they changed is "as easy as 1.2.3!"

Cairenn

06/29/14 05:03 PM

Quote:

Originally Posted by katkat42 (Post 9994)

I propose a new bit of Elder Scrolls slang:

Whenever ZO changes something and doesn't tell anybody, figuring out what they changed is "as easy as 1.2.3!"

Flamage

06/29/14 08:59 PM

Quote:

Originally Posted by katkat42 (Post 9994)

I propose a new bit of Elder Scrolls slang:

Whenever ZO changes something and doesn't tell anybody, figuring out what they changed is "as easy as 1.2.3!"

There is so much gold in this statement. I agree wholeheartedly.

YelloDello

06/30/14 12:41 AM

ZO_LinkHandler_ParseLink

This could easily be a result of my superficial knowledge of the API and/or lua, but it seems like ZO_LinkHandler_ParseLink() is no longer working the way it used to. Can anyone else verify/disprove this?

Specifically, #ZO_LinkHandler_ParseLink(var) no longer returns the number of arguments, even though I can select(x, ZO_LinkHandler_ParseLink(var)) and prove that there is an argument #x.

(Also, the arguments that are returned are different, e.g. there is no longer a name in an item link. Not sure if this is because item link data has changed, or the linkhandler function is reading things incorrectly.)

Flagrick

06/30/14 02:50 AM

Quote:

Originally Posted by YelloDello (Post 10003)

Explanations here :
http://www.esoui.com/forums/showthread.php?t=1811

YelloDello

06/30/14 09:07 AM

Quote:

Originally Posted by Flagrick (Post 10006)

Explanations here :
http://www.esoui.com/forums/showthread.php?t=1811

Thanks for that! Wow... fairly drastic changes.

One question remaining for me: Why does #ZO_LinkHandler_ParseLink(var) return a zero, even though ZO_LinkHandler_ParseLink(var) has a non-zero number of results?

zgrssd

06/30/14 10:49 AM

Just made a test on the Patched NA server. Nothing new at the Saved Var front.
But then again I did not expect it and it was never planned. I only hoped for it.

Tar000un

06/30/14 12:56 PM

Quote:

Originally Posted by YelloDello (Post 10017)

I didnt a zgoo on, but after a rapid test to complet my answer :
if table[1] = true, so #table = 1, but if table["index"] = true, so #table = nil.

In fact #table is working only with the last correct numeric index.
table[1] = true;
table["index"] = true;

=> #table = 1

SOooo... The table has a non-zero number of results but a #table = 0, because it's probably using a string key instead a numeric key.

Garkin

06/30/14 01:33 PM

Quote:

Originally Posted by Tar000un (Post 10024)

Return value from ZO_LinkHandler_ParseLink(link) is not a table, so #ZO_LinkHandler_ParseLink(link) does not work. You can try to use:

Lua Code:

local resultsTable = { ZO_LinkHandler_ParseLink(link) }
d(#resultsTable)

Tar000un

06/30/14 01:37 PM

Hmm why i read it as a table ? :confused::confused::confused:
Ok, time to sleep i think. x)

zgrssd

07/01/14 03:49 AM

Quote:

Originally Posted by Tar000un (Post 10026)

Hmm why i read it as a table ? :confused::confused::confused:
Ok, time to sleep i think. x)

The Saved Var acessor object can also be read as a table (int and string indexes). Yet also #SavedVarAccessor will return 0.

My best guess is that they fake those two being a table via metafunctions (specifically they have some code for indexing attempts on not-really existing indexes). And they just did not bother to give # a proper meta function, so it won't return anything usefull.

Code:

SavedVar.SomeValue

is equal too

Code:

SavedVar["SomeValue"]

is equal too

Code:

SavedVar.[metatable].getIndex("SomeValue")

Edit: That could mean that "ZO_LinkHandler_ParseLink()" is not actually parsing the link and giving you a table interpretation.
Instead it returns an object that encapsulates the link and gives you some functions to extract data from contained link. It just hides the fact that those are functions behind a fake table.

Edit2: More correct the final piece of code would look like this:

Code:

getmetatable(SavedVar).__index(SavedVar, "SomeValue")

Sasky

07/01/14 01:17 PM

This isn't really related. As Garkin indicated, the function ZO_LinkHandler_ParseLink doesn't return a table but a list of values.

----------------------------------------------------------------------------------------

Yes, the # operator does not go through the __index function of a metatable. However, more relevant for your SavedVars scenario is it completely fails for string keys. Consider this (from Lua console):

Lua Code:

> t = {[1] = "a", [2] = "b", [6] = "d", foo = "e" }
> = #t
2

The # operator only looks at the part of the table that is a well-formed array, with indices {1, 2, 3, ...} consecutively. So the string key is ignored, as well as the 6 (since there's no 4 or 5 key).

YelloDello

07/06/14 06:10 PM

Quote:

Originally Posted by Garkin (Post 10025)

Return value from ZO_LinkHandler_ParseLink(link) is not a table...

Ah so that's what changed. Thanks.

Btw, I've noticed that if you call ZO_LinkHandler_ParseLink "too often" in a single execution, it seems to cause a crash to desktop. I'm not sure what the threshold is. The 1.1 version of ZO_LinkHandler_ParseLink did not cause the crash, even when I called it more than I do now. The new parselink must be more taxing with its string matching and splitting.

Garkin

07/06/14 06:47 PM

Quote:

Originally Posted by YelloDello (Post 10267)

ZO_LinkHandler_ParseLink before patch:

Lua Code:

function ZO_LinkHandler_ParseLink(link)
    if type(link) == "string" then
        local color, data, text = link:match("|H(.-):(.-)|h(.-)|h")
        return text, color, zo_strsplit(':', data)
    end
end

After patch:

Lua Code:

function ZO_LinkHandler_ParseLink(link)
    if type(link) == "string" then
        local linkStyle, data, text = link:match("|H(.-):(.-)|h(.-)|h")
        return text, linkStyle, zo_strsplit(':', data)
    end
end

Is there such a big difference to cause crash to desktop? :)

YelloDello

07/06/14 09:16 PM

Quote:

Originally Posted by Garkin (Post 10268)

Is there such a big difference to cause crash to desktop? :)

Ha! Well, no, definitely not, if that's really the only difference between the ESO 1.1.2 and 1.2.3 versions of the function.

But if that's the only difference, then I'm amazed, because these different results seem to have occurred:

ESO 1.1.2

#ZO_LinkHandler_ParseLink(link) returns nonzero number (I forget, but think it was 23).
Calling ZO_LinkHandler_ParseLink large numbers of times (roughly 191406) in a single execution is fine.

ESO 1.2.3

#ZO_LinkHandler_ParseLink(link) returns 0.
Calling ZO_LinkHandler_ParseLink far fewer times (anywhere between 4556 and 5112) causes a crash.

If your code excerpts are accurate, perhaps the difference I'm seeing in the results is not because of the parselink function, but instead because of some library changing, and/or new limitations being imposed, or some other factor.

Edit: Changed numbers for calls (missed fairly important step in calculation).

merlight

07/06/14 10:03 PM

The code Garkin posted (before patch) is identical to what I have in source dated 19 Aug 2013 (yes 11 months old).

You seem to be misunderstanding what ZO_LinkHandler_ParseLink returns, and how # operator works.

ZO_LinkHandler_ParseLink has always returned multiple values. Not a table. The first returned value is the text contained at the end of the link (between |h tags).

# operator returns the length of its argument - its single argument. When you use a list of values (such as that returned from ZO_LinkHandler_ParseLink) in scalar context, Lua uses only the first value from the list. So, #ZO_LinkHandler_ParseLink(link) returns the length of the text (throwing away the rest of returned values). Since after the patch they stripped the text, the length is 0.

Now, if you want to know how many values ZO_LinkHandler_ParseLink returns, you can either put the results in a table and then use # operator to get its size:

Lua Code:

local function parseLinkIntoTable(link)
    local tab = {ZO_LinkHandler_ParseLink(link)}
    return #tab, tab
end

or, if you really want only the count and not the values, use select:

Lua Code:

local function numLinkParams(link)
    return select("#", ZO_LinkHandler_ParseLink(link))
end

I don't think you're completely wrong with the performance issues, though. I noticed something evil right after Craglorn patch. Back then I only had 1 addon, SpentSkillPoints, and an old version of that which did no caching at all. After the patch, every time I opened my skills, there was a very noticeable delay before the window actually opened. The delay was much shorter before that patch, and it went away once I updated the addon. But something must've changed, perhaps they're throttling Lua instructions per timespan, I don't know.

YelloDello

07/06/14 11:07 PM

Quote:

Originally Posted by merlight (Post 10275)

You seem to be misunderstanding what ZO_LinkHandler_ParseLink returns, and how # operator works...

Well, that explains it: I didn't understand the # operator fully.

Given what Garkin wrote, I interpreted that with the old 1.1.2 link style, #ZO_LinkHandler_ParseLink should have returned a 0 or nil, which was confusing because it had actually returned a nonzero integer. Now I see that it returns the character length of the string that is the first argument. Returning the length of that string would explain everything I've been seeing.

Quote:

But something must've changed, perhaps they're throttling Lua instructions per timespan, I don't know.

It seems that way. I'm very new to lua and the ESO addon api so it's always possible that I'm missing something, but I've seen crashes in multiple places which I've avoided by doing nothing more than limiting the number of instructions.

zgrssd

07/09/14 05:12 AM

Quote:

Originally Posted by zgrssd (Post 9899)

Worked the Trading House events into the Wiki.
Made a descirption for Cooldown Update.

Also added the new mail functions.
Wrote a warning that "GetMailItemInfo" is propably sheduled for removal, once all it's return values are avalible via smaller functions.

Xrystal

07/13/14 03:01 PM

1 Attachment(s)

edit: But then again .. this link works fine

Quote:

"|H2DC50E:item:30148:1:7:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0|hblue entoloma|h"

edit2: Very curious, the same item and thus the same link shows as both bad and good linking even though the link is only stored once for each item name. As the 2nd screenshot shows.

edit3: Aha, looks like the discrepancies are because it has stored it twice. Once under account [""] and once under ["@Xrystal"]. Guess a bit more investigation to do to find out which to keep and which to discard.

Sigh,

Looks like I will be re-writing XrysGatherer big time again .. the link data I have stored away is now corrupt because it has the name stored in it.

As per the history screen showing the link that should be clickable to show the tooltip but as the screenshot shows, now shows an error.

And this of course is the existing link stored.

Lua Code:

"|H2DC50E:item:30166:1:13:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0|hwater hyacinth|h"

Scratch goes the idea of storing the link for later display, if they do something like this. I was considering using the uniqueID ( 30166 ) as the key and just storing the link for extracting the rest of the information.

I'm not quite sure how this can be rectified short of ignoring the link altogether and storing everything else and thus taking up more space, which has already found to be a problem with saved variables.

I'm currently in the process of writing a set of addons to convert and utilise a more compact set of data, and this has now put a spanner in the works.

CrazyDutchGuy

07/13/14 03:46 PM

You can refactor all your old links to the new link style quite easily

Lua Code:

"|H2DC50E:item:30166:1:13:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0|hwater hyacinth|h"

Just replace color H2DC50E with H1 (brackets) or H0 (no brackets) and (optionally) remove the text between |h tags

Lua Code:

"|H1:item:30166:1:13:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0|h|h"

Xrystal

07/13/14 03:55 PM

Quote:

Originally Posted by CrazyDutchGuy (Post 10545)

You can refactor all your old links to the new link style quite easily

Lua Code:

"|H2DC50E:item:30166:1:13:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0|hwater hyacinth|h"

Just replace color H2DC50E with H1 (brackets) or H0 (no brackets) and (optionally) remove the text between |h tags

Lua Code:

"|H1:item:30166:1:13:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0|h|h"

Thanks, have been trying that but doesn't seem to work. I currently have this block running to see if that theory panned out but nada, the reworked link is still reported as broken.

Lua Code:

local linkData = { ZO_LinkHandler_ParseLink(itemLink) }
    if account == "" then
        CHAT_SYSTEM:AddMessage(string.format("Valid: Converting Account:%s Name:%s ID:%s Link:%s ",tostring(account),tostring(itemIndex),tostring(itemID),tostring(itemData["Link"])))
    else
        CHAT_SYSTEM:AddMessage(string.format("Before: Converting Account:%s Name:%s ID:%s",tostring(account),tostring(itemIndex),tostring(itemID)))
        local newLink = "|H"    
        newLink = newLink..linkData[2]  
        for i = 3, 23 do            
            newLink = newLink..":"..linkData[i]
        end
        newLink = newLink.."|h|h"
        CHAT_SYSTEM:AddMessage(string.format("After: Converting Account:%s Name:%s ID:%s Link:%s ",tostring(account),tostring(itemIndex),tostring(itemID),tostring(newLink)))
    end

edit: D'oh .. must have been re-using the color value which, although was printing out as 0 must still be using it as the original color value. Changed it to |H1 and then the for loop and all is well.

edit2: Thanks for the tip with H0 and H1 for the different types.. Decided to change the H0 ones to H1 as well. A Much better display for links rofl.

Lua Code:

if linkData[2] ~= "0" and linkData[2] ~= "1" then
        local newLink = "|H1"   
        for i = 3, 23 do            
            newLink = newLink..":"..linkData[i]
        end
        newLink = newLink.."|h|h"
        itemLink = newLink      
    elseif linkData[2] == "0" then
        local newLink = "|H1"   
        for i = 3, 23 do            
            newLink = newLink..":"..linkData[i]
        end
        newLink = newLink.."|h|h"
        itemLink = newLink      
    end

merlight

07/13/14 05:34 PM

I find your replacement code quite convoluted :) Try this:

Lua Code:

link:gsub("|H(%x%x%x%x%x%x)(.-|h)(.-)|h", "|H0%2|h")
-- first capture matches six hex digits, which are discarded
-- second capture matches everything up to and including |h, and is put in replacement %2
-- third capture matches everything up to second |h (link text, discarded)
-- you can use it on old and new links alike, no need to test which format you have
-- on new links it wil just not replace anything, because the |Hxcolor code won't match

edit: oops, somehow I dropped one x from the pattern. fixed

Xrystal

07/13/14 06:12 PM

Quote:

Originally Posted by merlight (Post 10547)

I find your replacement code quite convoluted :) Try this:

Lua Code:

link:gsub("|H(%x%x%x%x%x%x)(.-|h)(.-)|h", "|H0%2|h")
-- first capture matches six hex digits, which are discarded
-- second capture matches everything up to and including |h, and is put in replacement %2
-- third capture matches everything up to second |h (link text, discarded)
-- you can use it on old and new links alike, no need to test which format you have
-- on new links it wil just not replace anything, because the |Hxcolor code won't match

edit: oops, somehow I dropped one x from the pattern. fixed

Thanks, this information is appreciated. I know about the gsub routines but I have revised my code somewhat to be less repetitive but this way I know when I look at the code in 6 months time I won't have to research how gsub works again rofl. And seeing as this should be one of those one off conversion things it won't be used much.

Lua Code:

if (linkData[2] ~= "0" and linkData[2] ~= "1") or linkData[2] == "0" then
        local newLink = "|H1"   
        for i = 3, 23 do            
            newLink = newLink..":"..linkData[i]
        end
        newLink = newLink.."|h|h"
        itemLink = newLink      
    end

merlight

07/13/14 06:58 PM

Probably the only thing I like about Lua's regular expressions is that they traded power for simplicity, so they're easy to learn. And the added benefit of learning things like this is you get better understanding of other people's code. I've had to learn myself, never used Lua and still don't like it as a language ;)

Another shortcut:

Quote:

Originally Posted by Xrystal (Post 10548)

Lua Code:

for i = 3, 23 do            
            newLink = newLink..":"..linkData[i]
        end

Lua Code:

newLink = newLink .. table.concat(linkData, ":", 3, 23)

Sasky

07/14/14 09:47 AM

Also table.concat is more efficient than joining a bunch of strings with concatenation operators (..).

When you combine a string using "abcd" .. "e", it'll copy it all into a new longer string rather than just appending. As such, adding a little bit on for each step of a loop incurs a lot of overhead from copying over and over in memory (and overhead from the garbage collector too). For the table, it just grabs a little more memory each time, and does the copying once when you combine it at the end with table.concat()

Xrystal

07/14/14 02:18 PM

Quote:

Originally Posted by merlight (Post 10549)

Lua Code:

newLink = newLink .. table.concat(linkData, ":", 3, 23)

Ah, now that concat didn't even cross my mind .. I always assumed table.concat was for concatenating tables not values within tables. Very interesting.

And yes, true, I am always up for learning and I do try using the table and string functions where I can but some of the more complex ones I always forget months down the line. If this was professional it would be a different kettle of fish, but this is for a game and just for a data conversion tool and not a use all the time addon :) But seeing as the release of this is a ways off you never know, I may rethink things and include these suggestions.

So thanks again for pointing them out and especially for explaining the gsub statement.

Xillix

07/27/14 12:37 PM

Tested it on PTS and skill procs like Crystal Shards still do not proc in the new version.

Also, there has been some reports of lag with new version... love this addon and keep up the great work!

All times are GMT -6. The time now is 02:40 AM.