Go to Page... |
Thread Tools | Display Modes |
06/18/15, 08:56 AM | #1 |
Upcoming Combat and Effect API Changes
In patch 1.7 we will be testing some changes to the rules that control which combat events and effects (buffs/debuffs) are communicated to addons. These changes are intended to deliver more reliable information about what is happening to the player and their target without changing what addons know about activities between other players. Here are some of the changes:
Before:
After:
Before:
After:
Before:
After:
Our hope is that these changes will give existing combat and effect addons the same information that they were working hard to cobble together before in a more reliable and easy to use format. We are posting them ahead of time to offer a chance for feedback and discussion before the PTS realm goes live. |
|
06/18/15, 09:03 AM | #2 |
Thank you very much.
|
|
06/18/15, 10:51 AM | #3 |
Huge News
Hey Chip,
Thanks a lot for sharing these plans with us ahead of time, I appreciate the advance heads up. I honestly believe this is a step in the right direction and will greatly improve the quality of addons like my own that are trying to re-assemble this information. I'm sure that being able to present this data more efficiently will benefit addon user's gameplay experience. I do have a number of questions about these changes, if you can answer: 1. Integrated Combat and Effect UI Recently during an Xbox One Reddit AUA Chris answered the following question: Tasteh: The lack of Floating Combat Text is hurting this game’s long term potential. I am a player who enjoys optimizing my character. Because floating combat text is missing, it makes it much harder for me to do so. I am left with 2 options: I can choose to rely on the work being done on PC or try to use time to kill tests on some standardized target. Either way this is suboptimal because I must rely on either external sources or relatively rough estimates. One of the things I’ve heard raised against floating combat text is that it would separate the community. I’d like to address this point now. Regardless of what changes are made, the community will remain separate. The PC community has already determined what builds are powerful, and thus acceptable in hardcore endgame groups, and what are not. That knowledge is already available. Therefore, players who choose to make their own builds that are weaker will already be excluded by these players. You can see then that this point is moot. Another point I’ve heard raised to be a negative for some players is that seeing numbers reduces immersion for them. That is a completely fair and valid argument. To negate this, I would propose that this be a toggle. This would result in no changes for more casual players who want to be as immersed as possible and a positive change for players like me who seek to squeeze out every ounce of damage that we can.I assume this relaxation of the API is both an effort to reduce the amount of acrobatics existing addons need to perform as well as support the development of integrated UI tools. Some questions on this front:
2. EVENT_EFFECT_CHANGED I have a few questions and concerns about the new behavior of this event.
3. EVENT_COMBAT_EVENT I have a few questions about this one too.
Thanks a lot for sharing with us Chip, much appreciated. |
|
06/18/15, 12:29 PM | #4 |
This sounds great!
One question about the COMBAT_EVENTS though. Right now there are different ways for how the death of a unit is reported. Currently there are three action results that are related to a unit death.
I want to add killed and assisted messages to sidWarTools, but currently it is not really possible to do it in a reliable way. Ideally there would be three separate action results for a killing blow, when I hit the target and someone else killed it and maybe - unless it is a bug and should be removed - when the target respawns. EDIT: did some more testing and corrected what I wrote about ACTION_RESULT_DIED Last edited by sirinsidiator : 06/18/15 at 01:58 PM. |
|
06/18/15, 01:58 PM | #5 | |||||||||
|
||||||||||
06/18/15, 02:22 PM | #6 | |||||
Hey Chip, thanks for the further detail!
From a user-experience perspective, client side rendered combat text is a vastly superior solution to a simple scroll or cloud window since it visually associates damage with its target. The only downside from an addon development perspective is that we're stuck with whatever information the default UI solution provides. I think it would be super cool if there were API functionality to register data for client-side rendering associated with a specific target, however. An example use case would be an addon to registering a floating experience gain number anchored to the position of recently deceased enemies to indicate how much XP was earned by defeating them (assuming the default solution does not include this anyways).
On a separate, but related note, has there been any ongoing work to evaluate what is causing certain events to be a bit....spammy? For example, when you form a group there seem to be a ton of redundant events that fire. Units are created, then destroyed, then created again in which creates a lot of false triggers. In this case, if you try to set up group frames or use group member data when a new member first joins, it will often fail since in the intervening milliseconds that unit has been destroyed, then re-created. Weapon swapping is another case in which event triggers seem to be a bit hyperactive.
Thanks for continuing this discussion. I look forward to seeing what some other authors have to say. Speaking of which:
I would agree that it would be awesome to have an action result reported (or even separate event) for target death even if the player did not directly generate the killing blow. |
||||||
06/19/15, 07:52 AM | #7 | ||
Lua Code:
|
|||
06/19/15, 08:32 AM | #8 |
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.
|
|
06/19/15, 10:24 AM | #9 | ||
Hey Chip, thanks again for all the discussion, I really appreciate the insight.
Hopefully the 1.7 API documentation can have a list of allowable filters per event, but this sounds promising for both addons and default UI. Do you guys already use these filters, or is this a new logic that will benefit the default UI as well? I have a more "big-picture" question, if you can indulge me. Suppose 10 controls all register for a certain event. When the event-triggering action occurs, does C++ issue 10 parallel calls to the LUA VM, or does it just send the event to LUA which distributes it to the 10 registered controls? It sounds to me like what you are saying is that the C-side filtering would allow us to reduce the number of calls to the VM, so I'm guessing it's parallel threads. Given the amount of filtering that I do in FTC alone I could easily see how this could have a performance impact. I filter out maybe 7/10 events that I am registered for.
|
|||
06/19/15, 12:15 PM | #10 | |
|
||
06/19/15, 12:50 PM | #11 | |
When I look at some players I get flooded with ~40 EVENT_RETICLE_TARGET_PLAYER_CHANGED events. I just need to look around in Belkarth for a bit and get thousands of these. My guess is this happens when there are multiple players standing close to each other. I also get hundreds of EVENT_COMBAT_EVENT when I just stand around inside the city and do nothing. EDIT1: After I open the campaign window for the first time, I also get 2 EVENT_KEEP_RESOURCE_UPDATE for each existing resource per second which makes this the most spammy event so far. EDIT2: This is what I get after I stay near a sieged keep in Cyrodiil and participate in one short fight. ABILITY_COOLDOWN_UPDATED and ACTION_UPDATE_COOLDOWNS are thrown quite a lot for me only fighting for 10 seconds. The rest of the time I was just staying hidden. EDIT3: The previous screenshot has a bug where the detail view does not sort the entries correctly, so here is another one of a fight for a keep. Last edited by sirinsidiator : 06/19/15 at 01:42 PM. |
||
06/22/15, 06:47 AM | #12 |
I was wondering if you could add a method to fire events for testing purposes in the next major update.
More than once did I want to try what happens when a certain event gets thrown, but there is often no easy way to achieve this in a controlled way. Something like Lua Code:
|
|
06/22/15, 09:59 AM | #13 | |
|
||
06/22/15, 10:31 AM | #14 | |
|
||
06/22/15, 10:37 AM | #15 |
|
You can make your own
(pseudo code) Code:
local function DebugFireEvent(events,eventId,...) local func = events[eventId] if func ~= nil then func(...) end end -- Usage local function Event1Fired(eventCode) end -- lookup local _events = { [EVENT_ID_1] = Event1Fired, [EVENT_ID_2] = function(eventCode) end } -- register handlers any way you like with EVENT_MANAGER:RegisterForEvent -- as long as the function address is also in a lookup -- Test fire events DebugFireEvent(_events,EVENT_ID_1,...) DebugFireEvent(_events,EVENT_ID_2,...) |
06/22/15, 11:08 AM | #16 |
This only works for addon event handlers, which is something I already do whenever it is possible.
But there is no way - at least I know of none - to access the ingame event handlers, so in order to test how the GUI reacts to a specific event, I need to find a situation in the game where the event will get triggered and do that over and over again. For example I built a feature into sidWarTools that reacts to EVENT_RESURRECT_REQUEST and also is linked to the behavior of the default UI. In order to test what happens when I get resurrected I had to let myself get killed and have someone revive me over and over. I could add some extra code to call the handler in my addon manually, but it is only one part of the functionality and the handler in the default UI is not exposed, so I can't do the same with that. With a DebugFireEvent function I could simply fire that event and the event manager handles the rest. |
|
06/22/15, 11:40 AM | #17 | |
|
|
|
06/22/15, 03:50 PM | #18 |
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.
|
|
06/22/15, 04:08 PM | #19 | |
|
||
06/23/15, 07:31 AM | #20 |
ESOUI » Developer Discussions » General Authoring Discussion » Upcoming Combat and Effect API Changes |
«
Previous Thread
|
Next Thread
»
|
Display Modes |
Linear Mode |
Switch to Hybrid Mode |
Switch to Threaded Mode |
|
|