I'm also kinda wondering why you would use 3 slots to decrease average delay by 10% when each of those slots has a decent amount of snapshot on it
isnt gearing for rapid shot a bad idea, since you'd be shooting in gear without racc/ratk? or can gearcast actually get the gear changed between pulling weapon and shooting, even with rapid shot?
Gearswap may change the gear fast enough, but I've always noticed it takes the game itself a second to update stats on gear changes.
I think it kinda depends from what I remember of byrths testing rapid shot procs didn't have a set amount of reduction so sometimes it reduced alot sometimes a little
Gearswap is fast enough to change gear if Instant Cast procs. So Rapid Shot is not an issue.
The bullshit about "I don't notice [so and so] happening with gearswap needs to stop. That is the whole point. The chunks are sent, in order, in the same packet. The server makes the calculations for what's suppose to happen and your actions are processed with the appropriate gear without you being able to visually observe it at all. Please stop making these useless comments, please.
Sorry for bumping this, but I'm trying to solidify some info on how ranged stuff works.
1) Delay
Common factor for ranged delay has been (generally) one of delay/103, delay/106, or delay/110. Proth also mentioned a long while back that it might be (delay-120)/60.
Looking at the result data Byrth posted, one in particular stands out: the 999 delay relic gun. With an 8.6 second mode, it would need to be using delay/116 to reach that value.
Overall, I think the simple divisor used that way is not a solid answer; there's just too much messiness and uncertainty involved. So, I took the data from the Mamoolbane, Illapa, and relic test, looked at the slope of the line that passed through their apparent nominal delays, and found a much simpler scaling:
Time per shot = Delay / 120 + 0.4
Now, even that's not exact for the relic; it comes out at 8.725 seconds instead of the observed 8.6016. However, the apparent 50% delay reduction for Rapid Shot is at 4.38 seconds, which would be half of 8.76, not 8.6.
Also interestingly, for the vast majority of ranged weapons, delay/120 gives an exactly neat delay value. 600 delay == 5.0 seconds; 432 = 3.6 seconds; 540 = 4.5 seconds; 582 = 4.85 seconds; 294 = 2.45 seconds; etc. Adding a flat 0.4 to that obviously doesn't change the simplicity of the result.
Is there anything that would seem to run counter to this hypothesis?
2) Rapid Shot/Snapshot
Unfortunately Byrth didn't provide raw data for most of his tests, so I can't do much analysis except for a handful of them.
For the ones he did provide data for, one notable characteristic of the clustered values was that when there were several large spikes within a cluster, the time difference between those spikes was generally 0.034 seconds, or the duration of one frame (ie: ~29.4 frames per second).
As such, multiple large spikes seem safe to consider as a continuous portion of a cluster. It also means that any mode spikes can reasonably be considered up to one frame's delay higher than their 'true' value, given that there's clearly a resolution factor involved.
The next question is how to define the 'time value' of a cluster. It can either be at the leading edge, and assume all of the sample spread was due to an uncertain amount of lag, or it can be at the center of a cluster, with a random +/- distribution.
Given that the time cluster is the difference between two packets (the one indicating that the aiming started, and the one that indicated the aiming completed), and that these packets will independently have their own transit lag distributions, it seems best to use the center of each cluster as the 'true' time value.
I'm going to pick a mode value within each cluster that's closest to the start of the cluster (in the case that there are multiple similarly-valued spikes). Doing that, I pull the following values out of the Illapa data (5/5 Snapshot merits, no other gear modifiers):
Also want to look at difference between each cluster value:Code:1.631 2.040 2.414 2.856 3.264 3.638
Now, the Illapa has a delay of 432. Using my hypothetical delay formula, that works out to (432/120) = 3.6 + 0.4 = 4.0 seconds per shot. Each mode is separated by about 0.4, a 10% increment, for about 40%, 50%, 60%, 70%, 80%, and 90% of the original delay for the respective cluster time valuesCode:Base Diff Delay% 1.631 --- 41% 2.040 0.409 51% 2.414 0.374 60% 2.856 0.442 71% 3.264 0.408 82% 3.638 0.374 91% Avg: 0.4014
I also looked at what percentage of all samples fell within each cluster:
The 40% set is a minor case. 50%, 60% and 70% are at ~10% each. 80% and 90% will take more work to figure out. Not sure why the primary cluster is at 80% with a lesser cluster at 90%.Code:Base Diff Delay% Samples Sample% 1.631 --- 41% 5 1% 2.040 0.409 51% 49 10% 2.414 0.374 60% 48 9% 2.856 0.442 71% 46 9% 3.264 0.408 82% 289 57% 3.638 0.374 91% 74 14% Avg: 0.4014 Total: 511
The same information for the test that added the AF3+2 hat.
This time we again have the primary cluster at 80%, but no cluster at 90%. 50%, 60%, and 70% are still at about 10% each, with another small cluster at 40%.Code:Base Diff Delay% Samples Sample% 1.633 --- 41% 7 3% 1.972 0.339 49% 27 10% 2.414 0.442 60% 29 11% 2.856 0.442 71% 25 9% 3.297 0.441 82% 181 67% Avg: 0.416 Total: 269
The fact that we still get 10% of all samples in the 50/60/70% slots to me indicates that Rapid Shot and Snapshot are entirely separate activations.
The thrown weapon test (Mamoolbane) gave slightly different distributions for Rapid Shot. Unfortunately I can only get an approximate estimate of the cluster values since all that's provided is a graph, but assuming the delay of (294/120)+0.4 = 2.85 is correct (and it seems to be a near perfect match), the clusters occur as follows:
Basically, they're equally spaced between them, but the top one is closer to the main cluster than the lower clusters are to each other.Code:0.88 ~= 56/64 0.72 ~= 46/64 0.57 ~= 36/64
The lowest cluster is very difficult to make out, but I'd put it at 45% of the primary delay.
The SMN test graph also showed a cluster at the 0.88 ~= 56/64 mark point, same as the first secondary cluster on RNG.
Overall, the distribution patterns for Rapid Shot on thrown weapons appear to be different enough from ranged weapons that I don't think we can use either to predict the other.
The distribution scale on the relic gun is low enough that it's very difficult to estimate anything from it. At best, there might be clusters every 5%, instead of the expected 10% intervals.
The main problem I have right now with forming a theory is the first Illapa test, with the high 80% cluster. I can't figure out why that's the primary spike rather than the highest 90% cluster.
Current speculation:
Snapshot determines the minimum delay reduction. 10% Snapshot would mean the highest cluster is 90%; 20% Snapshot would mean the highest cluster is 80%; etc.
A Rapid Shot proc creates a roughly equal distribution at 90%, 80%, 70%, 60%, 50%, and rarely 40% of the original delay. The highest percentage cannot be higher than what's allowed by Snapshot.
Given the Rapid Shot distribution, it fills in 5 potential cluster values at 10% each. Thus, overall, Rapid Shot has a 50% proc rate. If Snapshot prevents a higher value from occuring, the maximum well gets the overflow. It may possibly also increase the chance of a 40% proc.
Anything not subject to Rapid Shot falls in the 80% well (or the Snapshot well, whichever is lower).
This fits reasonably well with the currently available data. Would need more of Byrth's raw data, and probably other tests, to get a better read on how things work.
One other bit of info needed is exactly how displayed Snapshot values on gear correlate with the actual delay reduction. Can we confirm that +1 Snapshot = 2% delay reduction (as has been implied by some info)? Or is it +1 = 1%, as would normally be expected?
Am I reading this right in that rapid and snapshot aren't both factored in on procs instead it just uses the lower of the 2? So like if you have a lot of snapshot rapid shot wont do anything?
Not quite (though there's still issues with the model, so take with a grain of salt). If Rapid Shot procs (which won't always happen), the idea was that the max delay would still be the Snapshot delay. Though I guess if you got Snapshot delay reduction down to the minimum Rapid Shot value (rough estimate of 40%, but Overkill implied maybe 30%), Rapid Shot wouldn't do anything.
Still need to work through a lot of things before this makes sense, though.
I think we are saying the same thing... but to be clear it sounds like you are saying on rapid shot procs it doesn't add or multiply the rapid shot and snapshot reductions but just uses the greater reduction of the 2 of them?
Hypothesis, Revision 1, based on feedback from Byrth
The game receives packets from the server at intervals of approximately 0.4 to 0.45 seconds (subject to various lags). That means the information resolution of any received timing-related data can only be resolved to the nearest ~0.42 seconds.
That means that the discrete intervals of data clustering that were assumed to be the effect of Rapid Shot are, in fact, an artifact of the packet delivery system. As such we cannot assume any sort of discrete division.
The relic test data provided clusters of data every 0.4 seconds for everything between 4.5 seconds and almost 9 seconds. Given that, it's reasonable to assume that Rapid Shot generates a continuous distribution of possible aiming delays.
Now, the packet delay means that anything up to 0.4 seconds after the actual delay may show up as the primary cluster/spike. That means the method of determining delay in seconds based on weapon delay is skewed. In fact, the extra 0.4 seconds I added to my delay hypothesis is pretty much exactly an artifact of this.
As such, I can revise the delay hypothesis.
If we take the relic data and just use 999/120, we get 8.325 seconds. The main cluster is at 8.6 seconds (within 0.4 seconds of the proposed actual delay). The cluster prior to that is at 8.2. That means 8.325 could be perfectly valid, and all the hits that landed there would show up at 8.6 seconds.
Looking at the low end, the lowest cluster is at ~4.5 or a tad higher. That's notably higher than half of 8.325, however... 8.325 / 2 = 4.1625. Add 0.4 and it's at 4.5625, right where we see the lowest cluster.
Proposed delay hypothesis: Ranged weapon delay time is simply (delay / 120). That fits all of the available test data when the various bounds are accounted for.
Using that, we now have a delay for Mamoolbane of 2.45 seconds. If we consider Rapid Shots to be continuous from 50% to 100%, I can extract the probable portion of the primary cluster that should belong with the RS proc set. Doing so results in a proc rate of 42%.
Doing the same thing with the Illapa data gives a proc rate of 38%.
Given that Byrth mentioned having merited Rapid Shot to 5/5, that gives an actual trait range of 33%-37%. We can reasonably assume a 35% proc rate as a baseline.
For the anomalous high cluster on the Illapa data, we consider the Snapshot delay. With 10% Snapshot from merits, delay becomes 3.6 * 90% = 3.24 seconds. As it happens, that's almost exactly on top of the primary data cluster. Any fluctuations in the exact value would lead to the shot being pushed to the next data packet: 3.64 seconds. Thus the smaller upper cluster is the result of the data not quite making it into the packets being delivered.
Also interesting from that data set is the lowest delay value: 1.631 seconds. As it happens, that's just above 50% of the Snapshot delay: 3.24 * 50% = 1.62 seconds. That helps confirm the delay + Snapshot picture, as well as showing that Rapid Shot's 50% lower bound is determined after Snapshot is applied to the delay.
So, new hypothesis:
1) Nominal delay in seconds = delay / 120
2) Effective delay is nominal delay plus the effects of Snapshot (so 10% Snapshot would give an effective delay of 90% of nominal delay)
3) Rapid Shot generates a delay between 50% and 100% of the effective delay
4) Base proc rate on Rapid Shot is 35%
I'm rather comfortable with these results, so I'll go ahead and put them in the spreadsheet (which was a sort of haphazard guesstimate up til now). More testing is certainly needed, but now it can be done with the idea of disproving aspects of the proposal, rather than blind guessing.
Under this assumption, I wonder what happens when you've reached the delay reduction cap via snapshot. Does rapid shot do anything at all? I'm guessing it doesn't, but I'm curious to know.
FWIW, It's seems like Flurry II caps delay reduction on RNG with snapshot merits, velocity shot, and all available snapshot gear.
Courser's+flurry2 shoots faster than flurry2 alone, so that's not the case.
I can't tell any difference, but I'm just eye-balling. I tried Flurry I with an 11 coursers, and it also shot at what seemed to be an identical speed as Flurry II by itself.
I'm also going under vague assumptions based on currently tested snapshot values, and ideas on what delay cap should be. (80%)
i.e.
velocity shot = 13-15%
merits = 10%
Caban = 5-10%
Gappette = 3-5%
Iuitl w. = 5-10%
Impulse = 3% (?)
Nahtirah = 9%
Wurrukatte = 3%
Either way, if Flurry II is 30% delay reduction, we should be right around 80% if not a bit over.
If we are at the point that Velocity, Coursers and Flurry 2 are capping Ranged Delay, then we should be able to start swapping out Snapshot for Rapid Shot, depending on Courser Roll.
Also, Overkill + Flurry 2 + Velocity + Gear = shooting before the gun is stationary.
Well if we were capped ranged delay I don't think rapid shot would do anything
Anyone tried testing caps yet? Also just decided to look thru new gear and iirc +1 snapshot is 2% right? If so we gained a couple of new top snapshot pieces one of them being Aurore Beret +1 as sad as that is lol
https://www.bg-wiki.com/bg/Snapshot
https://www.bg-wiki.com/bg/Aurore_Beret_%2B1
Unless wiki is incorrect, Empyrean Head +2 is the same Snapshot as Aurore Beret +1, both are listed as 5%.