Quantcast
Update 34 (Version 8.0) - ESOUI
Thread Tools Display Modes
04/18/22, 09:18 AM   #1
sirinsidiator
 
sirinsidiator's Avatar
AddOn Author - Click to view addons
Join Date: Apr 2014
Posts: 1,514
Update 34 (Version 8.0)

The next chapter "High Isle" will be available on the PTS later today.

New API Version: 101034

Notable Changes
  • New zone, item sets, combat changes, etc.
  • New minigame "Tribute"
  • Spanish localization
  • Accessibility settings
  • AMD FidelityFX Super Resolution (FSD) support
  • Quickmenu overhaul
  • Mundus stone support in armory
  • GUI code refactor (many bugfixes)
    • TLC are now only allowed on GuiRoot
    • Textures with click handlers need their draw layer explicitly set if they overlap other mouse enabled controls (details below)
  • GetAllyUnitBlockState
  • POWERTYPE_* enums renamed to COMBAT_MECHANIC_FLAGS_* (including new values, details below)

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

LinksI'll edit the OP with more useful information as you post it and add the links as they become available.
__________________
https://www.imperialtradingcompany.eu/ - My Addons - The Vault (Early updates and experimental projects) - My patreon - My blog
>siri.exe MyAddon
Does your addon work? [y/n] n
There is a typo in there.

Last edited by sirinsidiator : 07/11/22 at 07:35 AM.
  Reply With Quote
04/18/22, 01:22 PM   #2
Baertram
Super Moderator
 
Baertram's Avatar
WoWInterface Super Mod
AddOn Author - Click to view addons
Join Date: Mar 2014
Posts: 4,205
1st start of PTS / live API101034 warning about new "accessibility mode"

At 1st PTS start there was a popup asking for the new "accessibility mode".
If enabled this will enable gamepad mode too automatically.
So beware to press R or E after start of PTS/live and read the popup.
  Reply With Quote
04/19/22, 01:46 PM   #3
ZOS_DanBatson
ZOS Staff!
 
ZOS_DanBatson's Avatar
Yes this person is from ZeniMax!
Join Date: Jul 2015
Posts: 127
Documentation attached. Will try to get around to patch notes if I can find the time.
Attached Files
File Type: txt ESOUIDocumentationP34.txt (875.8 KB, 349 views)
  Reply With Quote
04/19/22, 03:06 PM   #4
Baertram
Super Moderator
 
Baertram's Avatar
WoWInterface Super Mod
AddOn Author - Click to view addons
Join Date: Mar 2014
Posts: 4,205
Known changes:

1. TLCs (TopLevelControls) defined as <TopLevelControl within XML will be checked for their parent to be GuiRoot, else there will be an error message!
You need to change a contorl that is not a readl TopLevelControl and does not anchor to GuiRoot to be a normal control to fix this. Do not use <TopLevelControl as template or do not create it via lua's TLC functions!

2. Seems there are changes which lead to unexpected behaviour: As long/soon as a control got the movable state enabled it's child controls become non-clickable (non mouse interactale)


An explanation by Solinur about the Draw order (Tier -> Layer-> Level) has been added to the WIKI:
https://wiki.esoui.com/Drawing_Order

Info from ZOs DanBatson:
There were some changes to hit testing in the gui code to fix some inconsistencies that were discivered when implementing some new systems. Essentially when you experience these issues, it just means you need to increase the tier layer or level of the thing. The level of the two competing controls was ambiguous, and its just a matter of which one happens to show up in the tree first when testing. You need to remove the ambiguity.
Since the launch of the game, textures have a default layer of background, which is under controls, because when that decision was made, it was decided that of course you would never want to render a texture overtop of something like a button or a label, because it would cover it, making the label/button/etc pointless. But that can also be a pain in situations like this. Changing it so that textures an no longer defauted to background would be more explicit but at thise point would throw everything into complete and utter disarray.

It was annoying for us too, we had to fix a lot of places where we had been lazily not resolving the ambiguity because it "didnt hurt anything" and it caused bugs we had to fix. But the new hit testing logic can't work the old way anymore, and only the old way resolved the ambiguity passively
To fix this: You need to change the draw tier/layer of the textures/controls via SetDrawTier/SetDrawLayer or via the appropriate XML tags:
Manually providing the draw tier/layer and making them even for all the controls "at another movable control" with the "movable control" (like checkboxes, textures, whatever on a backdrop/TLC) would fix this?
Essentially yea. If you have a texture and a non texture both with default layers, and they overlap eachother, and they're both mouse enabled, you're gonna have a bad time, because textures by default are BACKGROUND, and you need to move the texture's layer up
You need to decide which one you want on top of the other

Last edited by Baertram : 05/03/22 at 04:21 AM.
  Reply With Quote
04/19/22, 05:25 PM   #5
sirinsidiator
 
sirinsidiator's Avatar
AddOn Author - Click to view addons
Join Date: Apr 2014
Posts: 1,514
The BlockState enum returned by GetAllyUnitBlockState is currently not defined. The possible values are as follows and will be added in a future update (probably not this one):
Lua Code:
  1. BLOCK_STATE_NONE = 0
  2. BLOCK_STATE_IDLE = 1
  3. BLOCK_STATE_ACTIVE = 2
  4. BLOCK_STATE_DRAINED = 3
  5. BLOCK_STATE_BLOCKED = 4
  6. BLOCK_STATE_OVERRIDDEN = 5
  7. BLOCK_STATE_CLIENT_REQUESTED = 6
__________________
https://www.imperialtradingcompany.eu/ - My Addons - The Vault (Early updates and experimental projects) - My patreon - My blog
>siri.exe MyAddon
Does your addon work? [y/n] n
There is a typo in there.

Last edited by sirinsidiator : 04/19/22 at 05:27 PM.
  Reply With Quote
04/19/22, 05:27 PM   #6
Baertram
Super Moderator
 
Baertram's Avatar
WoWInterface Super Mod
AddOn Author - Click to view addons
Join Date: Mar 2014
Posts: 4,205
PowerType constants changed

Solinur provided this information about the powertype constants:
Code:
POWERTYPE_INVALID = COMBAT_MECHANIC_FLAGS_INVALID
POWERTYPE_MAGICKA = COMBAT_MECHANIC_FLAGS_MAGICKA
POWERTYPE_HEALTH_BONUS = COMBAT_MECHANIC_FLAGS_HEALTH
POWERTYPE_WEREWOLF = COMBAT_MECHANIC_FLAGS_WEREWOLF
POWERTYPE_STAMINA = COMBAT_MECHANIC_FLAGS_STAMINA
POWERTYPE_ULTIMATE = COMBAT_MECHANIC_FLAGS_ULTIMATE
POWERTYPE_MOUNT_STAMINA = COMBAT_MECHANIC_FLAGS_MOUNT_STAMINA
POWERTYPE_HEALTH = COMBAT_MECHANIC_FLAGS_HEALTH
POWERTYPE_DAEDRIC = COMBAT_MECHANIC_FLAGS_DAEDRIC

NUM_POWER_POOLS = COMBAT_MECHANIC_FLAGS_MAX_INDEX
the powertype constants got changed
the numerical values are also different, so in case you load them from SV you might need to do a conversion.
  Reply With Quote
04/19/22, 07:15 PM   #7
Phinix
 
Phinix's Avatar
AddOn Author - Click to view addons
Join Date: Apr 2014
Posts: 186
@Baertram - Can you clarify this?

Warning: Spoiler

On the current High Isles PTS both the following return the same value:

Code:
/script local wPower = GetUnitPower('player', POWERTYPE_WEREWOLF) d(wPower)
/script local wPower = GetUnitPower('player', COMBAT_MECHANIC_FLAGS_WEREWOLF) d(wPower)

Also the same:

/script local uPower = GetUnitPower('player', POWERTYPE_ULTIMATE) d(uPower)
/script local uPower = GetUnitPower('player', COMBAT_MECHANIC_FLAGS_ULTIMATE) d(uPower)
I didn't test all of them, but if the old constants are going away, it does not appear to have happened yet.

Will the old power constants be removed at some point, or are these only in a certain context perhaps?

The values do appear different; POWERTYPE_ULTIMATE is 10 on live and 8 on PTS, etc.. However both constants still appear valid.

EDIT: Also just wanted to say thanks to sirinsidiator, ZOS_DanBatson, and everyone keeping this information up to date here.

Last edited by Phinix : 04/19/22 at 07:28 PM.
  Reply With Quote
04/19/22, 07:21 PM   #8
Baertram
Super Moderator
 
Baertram's Avatar
WoWInterface Super Mod
AddOn Author - Click to view addons
Join Date: Mar 2014
Posts: 4,205
I can't, please ask Solinur as I was just forwarding the info.
  Reply With Quote
04/19/22, 07:53 PM   #9
Phinix
 
Phinix's Avatar
AddOn Author - Click to view addons
Join Date: Apr 2014
Posts: 186
OK, here are the values I get on Live vs. PTS:

Code:
LIVE:					PTS (old constant):			PTS (new constant):
-----					-------------------			-------------------
POWERTYPE_INVALID:		= -1	POWERTYPE_INVALID:		= nil	COMBAT_MECHANIC_FLAGS_INVALID:		nil
POWERTYPE_MAGICKA:		= 0	POWERTYPE_MAGICKA:		= 1	COMBAT_MECHANIC_FLAGS_MAGICKA:		1
POWERTYPE_HEALTH_BONUS:		= 12	POWERTYPE_HEALTH_BONUS:		= 32	COMBAT_MECHANIC_FLAGS_HEALTH:		32
POWERTYPE_WEREWOLF:		= 1	POWERTYPE_WEREWOLF:		= 2	COMBAT_MECHANIC_FLAGS_WEREWOLF:		2
POWERTYPE_STAMINA:		= 6	POWERTYPE_STAMINA:		= 4	COMBAT_MECHANIC_FLAGS_STAMINA:		4
POWERTYPE_ULTIMATE:		= 10	POWERTYPE_ULTIMATE:		= 8	COMBAT_MECHANIC_FLAGS_ULTIMATE:		8
POWERTYPE_MOUNT_STAMINA:	= 11	POWERTYPE_MOUNT_STAMINA:	= 16	COMBAT_MECHANIC_FLAGS_MOUNT_STAMINA:	16
POWERTYPE_HEALTH:		= -2	POWERTYPE_HEALTH:		= 32	COMBAT_MECHANIC_FLAGS_HEALTH:		32
POWERTYPE_DAEDRIC:		= 13	POWERTYPE_DAEDRIC:		= 64	COMBAT_MECHANIC_FLAGS_DAEDRIC:		64
NUM_POWER_POOLS:		= 10	NUM_POWER_POOLS:		= 7	COMBAT_MECHANIC_FLAGS_MAX_INDEX:	7
Seems like the values are different but both constant alias are still valid.
  Reply With Quote
04/19/22, 09:19 PM   #10
Phinix
 
Phinix's Avatar
AddOn Author - Click to view addons
Join Date: Apr 2014
Posts: 186
I notice changes in several events and functions from "CombatMechanicType" to "CombatMechanicFlags," which I am assuming correlates to these powerType changes. From a functional standpoint, so long as these values aren't being hard-coded in saved variables, there shouldn't really be any impact of this, so far as I can tell.

My main question right now is, will the original constant alias names eventually go away? In which case, will all functions doing things like GetUnitPower('player', POWERTYPE_ULTIMATE) need to eventually be updated to GetUnitPower('player', COMBAT_MECHANIC_FLAGS_ULTIMATE)? Or will both continue to work/exist as they do on the current PTS?
  Reply With Quote
04/19/22, 11:34 PM   #11
secretrob
AddOn Author - Click to view addons
Join Date: Jul 2021
Posts: 1
If it helps anyone else the new companion collectable ids are:
  • Ember - 9911
  • Isobel - 9912
  Reply With Quote
04/20/22, 02:33 AM   #12
Baertram
Super Moderator
 
Baertram's Avatar
WoWInterface Super Mod
AddOn Author - Click to view addons
Join Date: Mar 2014
Posts: 4,205
@Phinix Thanks for the update
Normally the constants will not go away, or if they get moved to an addon compatibility file within the ESOUi sources where they are kept for a decent time/forever, depending how often and long they have been used already.

EsoUI\Ingame\AddonCompatibilityAliases\PC\AddonCompatibilityAliases.lua
EsoUI\Ingame\AddonCompatibilityAliases\PC\AddonCompatibilityAliases.xml

Last edited by Baertram : 04/20/22 at 06:58 AM.
  Reply With Quote
04/25/22, 07:15 PM   #13
demawi
Join Date: Dec 2019
Posts: 2
Something happened with 'GetItemCurrentActionBarSlot'. It isn't a function anymore. It's just a boolean set to 'true'.
__________________
developer of Rulebased Inventory
  Reply With Quote
04/25/22, 09:57 PM   #14
Sharlikran
 
Sharlikran's Avatar
AddOn Author - Click to view addons
Join Date: Apr 2014
Posts: 389
@demawi

Search the documentation for "ActionBarSlotType" to start with.

I have no idea what the previous command did but using that I found

SelectSlotSimpleAction *protected* (*[ActionBarSlotType|#ActionBarSlotType]* _actionType_, *integer* _actionId_, *luaindex* _actionSlotIndex_, *[HotBarCategory|#HotBarCategory]:nilable* _hotbarCategory_)

More then likely it did not break, it was significantly altered? Just thinking out loud as I look.

I can see GetItemCurrentActionBarSlot() in the Alias files.

https://github.com/esoui/esoui/blob/....lua#L739-L741

Maybe FindActionSlotMatchingItem(bagId, slotIndex) but I don't know if it has the same functionality.
__________________
Admin for TES5Edit, occasional LOOT masterlist contributor, and Wrye Bash contributor. I also maintain special Fallout 3 and Fallout NV versions of Wrye Flash.
  Reply With Quote
04/26/22, 03:05 AM   #15
Baertram
Super Moderator
 
Baertram's Avatar
WoWInterface Super Mod
AddOn Author - Click to view addons
Join Date: Mar 2014
Posts: 4,205
It was removed from the addon compatibility aliases files with PTS v8.0 as you can see here:
https://github.com/esoui/esoui/blob/...ityaliases.lua

Should be FindActionSlotMatchingItem(bagId, slotIndex) now as it was the same code that the function returned in that alias, like Sharlikran said already.
As you can see here it is used in ZOs code on PTS 8.0
https://github.com/esoui/esoui/blob/...slot.lua#L1568
  Reply With Quote
04/26/22, 04:25 AM   #16
demawi
Join Date: Dec 2019
Posts: 2
alright. Thx to both of you.
__________________
developer of Rulebased Inventory
  Reply With Quote
04/26/22, 08:44 AM   #17
code65536
AddOn Author - Click to view addons
Join Date: Mar 2016
Posts: 19
I am encountering what appears to be a bug in update 34.

Demonstrated in this video:
https://youtu.be/ax-UQgR8_hY

The tooltip for the death recap has a draw tier of HIGH, a draw layer of OVERLAY, and a draw level of 10000.

It initially renders behind some controls.

Until the user clicks on any part of the addon (even a blank area that is not mouse-enabled), and then it fixes itself.

The problem remains fixed until the user relogs or reloads.

This was not a problem in Update 33 and is new in Update 34.
  Reply With Quote
04/27/22, 12:30 PM   #18
ZOS_DanBatson
ZOS Staff!
 
ZOS_DanBatson's Avatar
Yes this person is from ZeniMax!
Join Date: Jul 2015
Posts: 127
API Patch notes
Attached Files
File Type: txt APIPatchNotesP34.txt (48.6 KB, 318 views)
  Reply With Quote
04/27/22, 02:35 PM   #19
Sharlikran
 
Sharlikran's Avatar
AddOn Author - Click to view addons
Join Date: Apr 2014
Posts: 389
* HasCompletedQuest(*integer* _questId_)
** _Returns:_ *bool* _hasCompleted_

interesting, maybe I won't have to build a table of that anymore.
__________________
Admin for TES5Edit, occasional LOOT masterlist contributor, and Wrye Bash contributor. I also maintain special Fallout 3 and Fallout NV versions of Wrye Flash.
  Reply With Quote
04/29/22, 04:14 PM   #20
Baertram
Super Moderator
 
Baertram's Avatar
WoWInterface Super Mod
AddOn Author - Click to view addons
Join Date: Mar 2014
Posts: 4,205
Attention for quickslot related or weapon bar / action button related addons
All kind of GetSlot* functions for the action- and quickslots have changed their parameters and need a 2nd parameter HOTBAR_CATEGORY_* now to detect the correct abilityId, itemLink, etc.

e.g. GetSlotBoundId(slotNr, HOTBAR_CATEGORY_*) where the hotbar category of the default quickslots would be HOTBAR_CATEGORY_QUICKSLOT_WHEEL and the one for weapon bar 1 would be HOTBAR_CATEGORY_PRIMARY

Some of the hotbar_category parameters are nilable so the game maybe pick teh currently selected one if not provided.

As the parameter was "inserted" as 2nd param (if the current 2nd, 3rd etc params could be nil) it might be that your functions have wrong parameters passed in now, so check you code! Else your passed in variables might be a number and define any of the HOTBAR_CATEGORY_* constants "by accident"!

Also important:
The variable ACTION_BAR_FIRST_UTILITY_BAR_SLOT is not existing anymore.
The quickslots actionBar slot is 1 now and not 8 (ACTION_BAR_UTILITY_BAR_SIZE) anymore as it seems!

Last edited by Baertram : 04/29/22 at 04:58 PM.
  Reply With Quote

ESOUI » Developer Discussions » Tutorials & Other Helpful Info » Update 34 (Version 8.0)

Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

vB code is On
Smilies are On
[IMG] code is On
HTML code is Off