Do powers recharge during their own arcanatimes?

If I use, to choose a power at random, Gambler's Cut (0.67 activation, 0.924 arcanatime), when does it start recharging? 0.67s after activation? 0.924s? 0.792s (after the roundup but before the +1 clockInterval)?

Put another way, if I want to run an attack chain with a single Gambler's Cut with no +rech (3s recharge), how long does my chain need to be to avoid a pause? 3.67s, 3.924s, or somewhere in between?

If recharge started its timer at the end of the listed cast time instead of at the end of arcanatime, then we wouldn't need arcanatime to figure out how much recharge we need in a specific power for a pauseless chain.

So... I'm betting recharge starts at the end of the arcanatime.

EDIT: Wait one....

Arcanaville states here: http://boards.cityofheroes.com/showthread.php?p=3244522

Heh, just saw that - Arcana herself preempted my question by a good 20 minutes. Not sure what you mean about not needing Arcanatime in this case - you'll still need to apply it to your other attacks in the chain, to figure out your target recharge.

What could be happening is that the time is recorded as actual time, but only checked as Arcanatime. So by the time the check happens for the recharge time to begin, a fraction of the cycle time has elapsed. But if the actual time of the activation is recorded, then the code know that cast time has ended, and the fraction of the time in the past that it expired.

It may STILL be a factor of Arcanatime when the power recharges, though, because it may still need to poll to find that out. But it rounds off the cast time plus the recharge time to Arcanatime, not the cast time to Arcanatime, and THEN the recharge time to Arcanatime again.

I expect 90% of the time the result would be the same. But it might offset the recharge by a cycle in some cases.

Slash, Swipe, Brawl, Strike, Swipe, Repeat

Real Cast: 1.33, .83, .83, 1.17, .83
Arcanatime: 1.584, 1.056, 1.056, 1.32, 1.056
Recharge: 4.8, 1.7, 2, 3.2, 1.7

For this chain to be pauseless, under the old understanding that recharge starts after a-time ends:
Slash needs to recharge in 4.488 seconds with 6.95% rec-red.
Swipe needs to recharge in 1.584 seconds with 7.32% rec-red.

Strike and brawl need 0% extra rec-red for this chain.

One item that messes this test up a bit is that since Slash is no recharged by the time the second swipe finishes, it adds time for swipe to recharge. However, it's easy to test around this by testing nothing but swipe, slash, swipe.

Here are the findings:

I always get the pause I expect before Slash can fire off after the initial chain.

Testing Swipe, Slash, Swipe always produces a pause on the second swipe.

After placing a lvl 5 To (8.7% rec-red) in Slash, thus covering the 6.95% needed, I now only have a pause before the first Swipe of the second chain as expected.

The problem at this point is that if I place the other lvl 5 To rec-red in swipe, sure, all my pauses will be gone, but it doesn't tell us anything of worth because the value of the TO is too high.

So I left the RWZ base's practice dummies and went back to Atlas Park to hit level 5.

But I went ahead and stuck the lvl 5 rec-red To in Swipe. I should not be hearing the not-ready sound anymore on the swipe after slash, but I am. Consistently. Doublechecking math: With 8.7% rec-red in swipe, it recharges in 1.5639 seconds. It *should* be recharged fully before Slash finishes its cast time unless somehow arcanatime is being ignored completely when dealing with recharge or maybe slash's root time is longer than its cast time and it's keep swipe from firing off even though it's ready to do so?

Now trained up to level 6. The lvl 5 TOs are worth 7.5% rec-red. I'm back at the RWZ test dummies. I only get a pause when attempting to fire off the first swipe of the chain after the initial chain.

If the recharge start time is occuring after cast time and is ignoring arcanatime, then the following is true:

Slash needs 1.223% rec-red in order for it to fire off without a pause.

Swipe needs... well, it doesn't need any at all. 1.056-.83 = .226 1.584+.226 = 1.81 which is greater than the base recharge of swipe. However, we know this is not true. I currently have 7.5% rec-red in swipe, reducing its cast time to 1.5814

Let's completely ignore arcantime for a second...

For swipe to recharge in 1.33 seconds (slash's stated cast time) it would need 27.82% rec-red to work.
Slash would need for the chain listed above, 31.15% rec-red would be needed. But we know that 7.5% rec-red currently slotted is enough.

So why is arcanatime apparently correct for calculating the recharge needed for Slash, but isn't correct for calculating the necessary amount needed for Swipe? I then stuck another lvl 5 rec-red TO in swipe. I know have 15% rec-red in swipe. 9 of 17 attacks with swipe set off the Not Ready sound while using the chain above. Just around half of them. So 15% must be VERY close to the amount of recharge I need in swipe for the swipe/slash/swipe chain to work.

Ok, what does 15% rec-red drop Swipe's 1.7 recharge to? 1.4783 seconds. How is this number relevant?
We have a stated cast time of 1.33 for slash.
We have the arcanatime of slash at 1.584.
Now we have a recharge time of swipe at 1.4783 that seems to be on the money.

I have no idea what it means.

Bah, my old thread with a title like "Are we calculating required recharge time correctly?" appears to have been eaten. We discussed a lot of these issues, did some testing, and concluded... maybe, maybe not.

Now, at the time, I think I knew what I was talking about, but it's long since been purged from my cache so now I'm officially stupid and everything I say is suspect. But I believe I'd listed out a lot of possibilities for when recharge began and when it ended. Some people tested some of the cases. It was inconclusive. We saw some anomalies, but for the most part, things matched our "normal" understanding - start recharging after the Arcanatime delay has elapsed, not immediately after the cast time. But recharge only needs to be complete by the instant you need the power.

One of the possibilities in the matrix should have been this: recharge begins immediately on expiration of the cast time, BUT needs to be complete by the end of the cast time of the final other attack. If that were the case, the required recharge would have a small "random" variation around our normal calculations, leading to occasional anomalies during testing.

I THINK we did the earlier testing by looking for how much a power like Follow Up or Blinding Feint stacked, rather than listening for the recharging noise (which seems a little unreliable to me, such as in the 9 of 17 tests got the recharging noise - shouldn't it be all or nothing?). However, seems like the stacking itself opens up additional questions, since you can ask a separate question about exactly when the buff begins and ends. However, I THINK that's a known, so wouldn't be an issue in practice (?).

Arcanaville might have a better testing procedure, but if I were testing this, I suspect what I'd do is again make a matrix of the possibilities we've thought of. Does recharge START immediately on expiration of the cast time? At the next tick? One tick after that? Something else since there's really two server ticks? Then the same question for when recharge must be complete. You get a matrix of possibilities. Then it's a matter of testing and eliminating possibilities until only one remains.

On the other hand, it seems like what Jade Dragon proposed wouldn't even be in a simple matrix like this, so maybe I'm off base.

Anyway, it won't surprise me in the least if the way we currently do our recharge calculations is wrong. But the real answer will be CLOSE, because MOST of the time, everything behaves as expected.

Me, I'm lazy, and I will wait for the answer unless I get a command from on high to do some particular test.

Huh, I had no idea I was opening such a can of worms.

Quote:

Originally Posted by Bill Z Bubba Slash, Swipe, Brawl, Strike, Swipe, Repeat We have a stated cast time of 1.33 for slash. We have the arcanatime of slash at 1.584. Now we have a recharge time of swipe at 1.4783 that seems to be on the money. I have no idea what it means.

So swipe is actually taking longer than the listed value to recharge? Interesting.

Suppose that powers take an extra server tick to register as recharged, just like players take an extra tick to register as unrooted. This would effectively add about 0.132s to the recharge of every power - this seems unlikely to me to have escaped the notice of the DPS gurus around here for so long, but I'm not one of them so I wouldn't know. So your Swipe would have a recharge of 1.6103s, or only about 0.0263s longer than the Arcanatime of Slash.

From the original Arcanatime post:

Quote:

Originally Posted by Arcanaville The theory matches measurement usually to within 30ms, and often to within 20ms (less than one visual frame of animation). That's pretty good: I'm currently examining the question of whether there is another source of systematic error that can account for even *that* discrepancy, or if its simply an artifact of averaging dozens instead of thousands of attack chains to average out the jitter intrinsic to all of these measurements (when the server decides to do something every 132ms, that doesn't mean *everything* will be done instantly: it could happen anywhere within that 132ms window, which causes "jitter" in the measurements that can be partially averaged out).

So, the cause could be that for whatever reason, Slash sometimes takes an extra 30ms or so to activate, which would be enough to stretch it out to longer than the (adjusted) recharge of Swipe. In these cases, Swipe fires normally, otherwise you get the "recharging..." notification. I guess the way to test for this would be to take various powers and enhance them until their recharge times are very close to multiples of .132, then bookend them around powers of the appropriate length and see what happens.

Another possibility I entertained was that recharge times got rounded up to the nearest clockInterval just like activation times do (meaning Swipe would recharge in 1.584s), but this strikes me as unlikely, as it would cause recharge times and Arcanatimes to coincide very frequently, and the sometimes-recharged-sometimes-not effect wouldn't be so unusual.

So, I did a bunch of preliminary tests with unslotted Claws. Interesting:

Spin
Cast: 2.5s
Recharge: 9.2s
Unadjusted cycle time: 11.7s
ArcanaTime projected cycle time: 11.84s
Measured cycle time: 11.958s

Strike
Cast: 1.17s
Recharge: 3.2s
Unadjusted cycle time: 4.37s
ArcanaTime projected cycle time: 4.52s
Measured cycle time: 4.612s

Slash
Cast: 1.33s
Recharge: 4.8s
Unadjusted cycle time: 6.13s
ArcanaTime projected cycle time: 6.38s
Measured cycle time: 6.374s


Interestingly, a pattern is already emerging. Measured cycle time is consistently 0.24 - 0.25s longer than the calculated unadjusted cycle time. It is *not* following ArcanaTime; in particular notice that Slash has the highest variance between cast time and arcanatime (0.254 seconds) and ends up having the arcanatime projection almost equaling the measured cycle time, while the other two powers' arcanatime projections lag by 0.12 and 0.09 seconds respectively. The fact that measured cycle time is a consistent offset from unadjusted cycle time but not from arcanatime suggests that the powers are in fact recharging starting immediately from the expiration of cast time, but some other factor is involved which offsets when the power becomes available. The 0.24-0.25 seconds may in fact be a leading and tailgate 0.125 combat clock effect, but I'll need to do much more complex tests to get a better handle on that offset.

As of right now, the limited testing I've done suggests that a power will become available for use 0.25 seconds after its recharge completes, assuming recharge begins the moment cast time expires. I'll post another update when I've completed the next round of tests.

What I wanna know is if Arcanatime travel is possible?

Update: I fell asleep last night.


More relevant update: I collected a very long run of data which I'll analyze tonight related to whether or not the recharge system is "aligned" to the combat action clock (0.125). If it is, I should see a signature drift pattern in the recharge times. If not, its probably operating under the higher precision 1/30th server clock, in which case there has to be some other mechanism causing the 0.25s recharge delay. I'll post the results here when I get that done, although that might be very late tonight (tomorrow, for most people).

You can sleep when you're dead!

/cracks whip

In all seriousness, thanks, A. Hope the data points to something conclusive.

Before I fall asleep on my keyboard again and put little square indents in my face and everywhere else, an update. I analyzed my eight hour Spin run (which was supposed to be a bit shorter than that, but eh) and evidence suggests whatever is happening, its an actual lag of some kind after recharge completes. Not sure what it is yet, but if it was just aligning with the system clock, I would see the cycle time of Spin oscillate back and forth about a metronome-like centerline. The AI decision behavior exhibits this. Instead, I see more of a random walk.

So, its like the "rule" whatever it is will end up being something like "recharge is calculated like X, plus an additional buffer Y tacked onto the end." So it might very well be something like "just tack on 0.25s and you're good to go." Except its not quite that, because the offsets themselves are not always exactly 0.25s, and my measurements are accurate enough that the variations can't be within the margin of error. So its probably something else in the mechanics that is slightly variable. A similar thing happened for ArcanaTime, which led to the "divide by 0.132 and round UP, then add one and multiply back by 0.132." The "round up" was due to the power roots needing to align with both the animation clock and the combat clock and it meant every power had a different offset based on its rooted time. A similar thing might be happening to recharge, but it seems to be more subtle (since the values seem to be bouncing around 0.24 to 0.26 for the limited measurements I've made so far).

Gotta think up my next experiment. But for now, I believe that a reasonable rule of thumb is: if you want to be absolutely sure you have enough recharge, presume that the amount of time it takes for a power to recharge is its calculated recharge, assuming recharge begins at the end of the defined cast time (not Arcanatime), plus 0.26 seconds. It may take a little less time than that, but probably no more. If I find a power that has a longer offset than 0.26, I'll let you all know. I'll probably be looking at slotted recharge next, to see if the tailgate time changes under sped up recharge timers.

Probably already accounted for, but you are including latency and server combat clock ticks in your analysis right?

For example, if you start your timer based on when you press the button for an action it then goes to the server (probably 0.150 seconds on average depending on location) then the server receives this packet, and must wait until the beginning of one combat tick in order to begin processing the animation (up to another 0.132 seconds) assuming there is less then a one tick lag between receive and action, otherwise add ticks as appropriate.

Server load may also increase this time though I'd expect that these tests are performed under as ideal of circumstances as possible (instanced map cleared of enemies with lowest graphics settings) to remove any possible sources of variability.

Ok, A, lemme see if I have a handle on this.

To calculate necessary recharge values for a given attack chain, here are the new steps:

Get all cast times and base recharge times
Calculate arcanatime for each cast time
Select power you wish to determine rec-red amount needed
Add up arcanatimes of all the intervening attacks
Add to that the difference between the attack's cast and arcanatime
Add another .26 seconds

Subtract that total from the base recharge value of the attack and then divide the remainder by that same total. You now have the amount of total recharge needed.

Example using scrapper claws:
Followup: Cast- .83 Atime- 1.056 Recharge- 12
Focus: Cast- 1.17 Atime- 1.32 Recharge- 6.4
Slash: Cast- 1.33 Atime- 1.584 Recharge- 4.8
Strike: Cast- 1.17 Atime- 1.32 Recharge- 3.2
Swipe: Cast- .83 Atime- 1.056 Recharge- 1.7

First, we look at fu, slash, focus and calculate for FU's necessary recharge:
2.904 is the amount of atime between FUs.
.226 is the difference between cast and atime
.26 is the odd chunk
3.39 is the total
(12-3.39)/3.39 = 254% recharge in followup should work.

This result is not backed up by in game testing.
I'll assume that I'm doing it wrong. Perhaps I should only be dividing by the original atimes+the difference between the cast and atime?
(12-3.39)/3.13 = 2.75 or 275% recharge needed in FU for that chain. Again, I've been at 275% recharge and there's a solid delay before followup can fire again.

Either I'm completely missing something simple here or something is very wrong with the idea of recharge starting at the end of the cast time and the .26 addon.

EDIT: Wait one... think I see where I'm screwing up. The .26 needs be be subtracted...
2.904+.226-.26 = 2.87 seconds between followups
(12-2.87)/2.87 = 3.18 or 318% recharge needed in followup.... ok, I could see that variance occurring but won't be able to test that specific chain until I-19.

Let's go with what I tested eariler: swipe, slash, swipe
1.584 atime seconds between swipes
.226 between cast and atime
-.26 addon
(1.7-1.55)/1.55 = .097 or 9.7% recharge needed.... still not right as it was determined that 15% recharge got swipe to the point where half of the time the not ready sound went off.

The duration of the recharge doesn't change, just the available time for the recharge.

So the formula should be
(Recharge Time) / ((Arcanatime - Cast Time) - Noise + Time Till Next Activation)
for the required recharge.

If the noise causes the recharge to begin after the activation time, then you have less time available and so need more recharge than expected.

So for your Follow Up example:
12s / ((1.056s - 0.83s) - 0.26s + (1.584s + 1.32s)) = 418%

Arcanaville, do you have all your tests on perhaps a Google docs spreadsheet that is readable by others?

I'd like to see what data you generated via your tests if possible.

EDIT: Or rather what is the variance of values for your measured cycle duration for each power? That would be far more useful and something you probably already have.