V1.2.3 API Patch Notes & Change Log

ZOS_JessicaFolsom

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.

Cairenn

Thank you Jess

zgrssd

Thanks for the post. Better late then never

FYI, it seems that GetMapPlayerPosition('reticleover') seems to return all 0 now, instead the position relative to the player:
http://forums.elderscrollsonline.com/discussion/113772/getmapplayerposition-reticleover

We are uncertain if that is a bug or anti bot measure. And it might be related to the displayName issue.

SkOODaT

zgrssd wrote: »

Thanks for the post. Better late then never

FYI, it seems that GetMapPlayerPosition('reticleover') seems to return all 0 now, instead the position relative to the player:
http://forums.elderscrollsonline.com/discussion/113772/getmapplayerposition-reticleover

We are uncertain if that is a bug or anti bot measure. And it might be related to the displayName issue.

thank you for posting that here @zgrssd yes i am wondering very much so few other addons rely on this to work correctly such as range reticule and reticule settings

katkat42

First of all, thank you for publishing this! I've updated the wiki at wiki.esoui.com to reflect some of this.

Question, though: What about the changes to the link system? Also, I had one of my add-ons break because GetGameCameraInteractableActionInfo() had an extra return value added...

Still, this is a great start!

Sephiroth018

Thanks for posting that now. In the future, please post that on patchday, or (even better) before patch day.

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.

zgrssd

Sephiroth018 wrote: »

Thanks for posting that now. In the future, please post that on patchday, or (even better) before patch day.

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.

We had a simialr issues with GSEE. The function is working perfectly
It seems as if the timer is just firing too early:
http://www.esoui.com/portal.php?id=101&a=viewbug&bugid=898
He used ldtimer. Not sure what it uses at the backend, but maybe "ZO_CallLater" is bugged and fires too early.

Edit: he order zo_calllater to fire after 500 ms, then makes custom logic/rate limitig logic to see wich timer event to raise.

zgrssd

Link to chat issues. Reported with screenshoot, but just so it here too:
When trying to link several items to chat, the last link was cut off:

Just crafted this: |H1:item:45080:30:1:0:0:0:0:0:0:0:0:0:0:0:0:1:1:0:0:0|h|h|H1:item:45081:30:1:0:0:0:0:0:0:0:0:0:0:0:0:1:1:0:0:0|h|h|H1:item:45047:30:1:0:0:0:0:0:0:0:0:0:0:0:0:1:1:0:0:0|h|h|H1:item:45046:30:1:0:0:0:0:0:0:0:0:0:0:0:0:1:1:0:0:0|h|h|H1:item:45045:30:1:0:0:0:0:0:0:0:0:0:0:0:0:1:1:0:0:0|h|h|H1:item:45045:30:1:0:0:0:0:0:0:0:0:0:0:0:0:1

If I make a newlien for each link, it becomes more obvious:
Just crafted this:
|H1:item:45080:30:1:0:0:0:0:0:0:0:0:0:0:0:0:1:1:0:0:0|h|h
|H1:item:45081:30:1:0:0:0:0:0:0:0:0:0:0:0:0:1:1:0:0:0|h|h
|H1:item:45047:30:1:0:0:0:0:0:0:0:0:0:0:0:0:1:1:0:0:0|h|h
|H1:item:45046:30:1:0:0:0:0:0:0:0:0:0:0:0:0:1:1:0:0:0|h|h
|H1:item:45045:30:1:0:0:0:0:0:0:0:0:0:0:0:0:1:1:0:0:0|h|h
|H1:item:45045:30:1:0:0:0:0:0:0:0:0:0:0:0:0:1

I would guess the new format/lenght of the links is not considered when checking if they can be added to the chat.

zgrssd

@ZOS_JessicaFolsom I have a small request for information regarding the API:
Could it be that zo_callLater(function functionToCall, integer delayInMs) is running on/raises the callback (functionToCall) on a seperate thread from the UI Thread since 1.2?

Becaus we have some issues with timers that are most likely a race condition. Race condition requires multithreading. That would be the only function that could be using multthreading. A seperate thread (and maybe even one for each callback fire) for a timer is a pretty common thing right now.

Sephiroth018

zgrssd wrote: »

Sephiroth018 wrote: »

Thanks for posting that now. In the future, please post that on patchday, or (even better) before patch day.

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.

We had a simialr issues with GSEE. The function is working perfectly
It seems as if the timer is just firing too early:
http://www.esoui.com/portal.php?id=101&a=viewbug&bugid=898
He used ldtimer. Not sure what it uses at the backend, but maybe "ZO_CallLater" is bugged and fires too early.

Edit: he order zo_calllater to fire after 500 ms, then makes custom logic/rate limitig logic to see wich timer event to raise.

Good to know, at the first glance it really seemed like the new function was bugged. But a possible bug in zo_calllater is even worse, I think.

zgrssd

Sephiroth018 wrote: »

zgrssd wrote: »

Sephiroth018 wrote: »

Thanks for posting that now. In the future, please post that on patchday, or (even better) before patch day.

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.

We had a simialr issues with GSEE. The function is working perfectly
It seems as if the timer is just firing too early:
http://www.esoui.com/portal.php?id=101&a=viewbug&bugid=898
He used ldtimer. Not sure what it uses at the backend, but maybe "ZO_CallLater" is bugged and fires too early.

Edit: he order zo_calllater to fire after 500 ms, then makes custom logic/rate limitig logic to see wich timer event to raise.

Good to know, at the first glance it really seemed like the new function was bugged. But a possible bug in zo_calllater is even worse, I think.

@Sephiroth
The thing is that ld timers is not relying on the call-later for the actuall timer function.
He just uses it to fire a internal tick event every 500 ms. I would have done something like this with the Update Event. As long as it is called regulary, who calls it should not matter.

Inside that regulary called tick event he does custom checks wich timers callback has to be used (lastraised+timespan>= GetTimeMilliseconds()).
And I am still butting my head at what is wrong in there. I made two modifications to guard agaisnt race conditions, but the timer callback is still ocassionall raised too early.

Sephiroth018

zgrssd wrote: »

Sephiroth018 wrote: »

zgrssd wrote: »

Sephiroth018 wrote: »

Thanks for posting that now. In the future, please post that on patchday, or (even better) before patch day.

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.

We had a simialr issues with GSEE. The function is working perfectly
It seems as if the timer is just firing too early:
http://www.esoui.com/portal.php?id=101&a=viewbug&bugid=898
He used ldtimer. Not sure what it uses at the backend, but maybe "ZO_CallLater" is bugged and fires too early.

Edit: he order zo_calllater to fire after 500 ms, then makes custom logic/rate limitig logic to see wich timer event to raise.

Good to know, at the first glance it really seemed like the new function was bugged. But a possible bug in zo_calllater is even worse, I think.

@Sephiroth
The thing is that ld timers is not relying on the call-later for the actuall timer function.
He just uses it to fire a internal tick event every 500 ms. I would have done something like this with the Update Event. As long as it is called regulary, who calls it should not matter.

Inside that regulary called tick event he does custom checks wich timers callback has to be used (lastraised+timespan>= GetTimeMilliseconds()).
And I am still butting my head at what is wrong in there. I made two modifications to guard agaisnt race conditions, but the timer callback is still ocassionall raised too early.

I think I have found the real source of the problem, as I have also seen this with the addon PriceTrader and after digging through both addon's code and watching carefully what happened when, I saw it was always happening when changing the active guild. I also could reproduce that by manually doing a search and then trying to switch the guild while the search button was inactive.
So, long story short, the search delay now also affects SelectTradingHouseGuildId(int).
After modifying the code of GSSE to get and use the delay also when switching the guild, it worked (same for PriceTrader)

zgrssd

Sephiroth018 wrote: »

I think I have found the real source of the problem, as I have also seen this with the addon PriceTrader and after digging through both addon's code and watching carefully what happened when, I saw it was always happening when changing the active guild. I also could reproduce that by manually doing a search and then trying to switch the guild while the search button was inactive.
So, long story short, the search delay now also affects SelectTradingHouseGuildId(int).
After modifying the code of GSSE to get and use the delay also when switching the guild, it worked (same for PriceTrader)

The issues is that sometimes ld timer simply fires the timer event when <30 ms have passed. Despite being clearly told to wait 3000 ms (GetCooldown; checked the return value before passing it to the timer).
If have already tried two anti-race condition measures. But none seems to have worked so far. It still sometimes fires after 30ms when it should not.

Sephiroth018

zgrssd wrote: »

The issues is that sometimes ld timer simply fires the timer event when <30 ms have passed. Despite being clearly told to wait 3000 ms (GetCooldown; checked the return value before passing it to the timer).
If have already tried two anti-race condition measures. But none seems to have worked so far. It still sometimes fires after 30ms when it should not.

Strange, that didn't happen for me. But in this specific case it can be easily countered by using a recursive function that checks the remaining delay and calls the Id timer callback function again if the remaining delay is not 0.

KaizerXul

This time we've been working on some upcoming features for the dye, guild heraldry, guild trader, and chat bubble systems.

I'm just excited that these things are coming.

z1ver

Please let us see the group damage and healing..

zgrssd

z1ver wrote: »

Please let us see the group damage and healing..

They are still having lag issues. This simple thing would multiply the number of events that have to be reliably and timely transmitted to all clients by the number of group members (2-12). It comes after the bulk of lag issues have been solved, earliest.
We know they are working on it (the API for this was exposed by accident once or twice). But I asume it is just not ready yet.

Merlight

ZOS_JessicaFolsom wrote: »

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

Where can i find these API notes?

I have some questions regarding item and itemlink API. Names are no longer present in itemlinks returned from functions like GetItemLink. I guess this was done to have localized item names in chat, which is good and I hoped for it to be done. But is there a way to get the item's (localized) name in an add-on now?

Or better: could we have an API to extract all available information from itemlinks? I mean not just the numbers contained in the link. Localized item name, actual level* requirement (including VR), quality*, potion attributes, some sort of stacking id**, ...

* itemlink fields marked as Level and Quality on the wiki are not always that. I've seen Blessed Thistle of levels 1, 16; Dreugh Wax of levels 0, 1, 37; and so on, and these items stack. On the other hand potions with the same itemId but different levels don't stack; and their obscure "quality" value somehow determines their VR level and strength.

** I use GetItemInstanceId to decide whether two items would stack, but I'm unable do this with loot before I pick it. Would be nice to get this id off itemlink.

KiriX

Where I can found full actual API description?

Sephiroth018

This is what is currently available. ZOS hasn't published a full documentation...

KiriX

Sephiroth018 wrote: »

This is what is currently available. ZOS hasn't published a full documentation...

Thx, I know about esoui.
It's sad, that ZOS hasn't published a full documentation... =(

Cogo

KiriX wrote: »

Sephiroth018 wrote: »

This is what is currently available. ZOS hasn't published a full documentation...

Thx, I know about esoui.
It's sad, that ZOS hasn't published a full documentation... =(

Oh, ok, and that is more important then the stability issue for players...how?

Merlight

Cogo wrote: »

KiriX wrote: »

Sephiroth018 wrote: »

This is what is currently available. ZOS hasn't published a full documentation...

Thx, I know about esoui.
It's sad, that ZOS hasn't published a full documentation... =(

Oh, ok, and that is more important then the stability issue for players...how?

The keyword is published. They should already have it, not start writing it now. I do have all those issues, and I'm not afraid publishing a documentation would delay proper solution.

zgrssd

Cogo wrote: »

KiriX wrote: »

Sephiroth018 wrote: »

This is what is currently available. ZOS hasn't published a full documentation...

Thx, I know about esoui.
It's sad, that ZOS hasn't published a full documentation... =(

Oh, ok, and that is more important then the stability issue for players...how?

Why do you ask that?

This is the Addon and UI Mod Forum.
This thread is about the API Patch notes for 1.2.3 and thus the current state of the API.
Nobody said with one word that the API documentation is more important then anything on the list of known issues. In fact you are the first person to use the word 'important' in this thread at all.

We just would like to have a full API documnetation at it due time. And rather earlier then later.
Nothing more. Nothing less.