Update 39 (Version 9.1)
 

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.

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?

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.

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

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!

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

Can you give me examples?

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!

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

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.

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?

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?

"\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"

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.

Nice! That's all that matters :)

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

Dan, I just exported set data from ingame ItemSetCollections. Only "/esoui/art/icons/gear_falkreath_bow_a.png.dds" file remains there, which seemingly was forgotten. It's used for "Ironblood", "Draugr's Rest" and "Pillar of Nirn" sets. Just 3 occurences. The rest seems to be fixed.

Would it be possible for the future to have access to all the different assistances on the PTS?

Just having them available in the crown store would already be enough.

If you use a template char on PTS you should be able to buy all assistances from crown store for 1 crown, unless I'm missing something.

I think the issue is that they're not all available in the crown store on PTS.

Yeah, the Crownstore on PTS only includes the basic banker, trader and i think the armory guy.

The deconstructor woman as well as all other variations of the banker, trader and amory are missing.

Note about the trigger twice thing:

"The client will raise two consecutive kill events to Lua when the victim dies within two detection cells. The reason is that both our local trigger - detected via the Unit's SetDead method - and the server-based "crossed swords" trigger (sent via Region->Client message) fire that kill event.

Rather than having the client try to determine whether the kill occurred within the larger, 10-ish detection radius of any in-range crossed swords or having the server try to determine whether the kill was within the client's two detection cell range... the server just sends the event regardless, as does the Unit::SetDead "local" logic.

To safeguard against this, ChatHandlers.lua creates a singleton:
which suppresses the redundant message, if any, when received:
"

The cleanup of those assets has not been merged to PTS. We're not tracking the change for PTS, they'll be cleaned up in P40.

Thanks Dan, I will work on this. :)

This is weird as I got all the bankers on PTS somehow, one day.
Maybe they change during the PTS updates each week, like events change and server data changes from NA to EU too?
Or it was available for me because I owned some of the assistants on EU server and got them that way.

I checked during last pts cycle and the content of the crownstore regarding the assistants sadly never changed.

Info:
zo_strformat(formatString, ...) and ZO_CachedStrFormat can use 7 params on PTS now (increased from 6)
->

I plan on making it 10 later but I need to take some time to rethink how it currently works. Don't want all calls in the whole game to zo_strformat suddenly taking up more memory/time.

Note:
"allowFallthrough" in the XML currently causes the game to crash internally, it will be fixed in a future update and the use "allowFallthrough" will then raise an UI error.
If you have this in your xml files it has to be removed.
I already removed it in the Personal Assistant and Roomba addons as requested by (ZOS) Dan Batson.

More specifically, overwriting an existing action layer and trying to change allowFallthrough from what it already was to the opposite is not supported. Personal Assistant was invoking vanilla action layers and trying to set allowFallthrough to false when vanilla had already set them to true. And that's not kosher.

ZOS_DanBatson,
I understand that setting allowFallthrough differently for the vanilla action layer is a no-go and will cause UI errors in the future.

Am I correct in assuming that it is OK to set allowFallthrough to my own actions that inherit bindings from others, or to set allowFallthrough to my own action layer?

I missed this note and wanted to make a personal note about the exact usage.
There are also configuration items such as preventAutomaticInputModeChange and allowOnInputModeChange in the XML.

The action layer is a monster, so I don't think about doing anything carelessly...;)

The only issue lies with trying to change the value on an already existing action layer. Inheriting and choosing a different value is fine because it's still its own new layer. Also AFAIK the limitation lies solely with the allowFallthrough attribute.

Thank you for taking the time to clarify, Dan Batson.
I understood very well. We are required to check the description for our add-on's binding.xml. :)

I've updated the WIKI with that info, at:
https://wiki.esoui.com/Key_bindings

References: https://wiki.esoui.com/Keybindings

Feel free to update/Add/change the info about action layers and keybinds there

My headache of the day:
To allow using custom keybinds in menus with gamepad mode we have to use this though:

Is there any alternative or this will still be allowed?

no, I don't get it.

Guys, please keep this thread clean from conversations and only add valuable insights about "this patch / update"!
It's meant to be an aid for addon updates/fixes for this upcoming patch, now on PTS.

If you want to clarify things that belong to this update do so in gitter/element chat or PMs or another forum thread and then add the info/outcome here.

If you need to clarify general things, not related to this update, do so and add it to the Wiki please so we all benefit from it.

Many thanks.


Edit:
@Masteroshi: Afai understood:
If your gamepad keybind post was about allowFallthrough="false": As Dan explained you cannot use "true" as it would overwrite some default action layer and make the client crash atm.
As you use "false" it should work.

If you defne your own action layer not using vanilla game layers you can also use allowFallthrough="true".

If your post was about something else in the keybind definition: I do not see what it related to.

Again, it is only a problem if you try to change the value of allowFallthrough. Since the vanilla's value for GamepadUIMode is already allowFallthrough="false" you're perfectly fine to do what you did, because you aren't trying to change it to true.

So to be 100% clear:
These are the allowFallthrough in the ESOUI code, they are all set to false except SI_KEYBINDINGS_LAYER_HOUSING_EDITOR_PLACEMENT_MODE, it is not allowed to set these layers to true except for SI_KEYBINDINGS_LAYER_HOUSING_EDITOR_PLACEMENT_MODE.

Now what if for some reason I set SI_KEYBINDINGS_LAYER_HOUSING_EDITOR_PLACEMENT_MODE to false, is it ok?

Is the guideline "don't set to true when we set it to false" or "don't switch it"?

"what it already was to the opposite" or "Change" means:
if true, do no set it to false (or other values that might even fail to work at all then ;))
if false, do not set it to true (or other values that might even fail to work at all then ;))

OK, what I don't get yet is why do we have to set it to the same value if it is already set :

vanilla code is :
<Layer name="GamepadUIMode" allowFallthrough="false">

but I have to set this to allow using custom keybinds in menus with gamepad mode :
<Layer name="GamepadUIMode" allowFallthrough="false">
if I use this :
<Layer name="GamepadUIMode" >
then it doesn't work.

Is our XML totally overwriting the vanilla XML to the point we have to set all the variables that are in the tags again?

I think my problem is a misunderstanding of the XML and it's purpose...
Why this second language, in what cases I should use it over LUA...

As far as I know:
Yes. It's the same for lua and all other codes.
If someone defined some code (ZOs vanillla, or any other addon) but you need to change it again "later" you need to hook it, or overwrite it to add new code, or to change it somehow.
For lua you can prehook or posthook it to add your additional code.

For XML there is no such feature so if you define the same "name" you will overwrite existing XML code.
Normally this fails and says "Control already exists with same name" (if you were using a <Control> xml tag e.g.).
But for some xml tags like the <Bindings> <Layer> you will just redefine (if it exists in vanilla code, or another addon which was loaded before your's was loaded) the layer data then.
> This will overwrite the parts you did specify in your xml data then.

e.g. if you redefine
It either fails and says not allowed as some of the keybinds are protected afaik.
Or it will overwrite the MOVE_FORWARD with your definition then.

And if you add a new one which didn't exist yet
You define the surrounding tags and attributes and create a new keybind possibility that way, which is named "MOVE_BACKFLIPP".
Nothing overwritten.

In the case of keybindings as you cannot define keybindings via lua only.
And in any other case where you feel it's more easy to create UI elements via XML instead of using lua do dynamically create the controls.
And in any case where you define virtual templates for lua controls in XML and just load them via lua functions then that accept virtual template names as parameters (as virtual templates cannot be created without XML, in lua, afaik).



In your example with "<Layer name="GamepadUIMode" allowFallthrough="false">"
It was defined with that attribute allowFallthrough="false" and if you redefine (overwrite) that row again by removing allowFallthrough="false" it will fail to work properly as this was not intended to work/is not supported. (no client crash and no error message, just silently fails).
Same if you change that to "true" -> client crash (maybe error message in the future).

I'm not sure if there is any list which atributes in the XML behave like that.
e.g. would it behave the same if it would haven been hideAction="true" in original definition and you overwrite it with hideAction="false" or just remove the hideAction attribute in total? I don't know but I think it would behave the same (hopefully except the "client crash" :-)).
Else you might be able to change the general idea/usage of those keybinds by just removing info like "do not allow to be pressed while dead" etc.

Thanks for the infos Baertram! :)

The default for allowFalthrough (if you don't specify it) is true. So by omitting it, that's the same as saying true. Meaning you're trying to change it from false to true, which is a no-no.

Ah! That explains a lot! Thanks!
That is totally counter intuitive because in my mind a non-set bool is false, but here there is a default true value... Okay I'll keep that in mind.
:)

Documentation 2

Note: EVENT_PVP_KILL_FEED_DEATH should read:
@DisplayName first then CharacterName for both killer and victim, the documentation will be corrected later.

Suppressing redundant PvP Kill Feed events
 

Dan, in looking at your code in chat handlers, is your fall off time 10 seconds there?

So if a killer kills the same victim twice within 10 seconds that only one death notice is posted?

I'm asking because I have definitely killed someone in Cyrodiil that just put down a camp and they take the camp immediately and I kill them a second time in less than ten seconds.

In this case is only one death notice posted?

If so, you might want to consider cutting that fall off time in half to 5 seconds.

The 10 second timer is based around how the server sends down kill location information in 10 second intervals. That said, we will make a change that makes the recurrence tracker only consider dupes between local kills and server broadcast kill location kills. So two client-determined "nearby" kills won't ever be considered dupes of each other. That change will come in P40.