Update 34 (Version 8.0)
The next chapter "High Isle" will be available on the PTS later today.
New API Version: 101034 Notable Changes
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
|
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 Attachment(s)
Documentation attached. Will try to get around to patch notes if I can find the time.
|
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) :confused: 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: Quote:
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? Quote:
|
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:
|
PowerType constants changed
Solinur provided this information about the powertype constants:
Code:
POWERTYPE_INVALID = COMBAT_MECHANIC_FLAGS_INVALID Quote:
|
@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) 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. :) |
I can't, please ask Solinur as I was just forwarding the info.
|
OK, here are the values I get on Live vs. PTS:
Code:
LIVE: PTS (old constant): PTS (new constant): |
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? |
If it helps anyone else the new companion collectable ids are:
|
@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 |
Something happened with 'GetItemCurrentActionBarSlot'. It isn't a function anymore. It's just a boolean set to 'true'.
|
@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. |
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 |
alright. Thx to both of you.
|
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. |
1 Attachment(s)
API Patch notes
|
* HasCompletedQuest(*integer* _questId_)
** _Returns:_ *bool* _hasCompleted_ interesting, maybe I won't have to build a table of that anymore. |
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! |
All times are GMT -6. The time now is 06:57 AM. |
vBulletin © 2024, Jelsoft Enterprises Ltd
© 2014 - 2022 MMOUI