Update 39 (Version 9.1)

[sirinsidiator]

The next major update will be available on the PTS later today.

New API Version: 101039

Notable Changes

• New item sets, monster masks, furnishing, endeavours, combat changes, item set sourcing changes etc.
• PvP Death Notifications
• QoL improvements (re-summon companions after using assistants, stack daily rewards with crown store items, prevent loss of event tickets on loot, etc.)
• Improved game experience for new players (many small adjustments)
• Many bug fixes for quests in old zones
• Occlusion Culling graphics setting

PTS Dev Guild
We have created guilds on the EU and NA server for all addon developers, which get copied over during the PTS cycle for a new update, so we can test guild related things, ask for help with testing or just chat. If you need an invite, ask here or over on our Matrix channel. You are also free to join them on the live servers so you don't always have to be reinvited when the PTS is wiped.

Links

• API Patch Notes (changes in P39_2)
• PTS Patch Notes 9.1.0 (code changes from 9.0.6)
• PTS Patch Notes 9.1.1 (code changes from 9.1.0)
• PTS Patch Notes 9.1.2 (code changes from 9.1.1)
• PTS Patch Notes 9.1.3 (code changes from 9.1.2)
• PTS Patch Notes 9.1.4 (code changes from 9.1.3)
• Patch Notes 9.1.5 (code changes from 9.1.4) (code changes from 9.0.8)
• ESOUIDocumentation.txt
• ESOUI source code
• Official PTS forum for feedback
• Thread for Update 38 (Version 9.0)

I'll edit the OP with more useful information as you post it and add the links as they become available.

[ZOS_DanBatson]

Documentation

[Masteroshi430]

Originally Posted by ZOS_DanBatson Documentation

The forced disabled addon feature is a "security" measure you guys can activate in the future if an addon does unallowed things or do you plan to disable addons for some part(s) of the game?

[ZOS_DanBatson]

The add-on disabling tech is just there in case something catastrophic happens on the order of what happened a few releases ago with NodeDetection crashing clients. Basically a way that we can help players mitigate the bad experience until a solution is put in. Players still have the ability to turn the add-on back on if they so choose, at which point that's expected to be a caveat emptor situation.

It is not a system to prevent exploits or add-ons doing shenanigans, nor is it meant as official approval/disapproval of an add-on. If things work out the way I predict they will, we will literally never even use the feature. But it gives the studio peace of mind of having a tool in our toolkit to help when a crash is introduced and a large number of players are struggling to get past it.

Again, using the NodeDetection thing as an example: ZOS introduced a crash that NodeDetection happened to be tripping over with logic that had historically always been fine. It wasn't a problem with NodeDetection itself. But it would have been nice to be able to disable NodeDetection for people temporarily to help them stop crashing while it got sorted out. And a lot of players use HarvestMap.

It's not a lock down, merely a soft disable on the players' behalf that they can undo locally at will.

[Gelmir]

FYI: With Necrom, some *.png.dds files (duplicates of their *.dds counterparts) started to popup inside /esoui/art folder.

[ghostbane]

Thank you for the files Dan!

1) The new EVENT_PVP_KILL_FEED_DEATH, it will be returning a string of the location name? Would it be possible to have a keepId returned as well for applicable areas?

2) If such a thing is possible, would it further be possible to add an event filter on location? ( Edit: Nevermind, realised there is no Unit Tags )

No harm in asking!

[EHansonn]

am I crazy or does the EVENT_PVP_KILL_FEED_DEATH event trigger twice? I was testing it with an alt and it looked to me like it would trigger twice per kill for me

[ZOS_DanBatson]

Originally Posted by Gelmir FYI: With Necrom, some *.png.dds files (duplicates of their *.dds counterparts) started to popup inside /esoui/art folder.

Can you give me examples?

[ZOS_DanBatson]

Originally Posted by ghostbane Thank you for the files Dan! 1) The new EVENT_PVP_KILL_FEED_DEATH, it will be returning a string of the location name? Would it be possible to have a keepId returned as well for applicable areas? 2) If such a thing is possible, would it further be possible to add an event filter on location? ( Edit: Nevermind, realised there is no Unit Tags ) No harm in asking!

We can take a look and see how readily available that keep info is

[ghostbane]

Originally Posted by ZOS_DanBatson We can take a look and see how readily available that keep info is

Thanks Dan, that keepId should cover all tickable areas and would make this event extra useful!

[Masteroshi430]

Originally Posted by ZOS_DanBatson Can you give me examples?

I found some on PTS:
/esoui/art/icons/gear_celestial_1haxe_a.png.dds
/esoui/art/icons/gear_celestial_1hhammer_a.png.dds
/esoui/art/icons/gear_celestial_1hsword_a.png.dds
/esoui/art/icons/gear_celestial_2haxe_a.png.dds
/esoui/art/icons/gear_celestial_2hhammer_a.png.dds
/esoui/art/icons/gear_celestial_2hsword_a.png.dds
/esoui/art/icons/gear_celestial_bow_a.png.dds
/esoui/art/icons/gear_celestial_dagger_a.png.dds
/esoui/art/icons/gear_celestial_shield_a.png.dds
/esoui/art/icons/gear_celestial_staff_a.png.dds
/esoui/art/icons/gear_falkreath_bow_a.png.dds
/esoui/art/icons/gear_scalecallerbg_mace_a.png.dds
/esoui/art/icons/gear_undgrothdarr_1hmace_a.png.dds

[ZOS_DanBatson]

Looks like these files have been there for the last 5 years or so. I can see if art wants to clean them up though.

[Anthonysc]

So the new

"GetNumKillLocationAllianceKills" function would seem to be related to the

In Cyrodiil and Imperial City specifically, you will also get more information on “crossed swords” showing who’s currently winning in that particular fight.

patch note, correct? In that it is able to return how many deaths occured of each alliance?

* GetNumKillLocationAllianceKills(*luaindex* _index_, *[Alliance|#Alliance]* _alliance_)
** _Returns:_ *integer* _numKills_

Is the luaindex used the same as used for GetKillLocationPinInfo returned by looping over GetNumKillLocations?

I would suspect that it would be, but seemed reasonable to check.

[Masteroshi430]

Originally Posted by Anthonysc So the new "GetNumKillLocationAllianceKills" function would seem to be related to the patch note, correct? In that it is able to return how many deaths occured of each alliance? * GetNumKillLocationAllianceKills(*luaindex* _index_, *[Alliance|#Alliance]* _alliance_) ** _Returns:_ *integer* _numKills_ Is the luaindex used the same as used for GetKillLocationPinInfo returned by looping over GetNumKillLocations? I would suspect that it would be, but seemed reasonable to check.

So we use to iterate GetKillLocationPinInfo(*luaindex* _index_) with GetNumKillLocations() to get pintype and X Y coordinates of the pin, according to pintype we will use GetNumKillLocationAllianceKills(*luaindex* _index_, *[Alliance|#Alliance]* _alliance_) ?

it looks like EVENT_PVP_KILL_FEED_DEATH is feeding GetNumKillLocationAllianceKills does anybody knows how many kills per alliance per location is needed to be considered a kill location?

[Gelmir]

Originally Posted by ZOS_DanBatson Can you give me examples?

"\esoui\art\icons\gear_celestial_dagger_a.png.dds"
"\esoui\art\icons\gear_celestial_shield_a.png.dds"
"\esoui\art\icons\gear_celestial_1hhammer_a.png.dds"
"\esoui\art\icons\gear_celestial_1hsword_a.png.dds"
"\esoui\art\icons\gear_celestial_2haxe_a.png.dds"
"\esoui\art\icons\gear_celestial_2hhammer_a.png.dds"
"\esoui\art\icons\gear_celestial_2hsword_a.png.dds"
"\esoui\art\icons\gear_celestial_1haxe_a.png.dds"
"\esoui\art\icons\gear_falkreath_bow_a.png.dds"
"\esoui\art\icons\gear_scalecallerbg_mace_a.png.dds"
"\esoui\art\icons\gear_undgrothdarr_1hmace_a.png.dds"
"\esoui\art\icons\gear_celestial_staff_a.png.dds"
"\esoui\art\icons\gear_celestial_bow_a.png.dds"

[Gelmir]

Originally Posted by ZOS_DanBatson Looks like these files have been there for the last 5 years or so. I can see if art wants to clean them up though.

Uhmm, not really I regularly extract those icons. They appeared with Necrom PTS, and with that, their real counterparts actually weren't there. Then it got fixed: real files were added (possibly in subsequent patches?). Since I always work with PTS files, it is possible the actuals were released during Necrom live release. Anyhow, I know this because my website - guildplanner.pro - started 404'ing on those files. Then after investigating, I noticed these .png.dds files, renamed them. Did search, didn't find actuals, not until recently. That isn't big issue though, just wanted to let you guys know.

[ZOS_DanBatson]

Originally Posted by Gelmir Uhmm, not really I regularly extract those icons. They appeared with Necrom PTS, and with that, their real counterparts actually weren't there. Then it got fixed: real files were added (possibly in subsequent patches?). Since I always work with PTS files, it is possible the actuals were released during Necrom live release. Anyhow, I know this because my website - guildplanner.pro - started 404'ing on those files. Then after investigating, I noticed these .png.dds files, renamed them. Did search, didn't find actuals, not until recently. That isn't big issue though, just wanted to let you guys know.

I don't know what to tell you, these files got checked in in 2018. If something in the publishing pipeline was doing shenanigans with them before the reach PTS, I couldn't say, I don't have any control over that part of the process. But yes, definitely they've been in the depot since 2018.

Regardless, we cleaned those names up yesterday. Some were unused dupes of better named variants, and 3 needed to be renamed and re-referenced.

[Gelmir]

Originally Posted by ZOS_DanBatson Regardless, we cleaned those names up yesterday. Some were unused dupes of better named variants, and 3 needed to be renamed and re-referenced.

Nice! That's all that matters

[Anthonysc]

Originally Posted by Masteroshi430 So we use to iterate GetKillLocationPinInfo(*luaindex* _index_) with GetNumKillLocations() to get pintype and X Y coordinates of the pin, according to pintype we will use GetNumKillLocationAllianceKills(*luaindex* _index_, *[Alliance|#Alliance]* _alliance_) ? it looks like EVENT_PVP_KILL_FEED_DEATH is feeding GetNumKillLocationAllianceKills does anybody knows how many kills per alliance per location is needed to be considered a kill location?

“Crossed sword” indicators are displayed when there have been 3 or more kills in an area within a short period of time, and last for 30 seconds after their initial creation if no more deaths occur.

From the PTS patch notes in the "PvP Death Notifications". It doesn't say anything about per alliance, so I think its just 3 kills total then the game reports the skirmish information based on killed and killer alliance regardless if no one from one of the involved alliances was killed.
It's my sincere hope that if no one from an alliance was killed, and you query that alliance in "GetNumKillLocationAllianceKills" it actually returns 0 and not nil.

[Masteroshi430]

Originally Posted by Anthonysc From the PTS patch notes in the "PvP Death Notifications". It doesn't say anything about per alliance, so I think its just 3 kills total then the game reports the skirmish information based on killed and killer alliance regardless if no one from one of the involved alliances was killed. It's my sincere hope that if no one from an alliance was killed, and you query that alliance in "GetNumKillLocationAllianceKills" it actually returns 0 and not nil.

I used a minimum of 10 kills including the 3 alliances at a location to add the notification and 5 minutes without kill at the location to remove the notification in CyrHUD.
I'll see if I fine tune/modify this when U39 goes live because it is impossible to test this on PTS due to the low number of players there.

Note:
EVENT_PVP_KILL_FEED_DEATH bugs:
- Triggers once when you commit suicide with slaughterfish (you are then both the killer and the victim)
- triggers twice when another player kills you
I hope these will be fixed before U39 goes live