Update 4.0
 

The next version just hit the PTS, so here is an update thread for that.

New API Version: 100023

PTS Dev Guild
We always create a guild for all addon developers on the PTS, so we can test guild related things and more, ask for help with testing or just chat.
If you need an invite, ask here or over on our Gitter channel.

Links

• Patch Notes 4.0.5
• API Patch Notes
• PTS Patch Notes 4.0.0
• PTS Patch Notes 4.0.1
• PTS Patch Notes 4.0.2
• PTS Patch Notes 4.0.3
• PTS Patch Notes 4.0.4
• ESOUIDocumentationP18 2.txt
• Calia's API doc comparison
• ESOUI source code
• Feedback Megathread on the official forum
• Thread for Update 3.3
• Thread for Update 3.2 (links to older threads are found in there)

I'll edit the OP with more useful information as you post it.

Welkynar and Dremora are unfinished motifs. I wonder if Pyandonean is intentionally crown store only.

Most of you should already have Summerset access from the Morrowind PTS, but if any active addon author needs it they can message me.

I was given Morrowind access, but maybe I'm doing it wrong for Summerset? When clicking the wayshrine it tells me to upgrade.

There were some issues with access flags initially. Can you get in today?

Here's the UI documentation.

Thanks for the file

What's going on with the skills/ability data? Previously when you used the function GetSpecificSkillAbilityInfo() for an active/ultimate ability you would get 12 different ability IDs for all the morph/rank choices. Now, however, it seems it only returns 3 different ability IDs (one for each morph) and the same abilities for all 4 ranks of each morph. Further, it seems the previous rank 2-4 abilities no longer exist and some rank 1 abilities have new IDs.

I was hoping to find some new skill related functions in the API but I can't seem to find any. Is this an on-purpose change in the skill API or is there something buggy going on the current PTS?


This seems to affect a bunch of skill API functions (only checked a few):

• GetSpecificSkillAbilityInfo() -- Only returns the same ability for all ranks of a morph.
• GetAbilityProgressionAbilityId() -- Returns the same ability ID regardless of rank.
• GetAbilityProgressionXPInfoFromAbilityId() -- Doesn't return the correct morph.
• GetSpecificSkillAbilityKeysByAbilityId() -- Returns the correct morph but the incorrect rank (always 2).

I am confused Uesp GetSpecificSkillAbilityInfo() only returns 2 values, not 12.
It seems to be defined the same was it is right now

OLD

NEW

Sorry for the confusion...here's an explicit example comparing Live/PTS:

Live:
PTS:
On PTS abilities 27179, 27182, and 27186 do not exist. So either somethings buggy or they changed how the abilities level up from Rank 1-4.

Here's a comparision of 3.3 (left) to PTS (right) - couple things changed.

One more here: the 2nd reference to *luaindex:nilable* is now *integer*, some function and several params have changed. Orange text highlights the differences. Should have my comparision notes up shortly.

Thanks for the API info although the changes seem minor and not related to the issue/confusion I'm having. I believe it just due to how different skill ranks work behind the scenes so it would only be relevant to a few mod authors that rely on specific ability IDs existing or abilities of different ranks having different IDs.

This is relevant to data mining for our skill browser which was messed up this update as it expected ability data in the same format/organization as previous updates.

Previously we could just do:

and then the various GetAbility...() functions to get all the ability data for all 12 morph+rank combinations along with morph/rank data. However, now the ability rank seems to be a hidden factor so its not possible to get the ability data (description, tooltip, skill coefficients, etc...) for anything except the characters current rank for all skills. Further meaning I can't mine live data as I would need all active/ultimate skills leveled to rank 4 in order to get the correct tooltip data. Can use PTS templates to get all rank 4 data at least and hope there's no difference between PTS and Live on release day.

I'll keep looking at the API and trying to figure out a better/easier way of getting the data for all ability ranks and will take any suggestions people have. Would also love a ZOS dev to chip in (wink-wink) on this change and whether I'm missing anything obvious.

I'm pretty sure I don't have any addons messing with the inventory active, yet I get the tainted stack issue on all containers. Is anyone else having this issue and is this going to be taintgate 2?

Changenotes to 3.3 attached.

It's caused by the change to ZO_PreHook which will be reverted in the next pts cycle. Until then you can use the LibCustomMenu that votan posted on gitter yesterday.

Good, thanks.

I'm hoping someone goofed and the Jewelry line doesn't intentionally use Woodworking images...

The active skills were changed into single abilities with scaling behavior based on rank. This was to help with updating and maintaining these skills. I'll need to think about what it would mean to target specific ranks of these through APIs. I think it might mean adding rank parameters to a lot of the ability APIs. Which APIs are you using?

Yah, that's what I assumed was going on. It makes sense as it reduces the number of active skills you have to maintain by a factor x4.

As for adding the skill rank to API functions, it would be any of the GetAbility....() where the value might change between ranks. A few ones I can think of would include:

• GetAbilityDescription()
• GetAbilityCost()
• GetAbilityDuration()
• GetAbilityCastInfo()
• GetAbilityRange()
• GetAbilityRadius()

Unsure if those last few ever change for different ranks. At the very least the description which would let us mine the skill coefficients for all 4 ranks.

I would assume you were thinking of changing the API to something like:
or you could do:
I assume that at the moment the GetAbilityDescription(abilityId) and similar functions return values for the current rank of the character correct?

This is actually super helpful for me. Makes it way less difficult to do things like custom auras for ground abilities. Although - a method to pull the duration differences between ranks when relevant might be helpful in certain cases.

Also, Chip, would you be able to pass a suggestion along to the development team? Currently there's an inconsistency between ability names for "Off Balance" and "Off-Balance." Might be a good idea to do a pass on it and normalize it in all ability's as well as tooltips (I think tooltips might all say "Off Balance" now but I haven't check every single one). Thanks!

This is the best change that has ever been made since I was coding addons, awesome! It will make addon development so much easier for me. There is just one little grain of salt left: Can you add a field or a function that contains info wether the ability is a 'player owned' ability and additonally the base morph, morph a, morph b relations (e.g. 30244 being morph b, it should contain some info on which ability id is morph a and the base morph).

Morphs still have a different ID I believe. Just rank 1-4 for each were compressed into single id's.

Yep, I understood that, makes sense since there are boss abilities, that do not have morphs ^^

What I meant is, that I'd like to have a field that allows me to link a specific abilityId to it's (base)-morph(s) IF it is morphable (= player owned?).

The unification of ability IDs is certainly useful for my application. Makes things much more streamlined only having to register callbacks or monitoring for a quarter of the number of IDs, but I can see how it may introduce a little more work for those who use the unique ranks in more meaningful ways. I'm a fan.

Can confirm that stack IDs (à la Grim Focus) also maintain the Rank I IDs. Haven't tested all ranks for any "gotchas" but at least all the ones I've tested have stacked against the Rank I ID.

Cheers.
G

You can use GetSpecificSkillAbilityInfo to link up the morphs.

On PTS the handling of buffs(effects) has changed.
The effent EVENT_EFFECT_CHANGED and ESO client BUFF&DEBUFF option don't show:

- RAPID_MANEUVER_ABILITY
- RETREATING_MANEUVER_ABILITY
- CHARGING_MANEUVER_ABILITY

anymore, instead the resulting buffs

- MAJOR_GALLOP
- MAJOR_EVASION

will be shown.

Is the this change on purpose and permanent?

ESOUIDocumentationP18 2.txt
 

In ESOUIDocumentationP18 2.txt:
has not changed for update 18.

But with Update 18 the alliance point gain (tick) will be advised when the player may already has moved to another zone.

Therefore:
Can this event be extended with an additional parameter for keep Id of tick?
This would allow to track the source (credit list) of the tick.


.

Yes, these were unified into specific buff types.

Yeah we can do something like that.

I see, thanks! As you said, all player ability ranks have been merged. How about boss abilities? There were some encounters (especially light guy and shadow dude [don't remember their names right now] in vMoL) where some buffs of the same type and name are given to different players using different abilityIDs. Have those use cases' ability ids been merged, too?

Thanks for the fast response and the clearification, I'm looking forward to see that extension!

Cheers,
Gandalf

I tried to update Circonian's LibNotifications and noticed that NOTIFICATION_TYPE_GIFT is not defined, but is used in notifications_gamepad.lua and notifications_keyboard.lua. Not sure why it doesn't throw a lua error there, but when I copy the table into LibNotifications, it does exactly that:
@Chip is this entry unused and should be removed, or is the constant just missing? And could you please make these tables global? The lib breaks on almost every update because it relies on the data in these two files. :(

I'm looking at the latest code and I don't see any references to NOTIFICATION_TYPE_GIFT anywhere. They've all been split into RECEIVED, CLAIMED, and RETURNED variants.

We can make the table globals.

Ok. That explains why I didn't see any errors. I don't have the latest code extracted yet. :o

Works like a charm, Thank you!


Just one additional question:

Pre Update 18, attack/defense tick have been granted for keep types:
- KEEPTYPE_ARTIFACT_KEEP
- KEEPTYPE_KEEP
- KEEPTYPE_OUTPOST
- KEEPTYPE_RESOURCE
- KEEPTYPE_TOWN

In update 18:
A keep and its resources will been treated as a super structure with a total of 4 credit(reward) list and
the lists will be cleared when the player is defending/attacking in another super structure. Probably when the player earns CURRENCY_CHANGE_REASON_KILL for kills/healing.

What is the handling for the other keep types (without super structure)? Will these credit list cleared as well when the player is active on another keep of the same type? E.g. Moving from one scroll temple to another?

Thanks,
Gandalf

Per the programmer responsible, you can have credit on one of each keep type, with the exception of resource keeps where you can have credit on 3 as long as they have the same parent keep.

Just a note about crafting functions which were global and removed now.
Old and removed:

Replaced by:
ZO_CraftingUtils_GetSmithingFilterFromTrait(smithingResearchLineTraitInfo)

-> See file
/esoui/ingame/crafting/smithingresearch_shared.lua
-> function ZO_SharedSmithingResearch:Refresh()

e.g. used like this:
local expectedTypeFilter = ZO_CraftingUtils_GetSmithingFilterFromTrait(GetSmithingResearchLineTraitInfo(craftingType, researchLineIndex, 1))

Hey, I just wanted to ask if turning AddOutfitSlotPreviewElementToPreviewCollection private is a permanent change or if it is something temporary as in a past PTS with PreviewCraftItem?