V1.2.3 API Patch Notes & Change Log
 

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

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.

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.

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.

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

:-/

Sounds like this is going to bite me.

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.

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.)

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?

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.

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.

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

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.

is equal too
is equal too
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:

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):


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).

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.