ESOUI - Upcoming Combat and Effect API Changes

ESOUI (https://www.esoui.com/forums/index.php)

- General Authoring Discussion (https://www.esoui.com/forums/forumdisplay.php?f=174)

- - Upcoming Combat and Effect API Changes (https://www.esoui.com/forums/showthread.php?t=4810)

THANK you VERY VERY VERY much for opening this!!!!!!! :)

Quote:

Originally Posted by ZOS_ChipHilseberg (Post 21696)

We've added a new function called GetAbilityIcon which takes the ability id and returns its icon path. We've also modified COMBAT_EVENT to pass numerical identifiers for the source and target so units with the same name can be separated. This ids are good for as long as the unit exists on the client. The same is true of EFFECT_UPDATED and its unit.

Will the source and target IDs be unique through all NPCs in the game or just unique for the targets that are involved in the current combat? My idea was to separate the dungeon bosses to enable a boss kill tracker based on these IDs ;)

Some nice changes BTW!

Keldor

@ZOS_ChipHilseberg

It would be really useful with a hook to the source and target in the EVENT_COMBAT_EVENT.

Currently the workarounds for certain lookups are painful and cause performance issues, would it be possible to either get unitTags for target and source or a reverse lookup for a unitTag using a target/source name?

The idea is to resolve information such as: alliance, class, race etc.

I added a page about the event filters to the wiki because it wasn't documented there yet. Maybe somebody who already worked with them can check or extend it a bit?

I have some questions regarding AddFilterForEvent.

Specifying multiple filters in one call -- AND?
I assume this limits the event handler to ultimate AND player, right?

Lua Code:

EVENT_MANAGER:AddFilterForEvent("ZO_ActionBar", EVENT_POWER_UPDATE, REGISTER_FILTER_POWER_TYPE, POWERTYPE_ULTIMATE, REGISTER_FILTER_UNIT_TAG, "player")

Multiple calls to AddFilterForEvent -- OR?
Would this limit the handler to events related to player ultimate OR boss health?

Lua Code:

EVENT_MANAGER:AddFilterForEvent("ZO_ActionBar", EVENT_POWER_UPDATE, REGISTER_FILTER_POWER_TYPE, POWERTYPE_ULTIMATE, REGISTER_FILTER_UNIT_TAG, "player")
EVENT_MANAGER:AddFilterForEvent("ZO_ActionBar", EVENT_POWER_UPDATE, REGISTER_FILTER_POWER_TYPE, POWERTYPE_HEALTH, REGISTER_FILTER_UNIT_TAG, "boss")

Lifespan of filters
Are filters reset upon UnregisterForEvent, or do they persist "forever"? I couldn't find any reset/clear function.

It seems regardless of how you register them it is always OR. I register my filter like this:

Lua Code:

local filters = {
    REGISTER_FILTER_COMBAT_RESULT, ACTION_RESULT_DIED,
    REGISTER_FILTER_COMBAT_RESULT, ACTION_RESULT_DIED_XP,
    REGISTER_FILTER_COMBAT_RESULT, ACTION_RESULT_KILLING_BLOW,
}
EVENT_MANAGER:AddFilterForEvent(handle, EVENT_COMBAT_EVENT, unpack(filters))

and receive events for any of the 3 cases.

The lifetime is something I would be interested in too. I register them multiple times right now. No idea if that is necessary, or maybe even causes some trouble.

All forms of registration should function as AND. If any of the filters fail the event will not be sent. When the event is unregistered the filter will be cleared.

Are these filters easily and cheaply (from both development and runtime perspective) extensible to other events? I'm thinking about EVENT_INVENTORY_SINGLE_SLOT_UPDATE:
REGISTER_FILTER_BAG_ID
REGISTER_FILTER_IS_NEW_ITEM
REGISTER_FILTER_INVENTORY_UPDATE_REASON

Quote:

Originally Posted by merlight (Post 24128)

That would be a nice one to have !

I don't think it'll be a problem to add most of these. I'll throw it on the backlog.

Quote:

Originally Posted by ZOS_ChipHilseberg (Post 21642)

For the unique ID we're looking at providing a number to identify each instance with the same name. Players will always be 0 (since their name should be unique anyway) and non-players will have an arbitrary number that will be the same as long as that unit exists.

I'm guessing this was changed? Because effects on me or other players (in EFFECT_CHANGED) do not give a unitId of 0.

Any chance we could get something to help us determine when targets, unitId's, no longer exist? An event of some kind that fires when unitId's are destroyed perhaps. That way we know when to clear any data related to that target. Or at least a function to determine if a unitId still exists (both would be great), like:

Lua Code:

EVENT_UNITID_DESTROYED
DoesUnitIdExist(unitId)

Also a function to differentiate between different unit types (player, monsters, pets, other players, exc..) using unitId would be very helpful.

Lua Code:

GetUnitIdType(unitId)

For example right now the event EFFECT_CHANGED passes us:

Lua Code:

function OnEffectChanged(eventCode, changeType, effectSlot, effectName, unitTag, beginTime, endTime, stackCount, iconName, buffType, effectType, abilityType, statusEffectType, unitName, unitId, abilityId)

The unitId does help us differentiate between different units, but we have no idea what those units are. For example when a target/mob dies or is not currently targeted the unitTag field is nil so we can't use GetUnitType(unitTag) so we have no way of knowing if the effect was on a mob, pet, or another player.

Quote:

Originally Posted by ZOS_ChipHilseberg (Post 24168)

I don't think it'll be a problem to add most of these. I'll throw it on the backlog.

Hi @ZOS_ChipHilseberg,

I wanted to request adding a MsgEffectResult (changeType) event filter for EVENT_EFFECT_CHANGED. Use case would be, registering the unfiltered event only for EFFECT_RESULT_GAINED.

This way a database of gained abilityIds can be kept by an addon like Srendarr, and each could be registered for EVENT_EFFECT_CHANGED in its own namespace by abilityId and unregistered when the effect ends.

This should significantly improve performance, as you are only then open-listening for EFFECT_RESULT_GAINED events in EVENT_EFFECT_CHANGED (which is a heavy event), along with a pre-filtered list of specific abilityIds.

Quote:

Originally Posted by Phinix (Post 43853)

Hi @ZOS_ChipHilseberg,

Best not to necro a thread, he is not longer the developer.

@Phinix
Better use the WishList addon for this request, that's what Sharlikran meant. Or maybe ask ZOs DanBatson within Gitter.im/esoui/esoui. He is the actual responsible communication person for us

Thank you Baertram, I made that at almost midnight my time while I was working on something and forgot to post where. Then when I woke up I thought there was a forum for that wasn't there? The WishList, I was too tired and lazy to go hunt it down.