Update 12 API Patch Notes & Change Log (PTS)

ZOS_GinaBruno · August 2016

ESO UI API Patch Notes (Version 100017)
These patch notes highlight the larger changes to the ESO API. For the full updated API, take a look at the newest version of the ESO UI documentation (attached).

Dueling
The dueling feature has been added to the game.
Added the DUEL_RESULT enumeration:

DUEL_RESULT_FORFEIT
DUEL_RESULT_WON

Added the DUEL_STATE enumeration:

DUEL_STATE_DUELING
DUEL_STATE_DUEL_PENDING
DUEL_STATE_DUEL_TERMINATING
DUEL_STATE_IDLE
DUEL_STATE_INVITE_CONSIDERING
DUEL_STATE_INVITE_REQUESTING

Added Functions:

IsDuelingDeath()
GetDuelInfo() – DUEL_STATE, partnerCharacterName, partnerDisplayName
ChallengeTargetToDuel(characterOrDisplayName)
AcceptDuel()
DeclineDuel()
IsNearDuelBoundary()

Added Events:

EVENT_DUEL_COUNTDOWN – startTimeMS
EVENT_DUEL_FINISHED – DUEL_RESULT, wasLocalPlayersResult, opponentCharacterName, opponentDisplayName, opponentAlliance, opponentGender, opponentClassId, opponentRaceId
EVENT_DUEL_INVITE_ACCEPTED
EVENT_DUEL_INVITE_CANCELED
EVENT_DUEL_INVITE_DECLINED
EVENT_DUEL_INVITE_FAILED – DUEL_INVITE_FAIL_REASON, targetCharacterName, targetDisplayName
EVENT_DUEL_INVITE_RECEIVED - inviterCharacterName, inviterDisplayName
EVENT_DUEL_INVITE_REMOVED
EVENT_DUEL_INVITE_SENT - inviteeCharacterName, inviteeDisplayName
EVENT_DUEL_NEAR_BOUNDARY

Added lots of reasons a duel could fail under the prefix DUEL_INVITE_FAIL_REASON.
Added NOTIFICATION_TYPE_DUEL.
Added a setting for automatically declining duels, UI_SETTING_AUTO_DECLINE_DUEL_INVITES.

Craft Bag
There is a new option that allows the player to choose if crafting materials are automatically placed in the Craft Bag named LOOT_SETTING_AUTO_ADD_TO_CRAFT_BAG. There is also a new function for placing all items into the Craft Bag manually named StowAllVirtualItems. It is valid to use StowAllVirtualItems if CanAnyItemsBeStoredInCraftBag(BAG_BACKPACK) returns true.

Repeatable Quest Pins
Repeatable quests received their own pin types:

MAP_PIN_TYPE_ASSISTED_QUEST_REPEATABLE_CONDITION
MAP_PIN_TYPE_ASSISTED_QUEST_REPEATABLE_ENDING
MAP_PIN_TYPE_ASSISTED_QUEST_REPEATABLE_OPTIONAL_CONDITION
MAP_PIN_TYPE_QUEST_OFFER_REPEATABLE
MAP_PIN_TYPE_TRACKED_QUEST_REPEATABLE_CONDITION
MAP_PIN_TYPE_TRACKED_QUEST_REPEATABLE_ENDING
MAP_PIN_TYPE_TRACKED_QUEST_REPEATABLE_OPTIONAL_CONDITION

We also exposed two functions for converting between assisted and tracked quest pin types:

AssistedQuestPinForTracked(trackedType) – assistedType
TrackedQuestPinForAssisted(assistedType) – trackedType

3D UI APIs
The preliminary 3D texture/3D label control APIs have been finalized. However, the decision was made to privatize these functions to prevent addons from trivializing some dungeon mechanics by drawing markers on the ground in 3D space. The privatization of these functions will occur with the second PTS patch. If you have questions or comments about this change, please reply to this thread.

Nameplates
Added functions:

SetNameplateKeyboardFont(fontName, FONT_STYLE)
GetNameplateKeyboardFont() – fontName, FONT_STYLE
SetNameplateGamepadFont(fontName, FONT_STYLE)
GetNameplateGamepadFont() – fontName, FONT_STYLE

Miscellaneous

Added STAT_HEALING_DONE and removed STAT_PARRY.
The INSTANCE_DISPLAY_TYPE_GROUP has been removed and replaced with the more nuanced values:
- INSTANCE_DISPLAY_TYPE_DUNGEON
- INSTANCE_DISPLAY_TYPE_GROUP_AREA
- INSTANCE_DISPLAY_TYPE_PUBLIC_DUNGEON
Removed GetJournalQuestRewardInfoInZone as the zone is no longer important in reward calculations.
Added QUEST_TYPE_HOLIDAY_EVENT.
Added CancelRequestJournalQuestConditionAssistance to cancel an in-progress quest position path find.
Maps now have description text. It was added as the final return from GetMapInfo.
EVENT_COLLECTIBLE_NOTIFICATION_NEW now passed the collectibleId along.

Ayantir · September 2016

@ZOS_GinaBruno sticky please ?

Sounomi · September 2016

Its disappointing, though understandable, that the 3D UI API was chosen to be unaccessible via add-ons. My only hope now is that you make parts of the UI that function in a 3D space, such as combat text, nameplates, group markers, etc become more customizable via add-ons in the future to make up for this decision.

Kyoma · September 2016

I too am a bit disappointed about the decision to make em private. I can understand it but I do hope we'll get certain features in the vanilla UI then, like placing predefined 3D markers at a map ping for example.

Ayantir · September 2016

ZOS_GinaBruno wrote: »

3D UI APIs
The preliminary 3D texture/3D label control APIs have been finalized. However, the decision was made to privatize these functions to prevent addons from trivializing some dungeon mechanics by drawing markers on the ground in 3D space. The privatization of these functions will occur with the second PTS patch. If you have questions or comments about this change, please reply to this thread.

Please change a bit the function to something like this :

if GetCurrentZoneDungeonDifficulty() == DUNGEON_DIFFICULTY_NONE then
    StartWorldParticleEffect (number particleEffectId) 
else
    assert("Particles cannot be used in Instanced Dungeons")
end

Shinni · September 2016

3D UI APIs
The preliminary 3D texture/3D label control APIs have been finalized. However, the decision was made to privatize these functions to prevent addons from trivializing some dungeon mechanics by drawing markers on the ground in 3D space. The privatization of these functions will occur with the second PTS patch. If you have questions or comments about this change, please reply to this thread.

I'm kinda diappointed in that change. I can totally understand the reason, but if exploiting the 3d api to trivialize fights is an issue, why not prevent that issue without completely removing the 3d api for addons?
For instance, would it be possible to keep the 3d api open for addons and instead simply refuse to draw the 3d textures while the character is in combat?

edit: Ayantir's approach which disables the 3d api in dungeons sounds good too.

d.droeschelb16_ESO · September 2016

3D UI APIs
The preliminary 3D texture/3D label control APIs have been finalized. However, the decision was made to privatize these functions to prevent addons from trivializing some dungeon mechanics by drawing markers on the ground in 3D space. The privatization of these functions will occur with the second PTS patch. If you have questions or comments about this change, please reply to this thread.

What a huge disappointment! ;(
I was so happy to read that this functions will come and now i have to read this...
I guess that it would be more than enough to make the functions only accessible when out of combat if you really want to prevent "trivializing" Mechanics. But in my opinion there is nothing bad on highlighting spots in Game with the API instead of a Player shooting at a destination, or jumping like an idiot at a certain spot to show his mates what their location is, or where the Boss gets pulled to etc. Highlighting locations / mobs would just make it a lot easier to describe what to do and save a lot of time.

sirinsidiator · September 2016

ZOS_GinaBruno wrote: »

3D UI APIs
The preliminary 3D texture/3D label control APIs have been finalized. However, the decision was made to privatize these functions to prevent addons from trivializing some dungeon mechanics by drawing markers on the ground in 3D space. The privatization of these functions will occur with the second PTS patch. If you have questions or comments about this change, please reply to this thread.

Judging from how you put that last sentence there, there is either still hope or you are trolling us really hard.

I'll believe in the good in Gina and put together some pros and cons for leaving the 3D API open.

Reasons to keep it public:

it will open the doors for a new category of addons that will most likely attract some new authors (there is less than 50 active addon authors left)
it would allow for interesting user content that could enrich the world of Tamriel (e.g. street signs, pseudo interactable objects for user made quests, 3d resource bars and UI ...)
it will keep me (and other addon devs) entertained for a long time
you will never know what could be if you forbid it right away without giving anyone the chance to make something out of it

Resons to make it private:

it is scary to think about what some crazy addon authors will do with it (but you could say the same for the existing API)
it could possibly make dungeon mechanics too easy (but if anyone was interested in making such an addon they could already have done it in 2d via a map overlay)
it may cause performance problems (but badly coded addons already do that anyways)

So yeah. Not really any reason to make it private besides being scared of what could happen.
I say, leave it open for at least one update and see what happens before locking it down and if you are really that concerned about it making fights too easy, do what Ayantir and Shinni proposed and lock it only in dungeons and during combat for now until you have a real reason to lock it completely.

manavortex · September 2016

I do agree with the other children. Please leave this playground open for us - I have so many awesome ideas what this could be used for! Let's just talk about RP - we could have real wizard duels with real glowy effects'n'stuff!
Just lock it where necessary. Or restrict the visibility to groups. I can think of so many awesome ideas what we could do with this - custom quests, treasure hunts, let's just call it player-generated content! Don't strangle the baby at birth just because of power gamers...

Reorx_Holybeard · September 2016

I've just been looking at the new stats comparison feature and it works/looks really good. A few comments mainly from the add-on development side:

I was thinking that just showing the final value is good but I'd really like to see by how much the stat has changed by. With it right now I basically have to move the mouse left/right to see the original and modified values to get an idea of how much it has changed. See the image below for a quick test of what I was thinking. Perhaps showing the delta and the final value would be better. Either way, add-ons can customize the display by replacing the ZO_StatEntry_Keyboard:ShowComparisonValue(statDelta) function.
The new feature prevents additional existing and custom stats from being (easily) added to the inventory window. For example, in uespLog I've added Spell/Physical Penetration to the list as well as 4 custom stats. The reason it breaks and makes it difficult to extend is the addition of the local table CHARACTER_STAT_CONTROLS in esoui\ingame\characterwindow\keyboard\characterwindow_keyboard.lua. So when the window is displayed and the ZO_CharacterWindowStats_ShowComparisonValues() function (and the related Hide function) try to display they get a nil entry from that table which is used without being checked. The easiest fix is to just add a nil check to 2 places in the code like:
```
local statControl = CHARACTER_STAT_CONTROLS[stat]
if (statControl ~= nil) then
              statControl.statEntry:HideComparisonValue()
end
```
Right now I have to copy/replace those two functions in my addon which I'd prefer not to do as it is not portable and wouldn't work with another addon replacing those functions. Ideally I'd like a way to be able to properly add new/custom stats to the character window but that is a little harder (I can think of a few ways off the top of my head but none ideal).
As a related feature request, can we add the Spell Critical Damage and Weapon Critical Damage modifiers to the list of supported stats? AFAIK there is no way of getting those two stats in the game other than directly computing them (which is a pain, trust me).

Example of what I was thinking of for item #1. I'm still not sure whether I like showing the delta and/or the final value but probably both would be better.

Grouf · October 2016

Shouldn't this be pinned to the top of the forum? @ZOS_GinaBruno @ZOS_JessicaFolsom