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.
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.
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)
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
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
Last edited by sirinsidiator : 04/19/22 at 05:27 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?
@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.
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
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!