AdiButtonAuras

AdiButtonAuras

404k Downloads

Feature Request: Snares & Anti-Snares rule like LongestDebuffOf

IngeniousDox opened this issue ยท 20 comments

commented

In Legion or before, there was a rule at some point, called "LongestDebuffOf". This was removed.

In its place it was the plan to use the data that is now in LibPlayerSpells to make a new rule or mechanic out of it. Could this be made at some point? I'm going to PVP soonish again, and it would be really handy to see the highest duration slow on my target, so I don't have to hamstring.

Since slows are of differing slowing speeds, it would be great to show that also somehow. A 20% slow I might want to improve with my 50% hamstring, but a 70% slow (if that is still ingame), I wouldn't want to overwrite. Since it is never 100% slow (that would be a root), I figure you could have % where normally stacks are, and then duration where the duration is.

Now as to what to show, longest duration slow, or higher slow with shorter duration, that is kinda hard to pick atm, since I don't know what overrides what. Perhaps you folks have more knowledge then me on this.

commented

The biggest issue with this is the data gathering and accounting for anti-snares. If you contribute the data I might take a look into in when time permits.

commented

In LibPlayerSpells, there is already a SNARE category. However this doesn't include reduction % yet. And there are no anti-snares in just yet. Looking at the paladin data, you have crowd control category:

[ 20066] = 'INCAPACITATE', -- Repentance (talent)

While for snare you have:

183218, -- Hand of Hindrance (Retribution)

You could turn that into:

[183218] = '50', -- Hand of Hindrance (Retribution)

To store the snare %. Though, this doesn't cover snares that start high, and then diminish. I should look to see if it changes auras when the slow diminishes. But before that, do you think the % idea is feasible? Or would it make stuff too complicated?

And as for antisnares, we would need an antisnare category, with a way to see what you can cast it on. Blessing of Freedom (Pala), Tiger's Lust (Monk) can be cast on self or others. Avatar (Warrior) would be like a self anti-snare (though you have it as BURST already, don't know if it can be in 2 categories), Escape Artist (Racial) would be self anti-snare. So something like:

[1044] = 'FRIENDLY', -- Blessing of Freedom

As for the data gathering: If you have the rule in place, and part of the data (say warrior) in place how you want it. I can then look at the code, and make PRs for the other abilities from other classes. I was going to update the LongestDebuffOf rule I still have in my own repo, would much rather upstream something so others have benefit from it as well.

Or if you were looking to get a list of snares/anti-snares here in this issue, I could compile a list in a followup post.

commented

Hm, actually we might be able to use GetUnitSpeed and display values below 100% on snares. This would remove the need for extra data. I'll test it this weekend.

commented

@IngeniousDox are you be able to test the snares branch and provide feedback? It will display the percentage speed on enemies with a snare debuff on all your spells that could apply a snare. It is complimentary to normal debuff rules, meaning that if you applied the debuff, the "bad" border and the duration will be shown as well.

It has some limitations though:

  • The count model property is used to display the speed meaning that if the snare is a stacking debuff you apply, either the stacks or the percentage will be displayed based on rules precedence.
  • If the snaring spell has charges, the speed won't be shown, because ABA prioritizes the built-in count/charges display (I don't know if such spells exist in game).
  • If the snare is "upgraded" to a root, stun or some other form of crowd control by a talent or another mechanic, ABA won't catch that and will continue displaying the snares rule. This largely depends on how spells are categorized and is actually a limitation of LibPlayerSpells.
  • The unit's speed must be greater than 1% in order to be displayed. This means that the unit has to be moving for its speed to be determined. This is a limitation of GetUnitSpeed (it returns 0 for units that are standing still).
  • The snare rules are limited to snares applied by class abilities. I can disable the check if the unit is snared but this would mean that the unit's speed will be always shown (while greater than 1%). IMO this could diminish the usefulness of the shown value, but maybe you see this differently.
commented

Looks good. I'll test it out this week on various characters and report back.

I'm curious if unitspeed is best, instead of knowning the actual slow % that is on the target. A target could be mounted, not everyone has the same base speed, a target could have a speed increase, while being hamstringed, etc. I'll see how it will work in practice.

commented

By knowing the unit's speed you can compare it to your own which is what's relevant if you are kiting or chasing your target.

commented

Yeah, but you probably want to plug that into a weakaura. And make it green when you are faster, red when slower. ;)

On my buttons, I probably would prefer to see if there is slow on a target, and what the "strength" of that slow on the target is, without having to calculate in my head what it is, especially if the target has more then 100 speed to begin with (ferals, sprinting rogues, nightelf base speed).

For example: If I can see a 30% slow on the target, I know I can make it 50%. But when I see 50% already, I can't do a thing and I just have to refresh it before it drops.

But I have been using it for 30 minutes now, so I'll keep at it for a bit. Though I do have to say, seeing nothing when it is 0 is annoying. But I guess you could just code it, that if the unit is not moving, it shows 0 anyways.

commented

it simply checks if there is a known snare on the target, and if there is one, it shows the current movement speed

Correct.

instead of using 0, use 5 for standing still

I find this even more confusing :) I'll see into making the default behavior for stacks overridable.

commented

Yeah, true, it might be more confusing. So, having some way of also showing 0 when there is a debuff on them and they are standing still would be awesome.

Anyways, the moment speed is growing on me. It works perfectly when a target has 100 as base. In other cases my mind will slowly start to work out what value is "50% slowed".

One question: The duration of the snare I see on hamstring, is that the duration of my own hamstring? Or is it the duration of the first snare it comes across?

commented

One question: The duration of the snare I see on hamstring, is that the duration of my own hamstring? Or is it the duration of the first snare it comes across?

It's yours.

commented

Precise snare mechanics are possible but will require further categorization of debuffs and special handling in LPS. You also don't want the snare with the longest duration but rather the duration of the most potent one. This limits the usefulness of such a rule to PvP and I think a specialized PvP addon is probably better suited for such a task.

From a mixed PvE/PvP perspective I want to know at a glimpse if the target is faster than me when kiting/chasing it or if a fleeing mob is snared. I have a data broker displaying my own speed, so it is easy to compare the numbers in the first case and calculate in the second (speed-increasing buffs are easy to spot in PvE).

Though I do have to say, seeing nothing when it is 0 is annoying. But I guess you could just code it, that if the unit is not moving, it shows 0 anyways.

ABA's model for conveying information to the player has two textual properties - expiration, which displays the remaining aura duration, and count, which normally displays the number of applications/stacks of an aura. With stacks values of 0 and 1 are irrelevant as they are conveyed by the visibility of the expiration property and/or a highlight and are thus hidden. Because I use the count property for the speed display, the same restrictions apply. Normally it is easy to see if the target is moving or not, so I don't consider this a real reason for change.

commented

Yes, I figured out after I posted what the reason was for it to not show 0. I lack the knowledge of the code, but from what I understand it simply checks if there is a known snare on the target, and if there is one, it shows the current movement speed. This could work, and I'll just have to get used to it.

But.....perhaps instead of using 0, use 5 for standing still. I understand at 0 stacks won't be shown, but the speed % going away completely when a target stands still during an update is weird. Or you would have to add another value, say "model.speed" and show it like stacks, while giving speed precedence over stacks - though I don't think there are stacks anymore on any movement speed debuffs, they simplified most of them, but I'll keep rechecking that the coming weeks while I set up my alts again.

commented

Right, this has grown on me.

The latest addition I just pulled has a duration if you find a snare, that is a really handy addition. I was looking at the code, is it possible to get the longest duration snare there? Now you return true with the first you find. But if you use a local variable for the buff duration, and then iterate over all, updating the duration if there is a snare, then at the end you just update model.count and model.expiration and return true if the duration is bigger then 0.

commented

Yes ofc it is possible to show the longest but given snare mechanics it is just useless info (actually just as the duration of the first snare we find now, but this was meant to cover the case where the target is not moving so you can tell not moving and not having a snare apart)

However I found a really cheap way to display the friggin 0 when the target has a snare but is not moving and I think this is the best way for the common rule. You can always create a better custom rule for yourself if you like. I'll push it in a minute and would like your feedback in it.

commented

No, I really found that expiration really handy, even if it wasn't my slow. Actually especially if it wasn't my slow to begin with. You really want the current speed, and the time left of the slows on the target. Just having the current speed means missing one part of the equation.

In dungeons and pvp, when you need to slow something and keep it slowed, you need to know when the "last" slow is about to drop off, and redo the snare in time. You don't want to waste a GCD on a snare if it isn't needed.

Anyways, I'll start testing the 0.1 for stacks for standing still. I think the combination of the 2 pieces of information would make it better though. Duration of snare left, current speed (even 0) on the right.

commented

My first attempt for my own rule with longest duration + 0 when standing still: IngeniousDox@ddf73f7

Seems to work fine, but will have to test it in multi player scenarios later this week. (Ignore the spaces vs tabs indentation in the commit, was working quickly in Vim, and used spaces like I always do.)

commented

Say the target has a 2 sec remaining 50% snare and 5 sec remaining 20% snare and normal speed of 100%. You will see 5 50 on your button. How would you base you decision on that display?

commented

Well, there are currently 63 snares in LPS which would need to be categorized by slow percentage. For me keeping LPS up-to-date is a major time sink in regard to ABA so I really want to avoid any further additions to this unless somebody else swears on their first-born they are going to update and support it till the end of time. And then again, maybe they hate their children, so I'm not sure about that.

commented

In Arena: I know my partners and know what slows they have, so here it is no issue.
In RBG: It is less important, and I'll see when it becomes 20%, and can hamstring if needed which should set it back to 15 seconds.
In PVE: I don't really care, you usually assign someone to slow. And if I'm hamstringing something I'll see my duration.

Anyways, you are right, neither situation is perfect. So I have to pick one, and I think this would be my choice.

If we want it better, then we are we back to the questions: How hard would it be to add the snare % to LibPlayerSpells and how to use that?

commented

Well, it is missing information, and since you got everything else except snare % info, it feels wrong not to have it. I do understand that it takes time to update stuff, but most spells have had the same snare duration for like forever now, it is just the niche talents sometimes that change in value, and sometimes some changes on AoE talents since they are considered too powerful for example.

Anyways, I can PR stuff I when I find something missing/changed. But you would have to setup the initial change in LibPlayerSpell first, so I know what template to use. And some way to use that in the actually rules. (I never use LUA except for changing something in this addon.)

And I guess ANTI-SNARES need something as well, if you want to display it on that. But I figure that needs to be a different rule, since you don't actually want to see your own speed? Since you know that you are slowed?