Stalker's Guile proc stacks and delays hide


Edana

 

Posted

This is an issue I and others have experienced so I thought I'd post it here officially. There's also a discussion on the stalker forums here.

Arbiter Hawk has stated that the new ATO procs use BASE recharge to determine how often it triggers. 4 procs-per-minute means that a power with a base 15 second recharge should trigger the proc 100% of the time (60 seconds/4 = 15 seconds). This is regardless of ACTUAL recharge time due to enhancements or global boosts. A power that fits this bill exactly is Assassin's Strike, and indeed when slotted with the Stalker's Guile chance-to-hide enhancement, it will trigger EVERY time you use the power.

The proc will grant you a temp status called "Stalker's Guile" that puts you into hide and lasts 10 seconds.

Here's the problem...

If you have high recharge you can (and likely will) use Assassin's Strike again before that 10 seconds has expired, meaning Stalker's Guile will actually stack and not simply refresh. This means that the second proc will not take effect until the first one has expired.

On my own stalker, Assassin's Strike has an enhanced recharge of 7 seconds. The first time I use it in a chain I immediately drop into hide no problem, but when the power refreshes and I use it again, I won't go into hide again until 3 seconds AFTER the power has been used (10sec - 7sec = 3).

Three seconds is a long time in an attack chain, and when hide finally DOES drop in, it will happen at unpredictable and often inconvenient times. The most annoying example is when you are well into a chain and it occurs just as you're about to use Assassin's Strike, meaning you will suddenly find yourself performing the long interruptible version instead of the new instant one.

On the discussion mentioned above, Granite Agent suggested reducing the duration of Stalker's Guile from 10 seconds to 5 and I agree. It's an easy fix and would likely eliminate the problem.


The Grim Saint - Virtueverse [1323 Badges]

 

Posted

Let me see if i understand this issue...since i am not having any issues.....

...you slotted the proc into assassin strike and cannot exploit the system by staying hidden while you spam assassin strikes over and over becasue it wont let you stay hidden after your second attack in a row.

does that about sum up the issue?


 

Posted

No, he's saying that the power granting you hide has a 10s duration and stays active even after you break hide. This prevents the proc from putting you into hide less than 10s after it last fired regardless of how much of that time was actually spent hidden. If it was merely a case of the proc not firing inside that period it would be one thing, waiting for the previous instance to expire and then applying the hide state several seconds late doesn't sound like intentional functionality.


 

Posted

Quote:
Originally Posted by PsychicKitty View Post
Let me see if i understand this issue...since i am not having any issues.....

...you slotted the proc into assassin strike and cannot exploit the system by staying hidden while you spam assassin strikes over and over becasue it wont let you stay hidden after your second attack in a row.

does that about sum up the issue?
No. He said what the functional effect of the issue was pretty clearly, I thought. The effect reapplies but in unexpected and undesirable ways. The additional stack causes you to rehide some time later after the first one expires.

What should happen: AS, hide, attack with crit+unhide, stuff, AS, hide, repeat.

What happens: AS, hide, attack with crit + unhide, stuff, AS, delay that depends on the last time you AS'd where you don't hide, seemingly random hide at a later time.

Edit: What you are probably seeing:

Code:
 AS, |-Proc-Suppression--|,
    |----Other-Attacks---|, AS, |-Proc-Suppression--|,
                                |----Other-Attacks---|, repeat 
    HIDE                        HIDE
What we are describing:

Code:
 AS, |-Proc-Suppression--|,
    |-Attacks-|, AS, |-Proc-Suppression--|,
                     |-Attacks-|, AS, |-Proc-Suppression--|
                                      |-Attacks-|, AS, |-Proc-Suppression--|,
                                                       |-Attacks-|
      HIDE               HIDE             HIDE             HIDE
See how in the second flow the HIDE events are not happening after the AS, but are happening in the middle of other attacks?

The forum editor stinks for letting us lay out text, but what is happening is that when you can attack fast enough to overlap the suppression, your hide starts happening at the end of the prior suppression, which is well after the AS. It should simply not hide you at all, not hide you at a time later that usually feels (but isn't actually) random.


Blue
American Steele: 50 BS/Inv
Nightfall: 50 DDD
Sable Slayer: 50 DM/Rgn
Fortune's Shadow: 50 Dark/Psi
WinterStrike: 47 Ice/Dev
Quantum Well: 43 Inv/EM
Twilit Destiny: 43 MA/DA
Red
Shadowslip: 50 DDC
Final Rest: 50 MA/Rgn
Abyssal Frost: 50 Ice/Dark
Golden Ember: 50 SM/FA

 

Posted

Exactly. It would be one thing if the hide proc simply didn't trigger if used again within a certain window. The problem is that it DOES, but due to the overlap of Stalker's Guile it can and will drop in a seemingly unpredictable way.

I think the devs can either reduce the duration of Stalker's Guile to protect against overlap, or change the mechanics of ppm to apply to enhanced recharge instead of base recharge.

Obviously I am more in favor of the former if only because one ought to be rewarded for successfully using +recharge for maximum gain in their build, and judging by the decision to have ppm apply to base and NOT enhanced recharge, I'd wager the devs agree.


The Grim Saint - Virtueverse [1323 Badges]

 

Posted

It's been fixed interally and we'll probably see it the next patch with all the things that were discussed near the end of beta but didn't make I22's release.

Quote:
Originally Posted by Jibikao View Post
Good news!

Synapse said...

It is now fixed internally. It should now proc only once every 10 seconds and there won't be any second application of the effect. It is also slightly more likely to play nice with offensive toggles.


Getting a critical every time 10s is good IMO. Getting a critical every time a-strike lands sounds too good to me.
The way it currently works Hidden isn't completely unpredictable. When it was being discussed during I22 beta I found it was just over 10 seconds between each Hidden, assuming you get the ATO to proc at least once before the Stalker's Guile buff wears off. The buff reapplies itself after the first wears off and you go into Hidden again on likely the next server tick rather than based on when you attack.


 

Posted

Quote:
Originally Posted by Grim Saint View Post
Obviously I am more in favor of the former if only because one ought to be rewarded for successfully using +recharge for maximum gain in their build, and judging by the decision to have ppm apply to base and NOT enhanced recharge, I'd wager the devs agree.
It's off-topic for the problem, but I'd be careful about assigning that motive to the design. There's a decent chance they based it off of base values to reduce computational cost. Otherwise, it would need to recalculate its chance to proc dynamically. (Even if they tried to account only for slotted +recharge, as opposed to potentially dynamic global buffs and debuffs, enhancements are ultimately just a kind of buff.) That might not sound expensive, but done even a couple of times a second across potentially thousands of players (and potentially across multiple procs per player - regular SBEs like Mako's and Touch of Death use PPM mechanics too), it could end up being a noticeable extra server load.


Blue
American Steele: 50 BS/Inv
Nightfall: 50 DDD
Sable Slayer: 50 DM/Rgn
Fortune's Shadow: 50 Dark/Psi
WinterStrike: 47 Ice/Dev
Quantum Well: 43 Inv/EM
Twilit Destiny: 43 MA/DA
Red
Shadowslip: 50 DDC
Final Rest: 50 MA/Rgn
Abyssal Frost: 50 Ice/Dark
Golden Ember: 50 SM/FA

 

Posted

Quote:
It's been fixed interally and we'll probably see it the next patch with all the things that were discussed near the end of beta but didn't make I22's release.
Excellent! I much prefer the proc either happen or not based on a static timer, instead of a delay which can grief up your chain.

Quote:
It's off-topic for the problem, but I'd be careful about assigning that motive to the design. There's a decent chance they based it off of base values to reduce computational cost. Otherwise, it would need to recalculate its chance to proc dynamically. (Even if they tried to account only for slotted +recharge, as opposed to potentially dynamic global buffs and debuffs, enhancements are ultimately just a kind of buff.) That might not sound expensive, but done even a couple of times a second across potentially thousands of players (and potentially across multiple procs per player - regular SBEs like Mako's and Touch of Death use PPM mechanics too), it could end up being a noticeable extra server load.
That is a good point.


The Grim Saint - Virtueverse [1323 Badges]