Update 39 (Version 9.1) - Page 3

**Baertram** · 08/05/23, 07:01 AM

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.

ZOS_DanBatson · 08/07/23, 01:31 PM

Originally Posted by Masteroshi430

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?

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.

Masteroshi430 · 08/07/23, 11:25 PM

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

Code:

 \esoui\app\globals\bindings.xml (1 hit)
	Line 2:     <Layer name="LoadingScreen" allowFallthrough="false">
 \esoui\ingame\globals\bindings.xml (9 hits)
	Line  524:     <Layer name="GamepadUIMode" allowFallthrough="false">
	Line  691:     <Layer name="SI_KEYBINDINGS_LAYER_SIEGE" allowFallthrough="false">
	Line  720:     <Layer name="SI_KEYBINDINGS_LAYER_DIALOG" allowFallthrough="false">
	Line  802:     <Layer name="SI_KEYBINDINGS_LAYER_ACCESSIBLE_QUICKWHEEL" allowFallthrough="false">
	Line  891:     <Layer name="PlayerToPlayerAccessibleLayer" allowFallthrough="false">
	Line 1310:     <Layer name="GamepadChatSystem" allowFallthrough="false">
	Line 1458:     <Layer name="ScreenshotMode" allowFallthrough="false">
	Line 1498:     <Layer name="SI_KEYBINDINGS_LAYER_HOUSING_EDITOR" allowFallthrough="false">
	Line 1614:     <Layer name="SI_KEYBINDINGS_LAYER_HOUSING_EDITOR_PLACEMENT_MODE" allowFallthrough="true">
 \esoui\internalingame\globals\bindings.xml (2 hits)
	Line   2:     <Layer name="SI_KEYBINDINGS_LAYER_DIALOG" allowFallthrough="false">
	Line 274:     <Layer name="MarketAnnouncement" allowFallthrough="false">
 \esoui\pregame\globals\bindings.xml (1 hit)
	Line 242:     <Layer name="SI_KEYBINDINGS_LAYER_DIALOG" allowFallthrough="false">

**Baertram** · 08/08/23, 01:55 AM

More specifically, overwriting an existing action layer and trying to change allowFallthrough from what it already was to the opposite is not supported.
...
Again, it is only a problem if you try to change the value of allowFallthrough.

"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

)

Masteroshi430 · 08/08/23, 02:23 AM

Originally Posted by Baertram

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

**Baertram** · 08/08/23, 07:05 AM

Originally Posted by Masteroshi430

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

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

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

Code:

<Layer name="SI_KEYBINDINGS_LAYER_GENERAL">
        <Category name="SI_KEYBINDINGS_CATEGORY_MOVEMENT">
            <Action name="MOVE_FORWARD">

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

Code:

<Layer name="SI_KEYBINDINGS_LAYER_GENERAL">
        <Category name="SI_KEYBINDINGS_CATEGORY_MOVEMENT">
            <Action name="MOVE_BACKFLIPP">

You define the surrounding tags and attributes and create a new keybind possibility that way, which is named "MOVE_BACKFLIPP".
Nothing overwritten.

Why this second language, in what cases I should use it over LUA...

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.

Masteroshi430 · 08/08/23, 07:21 AM

Thanks for the infos Baertram!

ZOS_DanBatson · 08/08/23, 12:49 PM

Originally Posted by Masteroshi430

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

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.

Masteroshi430 · 08/08/23, 01:53 PM

Originally Posted by ZOS_DanBatson

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.

ZOS_DanBatson · 08/21/23, 08:44 AM

Documentation 2

Masteroshi430 · 08/23/23, 11:16 AM

Note: EVENT_PVP_KILL_FEED_DEATH should read:

Lua Code:

* EVENT_PVP_KILL_FEED_DEATH (*string* _killLocation_, *string* _killerPlayerDisplayName_, *string* _killerPlayerCharacterName_, *[Alliance|#Alliance]* _killerPlayerAlliance_, *integer* _killerPlayerRank_, *string* _victimPlayerDisplayName_, *string* _victimPlayerCharacterName_, *[Alliance|#Alliance]* _victimPlayerAlliance_, *integer* _victimPlayerRank_)

@DisplayName first then CharacterName for both killer and victim, the documentation will be corrected later.

Toirealach · 08/23/23, 12:58 PM

Originally Posted by ZOS_DanBatson

Note about the trigger twice thing:

"The client will raise two consecutive kill events...

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

"

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.

ZOS_DanBatson · 08/28/23, 12:48 PM

Originally Posted by Toirealach

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.