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
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:
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):
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):
Source |
Worked the Trading House events into the Wiki.
Made a descirption for Cooldown Update. |
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. |
Quote:
The problem comes from another undocumented change: Changing the active trading house guild now also triggers the cooldown. |
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. |
Quote:
|
Quote:
Sounds like this is going to bite me. |
Quote:
Whenever ZO changes something and doesn't tell anybody, figuring out what they changed is "as easy as 1.2.3!" |
Quote:
|
Quote:
|
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.) |
Quote:
http://www.esoui.com/forums/showthread.php?t=1811 |
Quote:
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? |
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. |
Quote:
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. |
Quote:
Lua Code:
|
Hmm why i read it as a table ? :confused::confused::confused:
Ok, time to sleep i think. x) |
Quote:
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 Code:
SavedVar["SomeValue"] Code:
SavedVar.[metatable].getIndex("SomeValue") 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") |
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:
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). |
Quote:
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. |
All times are GMT -6. The time now is 09:10 PM. |
vBulletin © 2024, Jelsoft Enterprises Ltd
© 2014 - 2022 MMOUI