Item Search
     
BG-Wiki Search
+ Reply to Thread
Page 4 of 6 FirstFirst ... 2 3 4 5 6 LastLast
Results 61 to 80 of 102
  1. #61
    Relic Horn
    Join Date
    Sep 2011
    Posts
    3,304
    BG Level
    7
    FFXI Server
    Leviathan

    Quote Originally Posted by Orestes View Post
    I'm curious how much total delay reduction we can get out of stacking Rapid Shot from Orion Beret +1 (14), Arcadian Jerkin +1 (12), and Arcadian Socks +1 (6). (32 total)

    In a previous post you mention the base trait contributes to a total of 10% delay reduction.

    Conclusions:
    * Rapid Shot job trait on 99RNG reduces ranged delay by an average of 10%.


    If approx. 32% rapid shot contributes to 10% delay reduction, do you think it's somewhat safe to assume adding another +32 rapidshot would equal -20% dealy reduction? (not including merits)

    Thanks
    No. The values on AF armor aren't cut and dry enough to make that assumption.

    It's possible, but nothing I'd make significant preshot changes for until we know more about it

  2. #62
    Ridill
    Join Date
    Apr 2011
    Posts
    23,736
    BG Level
    10
    FFXI Server
    Bahamut

    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

  3. #63
    HABS SUCK!!!!!
    Sepukku is my Hero
    Therrien's Cum Dumpster

    Join Date
    Mar 2005
    Posts
    37,942
    BG Level
    10
    FFXI Server
    Gilgamesh

    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?

  4. #64
    E. Body
    Join Date
    Nov 2008
    Posts
    2,032
    BG Level
    7
    FFXI Server
    Bismarck

    Quote Originally Posted by NynJa View Post
    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 changes gear fast enough that it's not an issue.

  5. #65

    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.

  6. #66
    Ridill
    Join Date
    Apr 2011
    Posts
    23,736
    BG Level
    10
    FFXI Server
    Bahamut

    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

  7. #67
    E. Body
    Join Date
    Nov 2008
    Posts
    2,032
    BG Level
    7
    FFXI Server
    Bismarck

    Gearswap is fast enough to change gear if Instant Cast procs. So Rapid Shot is not an issue.

  8. #68
    The Syrup To Waffles's Waffle
    Join Date
    Jun 2007
    Posts
    5,053
    BG Level
    8
    FFXIV Character
    Cair Bear
    FFXIV Server
    Excalibur
    FFXI Server
    Fenrir

    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.

  9. #69
    Chram
    Join Date
    Sep 2007
    Posts
    2,526
    BG Level
    7
    FFXI Server
    Fenrir

    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):

    Code:
    1.631
    2.040
    2.414
    2.856
    3.264
    3.638
    Also want to look at difference between each cluster value:
    Code:
    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
    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 values

    I also looked at what percentage of all samples fell within each cluster:

    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 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%.


    The same information for the test that added the AF3+2 hat.

    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
    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%.


    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:

    Code:
    0.88 ~= 56/64
    0.72 ~= 46/64
    0.57 ~= 36/64
    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.

    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?

  10. #70
    Ridill
    Join Date
    Apr 2011
    Posts
    23,736
    BG Level
    10
    FFXI Server
    Bahamut

    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?

  11. #71
    Chram
    Join Date
    Sep 2007
    Posts
    2,526
    BG Level
    7
    FFXI Server
    Fenrir

    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.

  12. #72
    Ridill
    Join Date
    Apr 2011
    Posts
    23,736
    BG Level
    10
    FFXI Server
    Bahamut

    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?

  13. #73
    Chram
    Join Date
    Sep 2007
    Posts
    2,526
    BG Level
    7
    FFXI Server
    Fenrir

    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.

  14. #74
    Hydra
    Join Date
    Feb 2014
    Posts
    131
    BG Level
    3
    FFXI Server
    Quetzalcoatl

    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.

  15. #75
    D. Ring
    Join Date
    Jul 2008
    Posts
    4,529
    BG Level
    7
    FFXI Server
    Phoenix

    Courser's+flurry2 shoots faster than flurry2 alone, so that's not the case.

  16. #76
    Hydra
    Join Date
    Feb 2014
    Posts
    131
    BG Level
    3
    FFXI Server
    Quetzalcoatl

    Quote Originally Posted by Darkmagi View Post
    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.

  17. #77
    E. Body
    Join Date
    Nov 2008
    Posts
    2,032
    BG Level
    7
    FFXI Server
    Bismarck

    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.

  18. #78
    Ridill
    Join Date
    Apr 2011
    Posts
    23,736
    BG Level
    10
    FFXI Server
    Bahamut

    Well if we were capped ranged delay I don't think rapid shot would do anything

  19. #79
    Ridill
    Join Date
    Apr 2011
    Posts
    23,736
    BG Level
    10
    FFXI Server
    Bahamut

    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

  20. #80
    E. Body
    Join Date
    Jan 2009
    Posts
    2,086
    BG Level
    7
    FFXI Server
    Quetzalcoatl

    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%.

+ Reply to Thread
Page 4 of 6 FirstFirst ... 2 3 4 5 6 LastLast