Quiver Haste Problem

[Gringo]

All parses were run with all aa's except trickshot, with a fleeting quiver and using 4 bows: Chitin-Joint Bow(CJB=25 delay), Bow of the Destroyer(BotD=17 delay), Shadow Agent Death Bow(SADB=36 delay) and Windstriker(WS=60 delay). All parses are a minimum of one hour. I had a very steady /autofire delay with CJB, BotD and SADB just under 0.200 seconds. For some reason, the delay on Windstriker parses varied a lot between parses from 0.03-0.18 seconds and the results are much less accurate.


(I created this spreadsheet in open office, then realized I couldn't post it, so I lost some formatting when switching over to google to display.)

The problems:
(1) Fleeting Quiver haste seems to have no effect below a hastened delay around 1.175(before hundred hands effect). Quiver haste took effect at 1.179 and above, but not 1.172 and below.

(2) In many cases, having more haste/overhaste is detrimental to archery dps. After parsing CJB at 216% haste with fleeting quiver, I clicked off my overhaste and parsed at 200% haste. My delay dropped almost a tenth of a second(sped up with less haste).

I did more archery dps with 0% overhaste than with 25% overhaste. If quiver haste took effect at 225% haste, archery dps at 225% haste should be about 12.5% higher than at 200% haste, instead it is 4.5% lower.

I've never seen conclusive parses showing how quiver haste works; it seems 1/3 of the weight reduction(20% in this case) as additive haste seems widely accepted. After running all these parses, it appears to act as a multiplicative 15% reduction on weapon delay(or multiplies haste total by 1.175), rather than 20% additive haste.

With the exception of the Windstriker parses(which I couldn't get consistent parse results for), all calculated quiver haste delays fit within 0.01 seconds of their actual value. If I run the calcs assuming instead 20% additive haste, the calculated delays are off by more than 0.1 seconds.

If anyone else could confirm this: a dps parse run with Deathwind or CJB at 214%-225% haste should be noticably lower than a dps parse with same bow at haste of 200%-211%.

[Delbaeth]

I have seen reversals in shot pace vs. bow delay. In particular I measured a 24 delay bow against a 27 delay bow each with a Fleeting Quiver and max overhaste. The 27 delay bow delivered more shots. Without the overhaste the 24 delay bow was faster. I did a series of tests with varied haste from spells, gear and quiver along with different bow delays. The results were mostly as expected save a few particular reversals at low delay and high haste. With long delay bows all tests came out reasonable with more haste or a faster bow always being a benefit.

My conclusion is autofire at low delay is buggy and contrary. I doubt any programmers at SOE will investigate this mess so my proposal is for the designers to make bows hit a lot harder and fire proportionately slower. Assume a 13dmg arrow like all rangers use, balance the ratio of (bow damage + arrow damage) / bow delay for the bow's intended power while making bow delay a lot longer. Let delays run from 40 to 60. Yes, I don't care about head shot. There can be a fast one now and then if you want to head shot but let the good bows be slow and hard hitting so our Sureshot runs work as expected.

[Gringo]

I realize the spreadsheet I posted lost its formatting, and I apparently couldn't show 4 decimal places on google docs, but the delay was very constant within a few thousandths of a second with all bows but Windstriker. I saw very predictable results, and I feel pretty confident it is coded rather than buggy.

For the parses where the hastened delay was below the proposed threshold, the delay with and without quiver gave the same effective delay within a thousandth of a second.

On the other hand in parses between 216% haste and 211% haste with fleeting quiver, the 211% haste parse gave a delay 0.15 seconds faster per shot, when it should have been slower by about .03 seconds per shot.

When I'm consistently getting parses within a few thousandths of a second of the expected delay and suddenly I have a 0.1-0.2 second discrepancy that is duplicated in all similar situations, it seems more than just coincidence. Furthermore, all of these 0.1-0.2 second discrepancies can be accounted for within a thousandth of a second by calculating quiver delay as a 15% weapon delay reduction.

[Schadenfreude]

My conclusion is autofire at low delay is buggy and contrary. I doubt any programmers at SOE will investigate this mess...

Hopefully the artificial delay added to /autofire years ago is fairly obvious from a code perspective and we can perhaps think about lobbying to get it removed. I'm sure if it's possible Sklug can fix it as he's done minor miracles in the past.

[Gringo]

Hopefully the artificial delay added to /autofire years ago is fairly obvious from a code perspective and we can perhaps think about lobbying to get it removed. I'm sure if it's possible Sklug can fix it as he's done minor miracles in the past.

The artificial delay for Chitin-Joint Bow, Bow of the Destroyer and Shadow Agent Death bow was constantly a few thousandths of a second less than 0.2 seconds(0.197-0.199). The variance can be attributed to the fact that I only ran each parse a minimum of an hour, which I am comfortable with.

I'm not a tech guy, but its my understanding that the artificial delay should not vary from person to person.

I added a parse with BoTD at 143% haste. With 145% haste the hastened delay=1.172; at 143% haste the hastened delay=1.189. This shows quiver haste triggering at 143% haste but not at 145% haste. By adding this 2% haste, BotD fires about 0.16 seconds slower per shot...

I simplified the table a little bit to display my point better. There is a column showing calculated delay without quiver haste, and a column showing calculated delay with quiver haste. In every case where the hastened delay is above 1.18 seconds, the calculated delay with quiver haste matches the effective delay; with hastened delays below 1.18 seconds the calculated delay without quiver haste matches the effective delay. Before you try to debunk it, or write it off as random bugginess look at the numbers.

[Delbaeth]

Before you try to debunk it, or write it off as random bugginess look at the numbers.

I would be happy to look at the numbers but I can't see them. The spreadsheet link leads to a log in from Google. That turned me away the first time as I am thoroughly fatigued with all the blasted log ins I have. But, what the hell, actual testing results for archery could be interesting so I dealt with their stupid log in. Now it says I don't have permission to view the document.

So, no numbers for me.

Still, I think it is fair to call reversals bugginess. Understanding exactly how they work may mean they aren't "random bugginess" but still I think bugginess.

[Gringo]

75 views of this thread before anyone spoke up! Sorry, first time using google docs, but it should be viewable now and you shouldn't need to sign in. Let me know if there is still a problem with it. Thanks Delbaeth.

[Efton]

As I understand it, quiver haste doesn't work like other hastes, it's not applied as a percentage. Take the weight-reduction specified on the quiver (60 for fleeting), divide by 10 and then subtract that from the bow delay. So a fleeting quiver reduces the delay on any bow by 6. Note that, unlike a percentage mod (normal haste), quiver haste will have more impact on faster bows. Imagine two theoretical bows, one with a delay of 7 and one with a delay of 700. Subtracting 6 ticks from each affects the first bow drastically, but the second bow hardly at all.

[Gringo]

I've seen a lot of different explanations on how quiver haste works, but never have seen any parses backing it up. 1/3 of the weight reduction as additive haste, 1/2 of the weight reduction as multiplicative weapon delay reduction, etc. As 15% delay reduction the calculated delays come within a couple thousandths of the parsed delays.

If I use a -6 delay reduction, some calculated delays would be off by up to 0.2-0.3 seconds. Bow of the Destroyer at 143% haste would be (17-6)/14.3 +0.199=0.9682. Calculating as a 15% delay reduction gives (17*0.85)/14.3+0.199=1.2095. The 10-hour parse I ran on this showed a delay of 1.2087. 0.199 is the artificial delay I found in parsing BotD at 0% haste.

Any way it's calculated is fairly close, but the 15% reduction has been within a few thousandths of a second every time.

The real issue is the fact in many cases that having more haste is detrimental to archery dps. Either quiver haste needs to be reworked or all bows need to have a delay of 27 or higher.

[Astroshak]

1/3 Weight Reduction was, as I recall, the figure given when they made quivers give "quiver haste".

How accurate it is, I've never seen tested. But that is the "legacy knowledge" that people (who have been around long enough) should remember.

[Delbaeth]

Well, thanks, it makes sense now, typical Sony math.

The quiver works a bit like spell haste. If the effective bow speed is fast enough the quiver simply isn't counted. The quiver haste effect is strong enough this creates reversals where a bow just past the cutoff is slower.

It is like a 2.5 second spell for which haste doesn't count making it slower than a 3.0 second spell. It looks like I want overhaste off when doing a Sureshot run. Of course that means no stacking Guardian of the Forest with it like I often do. It also means losing time getting overhaste back after I'm done shooting. Realistically I may not be able to get any advantage out of knowing this. Are you confident of that 1.18 number? Is it the cutoff or does it need verification?

Well, I guess I can lose the quiver as my 25 delay bow with 216% haste is past the cutoff. I will probably suffer through /resetaa and verify it all for myself before doing that. Bleh.

My request for harder hitting slower bows stands. They would work as expected.

Thanks for sharing these results.

[Gringo]

The cutoff number for hastened delay lies somewhere between 1.172 and 1.179; I haven't been able to narrow it down from there yet.

Edited the range after more parsing.

[Sarkaukar]

1. SOE had input a formula for weapons to ensure they get approx the number of swing attempts due to server ticks but only after lots of proof provided by players.

2. Besides using autofire in game, have you tested it with a hotkey/macro to press the range attack to eliminate the artificial delay?

[Delbaeth]

The cutoff number for hastened delay lies somewhere between 1.172 and 1.179; I haven't been able to narrow it down from there yet.

Edited the range after more parsing.

How about 1.1764?

Assume quiver haste really is multiply delay by exactly 0.85. Sony loves even percentages. 60 weight reduction / 4
If delay after quiver haste would be less than 1 then reject quiver haste and don't apply it at all.
Resulting boundary is 1/0.85.

[Gringo]

2. Besides using autofire in game, have you tested it with a hotkey/macro to press the range attack to eliminate the artificial delay?

I only ran a handful of parses with gamepad autofire. It is my understanding that repeatedly pressing the range attack button does away with the artificial delay from the /autofire command, but still has lag between client and server. Please correct me if I'm wrong, I don't know the technical mechanics so well. I ran the same parse twice to get an idea of this. The resulting delay varied by 0.03 seconds between the two identical parses, and was 0.11 to 0.14 seconds above the expected delay. Using /autofire gave a steady artificial delay of 0.197-0.199. I didn't run more gamepad autofire parses because I didn't think I would get consistent results that I could do anything with.

1.1764 would be very reasonable Del. It's difficult to narrow it down much further than I have already without /testcopying again with a larger assortment of worn hastes, overhastes and farming a Windsaber(the only 22 delay bow in game). I'm currently running 23 & 24 delay bows above and below the cutoff just to solidify the fact there is a cutoff.

I pm'ed Ngreth about this and he said he'd look into it but not immediately.