Guild Wars 2

So I’m testing overcharged shot with the trait that gives stability on gyro. Both the reactive lenses proc while also consuming the stability stack? Is this a bug?

no, I’d say it’s working within the technical limitations of the engine.
reactive lenses is not only a stunbreak, but also adds fury and grants immunity to blindness (especially the later circumvents stability). I’d be kittened off if stability would block it from proccing.

As for why it also consumes a stability-stack:
Because our PC’s don’t use quantum computing. While processors are incredibly fast nowadays, and therefore giving the impression of computing everything in real-time, between each computing step a fraction of time passes by, therefore forcing the engine that is responsible for setting the order of computing all these skill-interactions (among many many different things) to work in a specific pattern. While some processes can be multi-threaded, it’s inefficient to do so for a single skill interaction, since each processing-thread would need to w8 for all others to compute his sliver of data, which would cause incredible lag.
/tech-talk

what does that mean for this issue?
Stability ALWAYS needs to negate incoming stuns, else animations would be interrupted, giving the impression for players that stability is broken. Therefore, to ensure that stability offers full protection against stuns, in terms of fluent, continued animations, stuns themselves are hardcoded to check for stability on a target first. If stability is present, they don’t play their animation, but subtract one stack of stability instead. Additionally, and this will become important later on, they set a “flag” that a stun recently attempted to disable the player.
Stunbreaker on the other hand work differently. If a stunbreaker is triggered by a player (or automatically from traits) it does not check for anything, but will RESET the player into a playable animation-state, while applying their accompanying effects (boons, heals, whatever…).
You can observe this ingame with a simple test:
- Pick juggernaut, get a couple of stacks of stability, then drop ft and use os while running forward. You will see that the shot goes off, but nothing else happens to your character. He just keeps running.
- Now drop juggernaut and only equip reactive lenses. Run forward again and then use os. You will see that the shot goes off, and your character gets pushed backwards slightly, because this time the stun from OS did not find any stability on you, so it tried to play its animation. However, the reactive lenses trait (checking you several times per second) found that the “recent stun-flag” is raised, so it triggers, activates utility-googles, which then resets your animation into playable state. Still you can observe that you flew backwards a small distance, since there were a couple of milliseconds before the trait could notice that it needs to trigger its effect.

And this is why in your case, where both a stunbreaker trait and stability are present, both fire. First the stability stack gets subtracted by an incoming stun, then your trait finds the “recent-stun-flag” and fires as well.
Any other solution would probably mean that stuns need to check for more things then just stability on their targets. In fact, instead of just checking for stability, costing your processor (and the servers processor) a single cycle, they would need to check for every single stun-triggered-trait, sigil and any other kind of procc in the game, costing both you and the server around n cycles (n== total number of stun-triggered proccs in the game) each time a stun is attempted. While this would go by somewhat unnoticed for a single fight for both players (thanks to modern processor speeds), think about worldbosses, wvw, pvp-raids, and even pvp…
The server-lag would be insufferable, even if it’s just a decently filled pve-map.
Additionally, if stuns were to check of everything, each time a new stun-procc gets added to the game, all other stuns would need to be updated to check for this proc as well, therefore increasing the lag with continued addition of content, and giving more opportunities for bugs. Imagine the outrage if a new stun would ignore a couple of these proccs…

tl/dr:
works as intended. Even if these stability-stack-losses feel like a waste, they are (amongst other sacrifices) necessary for the overall stability of the servers and ease the life of developers, which both enhances our gameplay-experience. Interesting topic, tho.

BS
/15 character

wow that’s along post…

FWIW all of the ‘on CC’ traits work in this same way; they all proc even if you have stability or not. It makes it so the most efficient use it eat the CC and late the game auto-stunbreak it instantly for you. If you are reading the situation and proactively using stability to avoid the CC the trait still gets proc’ed and largely wasted.

Thanks HoT! Playing the game for you since October 2015.

Arantheal.7396:

-snip-

So wouldn’t it make sense to not flag a player as having been stunned recently if the stun detected the player had stability up. In that case, it would remove stability but leave no flag, thus the auto stun break would never be triggered. Seems like a pretty simple solution unless I missed something here.

It’s a design decision.
Sure, leaving this flag out would mean that less stunbreaks get wasted, but not all stun-related procs actually break a stun, and – even with stability up – are beneficial to be triggered.
One engi-related example: protection injection.
Upon being stunned it does not break it, but it gives you protection. The logic behind this is that a smart enemy will usually follow up a stun with burst-dmg, so this trait helps with mitigating it. Now if this flag were to be suppressed by stability , protection injection were not be able to trigger, so a player having stability needs to be aware enough to recognize that his enemy recently tried to stun him, and then waste a dodge to mitigate the follow-up dmg instead of relying on this trait.
In a wvw situation f.e., you don’t want to w8 until your stability is eaten up by a zerg before your protection kicks in, since there is so much dmg flying around simultaneously to the cc barrage, that you want this trait to fire as soon as possible.

Same goes for reactive lenses. While this one actually can break a stun, it also grants fury and an immunity to blind, so you want to keep this procc on cd – if possible – as well.
Any build that allows for permanent / high stability-uptime (f.e. juggernaut + scrapper), would not be able to use the following traits efficiently anymore:
- protection injection
- autodefense bomb dispenser
- reactive lenses (unless you get blinded, which triggers it as well)
None of these are “just” stunbreaks. In fact, 2 of them aren’t even a stunbreak. They all come with additional benefits that you will miss out on if you have a decent stability-uptime, tho.
And this is just Engi. Other classes will suffer from this with similar traits as well, and then there are all the stun-related rune proccs…

Again, it’s a design decision, and the argument that you could have more stunbreaks the other way around is a sound one, too. Still, I personally favor the system as it is now.

I can accept this being a design decision but favoring this is strange. That’s a long way of saying CC steals half your trait and being okay with it. You make a good case for protection injection and autodefense but those actively defend you when they autoproc. A blind field/protection is way more useful when you’re getting CC’d than some fury+might(traited).

>but those actively defend you when they autoproc.
which is also why both don’t actually break your stun. They work as alternative defense mechanism for the cost of leaving you disabled otherwise.
reactive lenses defends you too, by stunbreaking you, and therefore enabling you to react with peak performance to an upcoming spike. So while the first two just follow the principle of a solid defense, reactive lenses deems offense as the best defense. And even if stability on you will waste this stunbreak, the situation is still the same:
Usually when this situation occurs, your enemy did not pay attention to your stability stacks and was committed to burst you. He has wasted this cooldown, and if he clicks faster than he thinks (which many people do – muscle memory a.s.o.), he will partially – or even fully – spend & waste his burst as well. You on the other hand just received fury, (traited) might, immunity to blind, on top of the ability to react, which was not calculated in originally by your opponent. He thought you would be disabled for a brief time. Not only you aren’t, but you are suddenly buffed as well. Your opponent now in turn is forced to either dodge, actively block, or waste other defensive cd’s to deal with your counter-attack, that will certainly hurt (fury + might ) and can’t be mitigated passively (immunity to blind).
So even tho you loose a stability-stack in the process, this trait enables you to interfere with the attack-rhythm of your opponent by amplifying your counter-attack exactly when your opponent tries to carry out his own. And I personally prefer to do so as often as possible, regardless if I’m protected by stability or not.

Ofc this is a matter of taste, but I’m totally fine with the current state of this stability-mechanic.

Still, if I were forced to come up with a solution for this problem, I’d do the following:
Let stun-!breaking! proccs check if the player has stability. If he has, add a stack of stability (n seconds / n= duration of the cd in question) upon proccing. Ofc this would be an additional check, so it will slightly impact the server performance. But who knows, maybe the impact would be neglectable…

Edit:
Then again, there are traits that reward you with additional effects as long as stability is up. So if an enemy can’t burn trough all of your stacks, this solution might grant you unintentional benefits (especially if you don’t have perma-stability naturally), which in turn would generate another cascade of balance-problems.
Eh, now that I think more about this solution, it’s a rather bad one. I really don’t want to see a “fix” for this. I’m happy to work around this issue in its currently implemented form, and just deal with the fact that I might receive the short end from this, from time to time…

You bring up a 1v1 scenario when you previously used a zerg example which is favoring your example. At the end of the scenarios, the opponent still double-dipped by stripping your passive stun-break and stability.

I’m fine with your final solution and allowing the stunbreak to go off before the stability as long I still have stability afterwards. Whether or not it’s an impact on the server is ANET’s job. If they want to make it easier, they can tie it into the trait. Something like:

Reactive lenses: Activates utility goggles when blinded or disabled. Gain stability if you have it.

In a zerg it would be no different.
You want to have your burst ready / supported when the zergs clash together. Especially an immunity to blind becomes extremely handy in this moment.
I thought this was obvious.

But as I said, It’s really just a matter of taste.
Lets just hope that they change it decently, if they change it at all.
I can already taste the spring-tide of salt coming from the wvw forums if A-net somehow breaks stability^^

I would prefer it to not fire when a stability stack is consumed, it has a long icd. just make it fire on either an incoming blind or an incoming nonprevented cc.