V1.2.3 API Patch Notes & Change Log - Page 2

Garkin · 07/06/14, 06:47 PM

Originally Posted by YelloDello

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.

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

Originally Posted by Garkin

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

Originally Posted by merlight

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.

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

Originally Posted by zgrssd

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

edit: But then again .. this link works fine

"|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

Originally Posted by CrazyDutchGuy

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

Originally Posted by merlight

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:

Originally Posted by Xrystal

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

Originally Posted by merlight

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:

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!