Update 34 (Version 8.0)

sirinsidiator · 04/18/22, 09:18 AM

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.

Links

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

**Baertram** · 04/18/22, 01:22 PM

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.

ZOS_DanBatson · 04/19/22, 01:46 PM

Documentation attached. Will try to get around to patch notes if I can find the time.

**Baertram** · 04/19/22, 03:06 PM

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

sirinsidiator · 04/19/22, 05:25 PM

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:

BLOCK_STATE_NONE = 0
BLOCK_STATE_IDLE = 1
BLOCK_STATE_ACTIVE = 2
BLOCK_STATE_DRAINED = 3
BLOCK_STATE_BLOCKED = 4
BLOCK_STATE_OVERRIDDEN = 5
BLOCK_STATE_CLIENT_REQUESTED = 6

**Baertram** · 04/19/22, 05:27 PM

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.

Phinix · 04/19/22, 07:15 PM

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

**Baertram** · 04/19/22, 07:21 PM

I can't, please ask Solinur as I was just forwarding the info.

Phinix · 04/19/22, 07:53 PM

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.

Phinix · 04/19/22, 09:19 PM

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?

secretrob · 04/19/22, 11:34 PM

If it helps anyone else the new companion collectable ids are:

Ember - 9911
Isobel - 9912

**Baertram** · 04/20/22, 02:33 AM

@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

demawi · 04/25/22, 07:15 PM

Something happened with 'GetItemCurrentActionBarSlot'. It isn't a function anymore. It's just a boolean set to 'true'.

Sharlikran · 04/25/22, 09:57 PM

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.

**Baertram** · 04/26/22, 03:05 AM

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

demawi · 04/26/22, 04:25 AM

alright. Thx to both of you.

code65536 · 04/26/22, 08:44 AM

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.

ZOS_DanBatson · 04/27/22, 12:30 PM

API Patch notes

Sharlikran · 04/27/22, 02:35 PM

* HasCompletedQuest(*integer* _questId_)
** _Returns:_ *bool* _hasCompleted_

interesting, maybe I won't have to build a table of that anymore.

**Baertram** · 04/29/22, 04:14 PM

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!

Thread Tools
Show Printable Version Email this Page
Display Modes
Linear Mode Switch to Hybrid Mode Switch to Threaded Mode