Update 39 (Version 9.1) - Page 2

Gelmir · 07/17/23, 12:00 PM

Originally Posted by ZOS_DanBatson

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.

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.

ExoY · 07/18/23, 06:17 AM

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.

**Baertram** · 07/18/23, 10:25 AM

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.

Navarill · 07/18/23, 12:43 PM

Originally Posted by Baertram

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.

ExoY · 07/18/23, 07:30 PM

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.

ZOS_DanBatson · 07/18/23, 09:15 PM

Originally Posted by Masteroshi430

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

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:

Code:

g_pvpKillFeedDeathRecurrenceTracker = ZO_RecurrenceTracker:New(EXPIRATION_MS, EXTENSION_MS)

which suppresses the redundant message, if any, when received:

Code:

local numOccurrences = g_pvpKillFeedDeathRecurrenceTracker:AddValue(messageKey)
if numOccurrences > 1 then
    -- Suppress redundant notifications that would otherwise result
    -- from duplicate client- and server-sourced death events.
    return nil
end

"

ZOS_DanBatson · 07/18/23, 09:23 PM

Originally Posted by Gelmir

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.

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.

Masteroshi430 · 07/19/23, 01:15 AM

Originally Posted by ZOS_DanBatson

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:

Code:

g_pvpKillFeedDeathRecurrenceTracker = ZO_RecurrenceTracker:New(EXPIRATION_MS, EXTENSION_MS)

which suppresses the redundant message, if any, when received:

Code:

local numOccurrences = g_pvpKillFeedDeathRecurrenceTracker:AddValue(messageKey)
if numOccurrences > 1 then
    -- Suppress redundant notifications that would otherwise result
    -- from duplicate client- and server-sourced death events.
    return nil
end

Thanks Dan, I will work on this.

**Baertram** · 07/19/23, 09:36 AM

Originally Posted by ExoY

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.

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.

ExoY · 07/19/23, 10:18 AM

Originally Posted by Baertram

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.

**Baertram** · 07/20/23, 02:52 AM

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

Code:

Added _arg7_
* LocalizeString(*string* _formatString_, *string* _arg1_, *string* _arg2_, *string* _arg3_, *string* _arg4_, *string* _arg5_, *string* _arg6_, *string* _arg7_)
** _Returns:_ *string* _localizedString_

ZOS_DanBatson · 07/21/23, 11:25 AM

Originally Posted by Baertram

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

Code:

Added _arg7_
* LocalizeString(*string* _formatString_, *string* _arg1_, *string* _arg2_, *string* _arg3_, *string* _arg4_, *string* _arg5_, *string* _arg6_, *string* _arg7_)
** _Returns:_ *string* _localizedString_

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.

Masteroshi430 · 07/28/23, 01:37 PM

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.

ZOS_DanBatson · 07/28/23, 03:51 PM

Originally Posted by Masteroshi430

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.

Calamath · 07/28/23, 06:20 PM

Originally Posted by ZOS_DanBatson

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...

ZOS_DanBatson · 07/31/23, 10:48 PM

Originally Posted by Calamath

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.

Calamath · 08/01/23, 02:48 AM

Originally Posted by ZOS_DanBatson

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.

**Baertram** · 08/01/23, 04:17 AM

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

Masteroshi430 · 08/04/23, 11:50 AM

Originally Posted by ZOS_DanBatson

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.

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

Code:

<Layer name="GamepadUIMode" allowFallthrough="false">
   <Category>
             <AllowAction name="RUN_ROOMBA"/>
   </Category>
</Layer>

Is there any alternative or this will still be allowed?

Masteroshi430 · 08/04/23, 11:11 PM

Originally Posted by Calamath

I guess you finally realized that.

no, I don't get it.