Ranger Firing Range - Testing

Eorzea Time
 
 
 
言語: JP EN FR DE
日本語版のFFXIVPRO利用したい場合は、上記の"JP"を設定して、又はjp.ffxivpro.comを直接に利用してもいいです
users online
フォーラム » FFXI » Jobs » Ranger » Ranger Firing Range - Testing
Ranger Firing Range - Testing
First Page 2 3 4
Offline
By Verda 2016-10-30 11:11:15  
All my testing for ranger is spread out in multiple threads and pages in general ranger threads, and makes it hard to find refer to and for others to collaborate with so welcome to the firing range, where those problems are no more. I encourage you to pick up a weapon and shoot some stuff with me, it'll be fun! Try not to forget your lab coat and sharpened pencils while you're at it.

I will edit this post with my testing statuses as I get to do them (or others do them for me). A lot of testing done so far is on ranged attack speed, as it's very not understood and very important for anyone shooting things.

In Queue/In Progress
THF - Network Delay Test
[Requires: Using two different internet connections, one with low delay, one routed through a VPN with very high delay.]
[Method: Compare the same set of tests with multiple delay weapons to see how network delay can affect ranged shots. Use THF to rule out rapid shot.]
[Why: To see how and if network delay is included in aiming delay and if that being included more often can help explain why flurry/snapshot seem to lose some effectiveness with lower delay weapons]
[Hypothesis: Ranged aiming delay will tack on the delay from SE's server to the client, once, and this will have a 10-15% influence on would be speed on extremely low delay weapons and also every shot with high delay reductions like capped snapshot. Also, weapons with a big ratio of the aiming delay shifted out of aiming delay because the delay is in the ammo will be less effected by this, and maybe SE knew this in part when designing them since low delay weapons tend to be crossbows and crossbows have the best ratio of aiming delay to ammo]

THF - Embrava Snapshot Test - Suggestion by Bismarck.Snprphnx
[Requires: Baseline Aiming Delay and SCH to Embrava and test with]
[Method: Abuse friendships to get SCH to help you]
[Why: So we know how much snapshot to gear for when embrava is active]
[Hypothesis: It will do more than Flurry II, if not cap snapshot by itself due to it being tied to SCH 1 hour]

RNG - Gastra Snapshot Test
[Requires: Baseline on THF with same delay ranged weapon, Gastra]
[Method: Compare Baseline and capped snapshot on THF to Ranger with Gastra and same gear]
[Why: To see if there's possibly any "breaks the cap" snapshot gear for ranger, like there is for magic burst and many other jobs gear]
[Hypothesis: Nothing ever released gives us cause to think it does but it's something I want to know anyway, I believe it will not break cap.]

Testing Done
RNG - Test Velocity Shot with Capped Snapshot
[Requires: Known snapshot caps and flurry values]
[Method: Equip max snapshot and then do a set of tests to compare to, then use velocity shot and do a set of the same test with the same snapshot values]
[Why: To see how to gear ranger, if Velocity shot is special then we need to not count it as snapshot in our gearing]
[Hypothesis: Due to my testing and Zeke's observations, Velocity will either be additive or multiplicative with snapshot but still increase firing speed beyond snapshot cap. Due to Byrth's testing I believe it will somehow be additive but due to testing it also seems multiplicative at first. Whether it is additive or multiplicative will be hard to test since Rapid Shot is multiplicative already. ]
[Conclusion: Safe to conclude Velocity Shot is multiplicative as its own term with Snapshot, thus in effect breaking the 70 snapshot cap]

THF - Test Snapshot Cap
[Requires: tons of snapshot taeon augments, snapshot ambu cape, and confirmed Flurry values]
[Method: You can get a lot of snapshot through augments and cap pretty easily if you use flurry 2, then add in more snapshot and see if delay goes down. Use THF to rule out rapid shot.]
[Why: So we know how much snapshot to gear for]
[Hypothesis: It will be as SE said, 70 snapshot cap]
[Conclusion: Safe to conclude 70 snapshot is the cap]

THF - Test Flurry 2 compared to 15 snapshot and Flurry I compared to a 30 snapshot set
[Requires: Flurry 2 Trust, Snapshot set with exactly 15 and exactly 30 snapshot for THF, multiple delay weapons for THF]
[Method: Use these sets to show Flurry levels, use THF to rule out rapid shot]
[Why: Flurry will be used in other testing and is needed to know for how to gear snapshot.]
[Hypothesis: As shown in prior testing, lower delay weapons will get a bit less out of it on average but for about a 582 delay weapon it will be flurry is about 15% effective aiming delay reduction and for a very high delay weapon about 17% effective aiming delay reduction (culverin) and a very low delay weapon about 12.8% effective aiming delay reduction]
[Conclusion: For a 582 Delay weapon, 30% Flurry II and 15% Flurry I values are safe to conclude]

* Ranged Delay and Ammo Delay - tackles things like how ammo delay is not aiming delay but just benefits you as free TP and how there's 1 second between each ranged shot, and how ranged attacks get a different delay divisor (which in turn means we for the most part, get that 1 second counted into our TP gain).
* Flurry Testing Part 1 - shows how flurry and snapshot reduction varies some with how long a delay weapon you have, a longer delay weapon will get a bit more benefit from snapshot/flurry. (Avg reduction for a low delay weapon like Tsoabichi with 15% snapshot or Flurry I tends to be about 13%. For a mid delay weapon like Failnaught about 15% and for a higher delay weapon like Culverin it's about 17%). Opens questions for network delay, and other testing.
* Testing if Velocity Shot is special vs Snapshot

Testing Done by others in the Past and Resources
* Older mostly defunct testing on Amini Caban
* Byrth on Velocity and Snapshot
* BG mega thread on Ranged Delay and Snapshot and Stuff
* Official Forums Translation on Snapshot caps
* JP Wiki on Rapid Shot
* JP Wiki on Velocity Shot
* SE on Flurry 2 being 30%
* JP Wiki on Snapshot
* BG Wiki Snapshot, Velocity Shot, Rapid Shot

Please keep posts informative rather than speculative so it is a good resource. If you have speculation, make it a hypothesis and test it or propose a new test, just don't be upset if no one tests your hypothesis for you.

Subjects other than aiming delay and how ranged attacks work welcome.
[+]
Offline
By Verda 2016-11-01 21:20:35  
THF - Test Flurry 2 compared to 15 snapshot and Flurry I compared to a 30 snapshot set, Test Flurry I compared to a 15 snapshot set
[Requires: Flurry 2 Trust, Snapshot set with exactly 15 and exactly 30 snapshot for THF, multiple delay weapons for THF]
[Method: Use these sets to show Flurry levels, use THF to rule out rapid shot]
[Why: Flurry will be used in other testing and is needed to know for how to gear snapshot.]
[Hypothesis: As shown in prior testing, lower delay weapons will get a bit less out of it on average but for about a 582 delay weapon it will be flurry is about 15% effective aiming delay reduction and for a very high delay weapon about 17% effective aiming delay reduction (culverin) and a very low delay weapon about 12.8% effective aiming delay reduction]


1000 is 1 second for all datasets, mean and standard deviation are converted to seconds, all tests on THF/RDM

Test 1 - Baseline Delay
ItemSet 347499

Dataset:
Mean: 5.1417436996 seconds
Standard Deviation: .2858796 seconds
582 delay, would correspond to about 114 divisor. 582/114 = 5.1052
Network Delay to server average: 405ms


Test 2 - 15 Snapshot
ItemSet 347500 - cape is 10 snapshot

Dataset:
Mean: 4.30543238414
Standard Deviation: .2665036
Expected: 582/114 = 5.1052 * .85 = 4.3392
Network Delay to server average: 395ms

Test 3 - 0 Snapshot Flurry I
ItemSet 347499

Dataset:
Mean: 4.38717534383
Standard Deviation is: .2139026
Expected: 582/114 = 5.1052 * .85 = 4.3392
Network Delay to server average: 344ms

Test 4 - 30 Snapshot
ItemSet 347501 Taeon is 10 snapshot each.

Dataset:
Mean: 3.6231396746
Standard Deviation: .1924809
Expected: 582/114 = 5.1052 * .85 = 3.57364
Network Delay to server average: 357ms

Test 5 - 0 Snapshot Flurry 2
ItemSet 347499

Dataset:
Mean: 3.64136301095
Standard Deviation: .1895793
Expected: 582/114 = 5.1052 * .85 = 3.57364
Network Delay to server average: 417ms


This was a more controlled test to check against an earlier set of tests.

Observations:
* A 114 Divisor seems to hold up pretty well. The divisor is probably 120 on the server but varies a bit in effect due to network delay. This would make the 60 divisor of melee vs the 120 divisor of ranged match up nicely with the 1 second delay between shots. For the network delay test I suggest actually doing a 120 divisor to show the added network delay being there.
* Standard Deviation average seems to go down with more delay reduction, but only slightly. The server sending things out at fixed intervals could help explain this possibly, or it could be coincidence.
* Even with no rapid shot, due to my internet most likely having a lot of variance in ping delays so do the shots. What can not be explained by this is shots that are faster than they should be by the formula, it is almost as if the server did send out packets at intervals, but sometimes sends out ranged packets earlier, possibly to help make up for the fact some shots will be longer if packet artifacts do indeed exists, though this behavior could also just be explained by the server somehow taking your average latency into account or even just the internet being weird.
* Telling the difference between the variable shot delay and rapid shot will be impossible. Suggest trying on a more consistent internet if possible.
* Many of the shot groupings are very close in their time to each other.

Conclusions:
The mean of 30 snapshot and 30 flurry are nearly identical. The mean for Flurry I and 15 snapshot are also nearly identical. Prior testing sets showed this as well with which one was slightly more actually swapped. Due to these reasons, I conclude it is safe to conclude for a 582 delay weapon 15% aiming delay reduction is the value for Flurry and 30% delay reduction is the value for Flurry II. Due to prior testing, we know this number will wax on higher delay weapons and wane on lower delay weapons but the reason for that still isn't clear, or if it affects caps, but it is thought to be something with network delay or sending frequency of the SE server.

Thank You Aya for using Mog Pells in the name of science, and Mili and Hyph for stone donations and flurry 2 when I needed it on THF. (Also thank you to ffxiah, SE for making the game and the supportive ranger community :) I got lucky actually on 10 snapshot augs with only about 4.5 stacks of +1/+2s.
[+]
 Leviathan.Celebrindal
Offline
サーバ: Leviathan
Game: FFXI
Posts: 3753
By Leviathan.Celebrindal 2016-11-02 09:27:52  
As a player who began as a mage, all this testing is a godsend! Thank you!!!
[+]
 Fenrir.Snaps
Offline
サーバ: Fenrir
Game: FFXI
user: Mojopojo
Posts: 1139
By Fenrir.Snaps 2016-11-02 11:46:42  
Seems like a 15 Snapshot Fury I test would be good to verify that they they stack.
Offline
By Verda 2016-11-02 12:08:47  
Ya I did do a test like that in the flurry testing part 1, just didn't redo it here. I can put that on my list though.
Offline
By Verda 2016-11-02 14:08:41  
THF - Test Snapshot Cap
[Requires: tons of snapshot taeon augments, snapshot ambu cape, and confirmed Flurry values]
[Method: You can get a lot of snapshot through augments and cap pretty easily if you use flurry 2, then add in more snapshot and see if delay goes down. Use THF to rule out rapid shot.]
[Why: So we know how much snapshot to gear for]
[Hypothesis: It will be as SE said, 70 snapshot cap]

1000 is 1 second for all datasets, mean and standard deviation are converted to seconds, all tests on THF/RDM

Test 1 - 40 Snapshot Flurry 2 total 70 snapshot
ItemSet 347532
Taeon is all 10 snapshot, so is cape.
Dataset:

Mean: 1.73366941732
Standard Deviation: .230912
Expected: 582/114 = 5.1052 * .3 = 1.5315789
Average Network Delay: 408ms

Test 2 - 54 Snapshot Flurry 1 total 69 snapshot
ItemSet 347533
Taeon is all 10 snapshot, so is cape, legs don't have rapidshot aug
Dataset:
Mean: 1.84944907924
Standard Deviation: .1670106
Expected: 582/114 = 5.1052 * .31 = 1.5826315
Average Network Delay: 314ms

Test 3 - 54 Snapshot Flurry 2 total 84 snapshot
ItemSet 347533
Taeon is all 10 snapshot, so is cape, legs don't have rapidshot aug
Dataset:
Mean: 1.73299990506
Standard Deviation: .2701716
Expected: 582/114 = 5.1052 * .3 = 1.5315789
Average Network Delay: 444ms

Observations:
* Actual seconds delay is about .2 seconds longer than expected, possible to explain this in network delay tests
* Standard Deviation is a bit unstable sometimes, probably due to latency spikes in the data.

Conclusions:
84 Snapshot and 70 snapshot had no discernible difference, it is safe to conclude 70 snapshot is the cap when coupling this set of data with SE's official statements. Much higher sample sizes would make me even more sure, but I am pretty confident this is the case, even with the mean for the 69 snapshot test being higher than expected it is within the range I'd consider the test to be inaccurate and the test 1 and test 3 means are so close that I see any other conclusion as highly unlikely.
[+]
 Leviathan.Celebrindal
Offline
サーバ: Leviathan
Game: FFXI
Posts: 3753
By Leviathan.Celebrindal 2016-11-25 13:26:06  
Something I now am pondering, on traditional melees as your magic haste increases, you optimize your gear not so much for haste, but for multi-attack,higher attack,store TP,whatever best suits your job and it's ability to deal damage better with less dedicated "haste" gear...common knowledge yes. What are ways I can tweak my preshot sets depending on the level of Flurry I'm receiving to increase dps? What are the BiS swaps if you will?
Offline
By Verda 2016-11-25 13:29:38  
That question has been addressed in other threads please keep this to testing and results.
[+]
Offline
サーバ: Sylph
Game: FFXI
Posts: 61
By Sylph.Padisharcreel 2016-11-25 13:31:08  
If you're overcapped on snapshot, swap the excess out for more rapid shot
Offline
By Verda 2016-12-20 11:45:59  
RNG - Test Velocity Shot with Capped Snapshot
[Requires: Known snapshot caps and flurry values]
[Method: Equip max snapshot and then do a set of tests to compare to, then use velocity shot and do a set of the same test with the same snapshot values]
[Why: To see how to gear ranger, if Velocity shot is special then we need to not count it as snapshot in our gearing]
[Hypothesis: Due to my testing and Zeak's observations as well as other player testimonies and my own observations, Velocity will either be additive or multiplicative with snapshot but still increase firing speed beyond snapshot cap. Due to Byrth's testing I believe it will somehow be additive but due to testing it also seems multiplicative at first. Whether it is additive or multiplicative will be hard to test since Rapid Shot is multiplicative already. ]

Set used with GS turned off, no equipsets used:
ItemSet 348391

0 0 0 0
10 0 0 0
0 5 0 0
10 3 9 10

47 snapshot from gear, 10 from merits is 57 snapshot. With 15 from flurry that is 72.

Test 1 Velocity Shot off, Amini Caban +1 removed, Flurry I cast on myself.

Data over 103 shots:

Standard Deviation: 378.8515 (.378 seconds)
Mean: 2257.6125863882 (2.257 seconds)

Test 2 Velocity Shot on, Amini Caban +1 on, Flurry I cast on myself.

Data over 103 shots:

Standard Deviation: 231.9078 (.231 seconds)
Mean: 1546.8635609451 (1.546 seconds)

Now unless this sample set is wildly unbalanced in rapid shot procs then it's glaringly obvious Velocity Shot is a huge boon and is treated separately from snapshot. We can do a test vs the data by comparing only the longest duration shots, so here is the 10 longest shots for test 1, note 1000 would equal 1 real time second:

2653.850585937500
2622.564453125000
2622.260986328125
2572.132324218750
2567.180664062500
2562.646972656250
2560.386718750000
2559.814453125000
2559.640869140625
2558.105468750000

And for test 2:

1917.478759765625
1879.076171875000
1791.242675781250
1771.686523437500
1762.016357421875
1755.296875000000
1744.869140625000
1685.733886718750
1679.998535156250
1679.769531250000

The chance that every single shot had a great rapid shot proc in the 2nd test and every single shot in the 1st test didn't for those 10 shots would be .35^10 * .5 (for the half of reductions that are between 4/16 and 8/16 to make this large of a reduction even start to make sense) would be .001379% chance. so basically this is how it is, Velocity Shot breaks the cap of snapshot.

Ok but how does it break the cap of snapshot? Well I'm glad you asked!

2257.6125863882 is the mean for test 1
1546.8635609451 is the mean for test 2

We know we have 34% velocity shot.

2257.6125863882 * (1 - .34) = 1490.024307016212

This is only 56.839253928888 difference between what we'd expect if it was multiplicative. That in my view is within the bounds of randomness you'd get from packet delay differences and rapid shot differences. Actually well within it.

We also know it can't be additive, because you know like 70 + 34 is over 100 and you can't have a 100% delay reduction (darn it SE let me attack infinity times per second!).

The remaining question then is how does it stack with rapid shot? Well SE told us that Snapshot is multiplicative with Rapid Shot already. So what does that mean for Velocity Shot which is also multiplicative? Well as we know multiplication is associative and communitative even if we don't remember them by those names, everyone knows 2 * 3 is the same as 3 * 2 and 2 * 3 * 4 is the same a 4 * 3 * 2. So they all multiply with each other and as far as outcome is concerned, it doesn't matter what order they multiply with each other.

So Ranged Attack Delay can be summed up as follows:

Snapshot x Velocity Shot x Rapid Shot

Rapid Shot for each shot is determined by Rapid Shot % chance to activate, and if it activates, will be a multiplier between 15/16 and 8/16 (or reduces by 1/16 to 8/16). Note the values for Rapid Shot was taken from the JP Wiki.

This is a good Flurry I build I could come up with using this info:
ItemSet 348390

However the community might come up with better and we also have to come up with good no flurry builds and flurry II builds. For this set however:
Taeon is 10 Snapshot, Belenus is 10 Snapshot.

Since I always put the conclusions at the bottom, the tl;dr is it is safe to conclude Velocity Shot is multiplicative as its own term with Snapshot, thus in effect breaking the 70 snapshot cap.
[+]
Offline
Posts: 96
By Darksparksnot 2016-12-20 12:11:17  
So you're saying velocity doesnt count for 70snap cap and we still need 70snap in gear/buff?
 Quetzalcoatl.Alvon
Offline
サーバ: Quetzalcoatl
Game: FFXI
user: Alvon
Posts: 8
By Quetzalcoatl.Alvon 2016-12-20 12:13:24  
Great finding, I've always 'felt' snapshot cap is more than 70% guess this is why. Appreciate for taking your time and test it.
Offline
By Verda 2016-12-20 12:42:40  
Darksparksnot said: »
So you're saying velocity doesnt count for 70snap cap and we still need 70snap in gear/buff?

That's correct, merits too though!

Quetzalcoatl.Alvon said: »
Great finding, I've always 'felt' snapshot cap is more than 70% guess this is why. Appreciate for taking your time and test it.

You're welcome :D Thank you for the thanks ^^
 Fenrir.Snaps
Offline
サーバ: Fenrir
Game: FFXI
user: Mojopojo
Posts: 1139
By Fenrir.Snaps 2016-12-20 13:31:15  
For no Flurry situations.

ItemSet 345751

This should be 70 Snapshot and is probably the most practical mix between what's best and what's obtainable. If you have Gastraphetes, you can use Amini Caban.
[+]
 Fenrir.Snaps
Offline
サーバ: Fenrir
Game: FFXI
user: Mojopojo
Posts: 1139
By Fenrir.Snaps 2016-12-20 13:36:35  
Also, if you chose Haverton Ring, you can use Haverton Ring, Amini Caban, and reforged +3 legs without Gastraphetes.
[+]
 Fenrir.Snaps
Offline
サーバ: Fenrir
Game: FFXI
user: Mojopojo
Posts: 1139
By Fenrir.Snaps 2016-12-20 13:42:39  
I think Verda's set for Flurry I is correct, other than dropping HQ kecks for NQ kecks. I don't think using HQ kecks for a shapshot piece is a good use of them (you're only gaining rapid shot anyways as Snapshot is still capped), but if you have infinite money I guess by all means. You can drop Taeon Chappeau for Orion Beret when using Gastraphetes.
 Fenrir.Snaps
Offline
サーバ: Fenrir
Game: FFXI
user: Mojopojo
Posts: 1139
By Fenrir.Snaps 2016-12-20 16:30:50  
Using the Flurry I set Verda posted (subbing in Orion Beret +1 for Gastra), the expected mean actual delay (including aiming delay) for Gastra and Fomalhaut are as follows.

Gastra - 1.3458486842105262 seconds
Fomalhaut - 1.585207236842105 seconds

In practice, your results are going to be a bit higher because packet delay. Either way it doesn't seem to favor Gastraphetes (D321) over Fomalhaut (D467). You need less Store TP to 3 shot with Fomalhaut, and your WS will be much chunkier. Cooldown after using a WS is also the same for both weapons. I know Gastra has True Flight +30% and ODD/ODT, but Fomalhaut has TP Bonus +500 (fairly equivalent) and Aftermath lets True Flight -> True Flight make Light (or Radiance if you have level 3.)
Offline
By Verda 2016-12-20 16:37:56  
Can we take balance discussion to another thread please? I will say I don't actually agree though :/
 Siren.Kyte
Offline
サーバ: Siren
Game: FFXI
Posts: 3331
By Siren.Kyte 2016-12-20 16:45:39  
Quote:
I know Gastra has True Flight +30% and ODD/ODT, but Fomalhaut has TP Bonus +500 (fairly equivalent) and Aftermath lets True Flight -> True Flight make Light (or Radiance if you have level 3.)

Mythic WS don't have level 3 properties, nor does AM grant them.
necroskull Necro Bump Detected! [54 days between previous and next post]
 Fenrir.Snaps
Offline
サーバ: Fenrir
Game: FFXI
user: Mojopojo
Posts: 1139
By Fenrir.Snaps 2017-02-12 23:05:48  
Reposting cause I'm dumb and posted it in the Omen thread by mistake.


I did some testing today to try and gauge whether or not it would be worth the effort to improve the autora addon I'm working on. I got some weird results.

I used 70(71) Shapshot, 34 Velocity Shot, and some amount of Rapid Shot (56 assuming Rapid Shot II gives 30%).

Code
Weapon		Delay	Delta
Atalanta	130 	1.967172
Shortbow	360	2.276916
Self Bow	450	2.365931
Longbow		540	2.438667
Shigeto Bow	600	2.588359
Musketoon	600	2.617526

The delta is the time between each incoming ranged attack start packet over the course of at least 200 ranged attacks. I used Comeatmebro's method of injecting a ranged attack packet on every outgoing UDP chunk. You shouldn't be able to shoot faster than this but it comes with the expense of not being able to use an idle set. Musketoon was included to verify that ammo delay doesn't affect anything (and it appears that it does not.)

The first thing I noticed is that the delta for the lower delay weapons is lower than anticipated. Assuming the model delta = delay * A + B where A is the mean reduction from Snapshot/Velocity Shot/Rapid Shot and applying linear regression to all of the data except Musketoon and yields A = 0.001257002 and B = 1.807010262 with R^2 = 0.993407499 (please someone double check this.) This would imply that the ranged cool down is actually 1.8 seconds. The percent error from A using Verda's model is 0.69%.

It would be nice if someone else could repeat this as it seems like a large detriment to lower delay weapons. If you have a good preshot set, the overwhelming majority of the resulting delay is not from the weapon itself. There may have been instrumentation error on my part as the windower packets API is a black box to me (I don't have hook access so I don't know what actually happens to the injected packets.) I did get the "You must wait longer to perform that action" packets though (but not as many as I was expecting) so it is probably a valid experiment. The data has a smooth range of deltas for the various delays so there's that too.

In regards to how this stacks up to the addon I'm working on (which doesn't use Comeatmebro's method, it's more vanilla than that), here's the data I have for the two weapons I tried.

Code
Weapon		Delay	Addon		Injected	Gain
Atalanta	130	2.045053	1.967172	3.96%
Shigeto Bow	600	2.668045	2.588359	3.07%

The gains are much smaller than I thought, which is unexpected and makes me question the results. I'll probably stick with my method as I think the value of an idle set is greater than a 3~4% marginal gain in shooting speed.
[+]
 Fenrir.Snaps
Offline
サーバ: Fenrir
Game: FFXI
user: Mojopojo
Posts: 1139
By Fenrir.Snaps 2017-02-12 23:08:00  
Responses -

Leviathan.Comeatmebro said: »
the 'value of an idle set' is only going to be the same 3-4% as the gain since you're still wearing shooting gear during the shot, unless i misunderstood something, which seems like pretty near no value

interesting test though, 1.8s cooldown is much higher than i would've expected
Fenrir.Snaps said: »
I mean the value in being able to idle in PDT (injecting on every UDP packet means you can't, you're always in your midshot.) Please feel free to repeat the experiment, I was also surprised at 1.8 seconds and I'm afraid I may have done something wrong.
Fenrir.Snaps said: »
Also, it's probably worth stating that the cool down the server enforces is probably less than 1.8 seconds and that there is some artifacting due to the client only sending a UDP packet every elapsed .4 seconds. For modeling purposes though 1.8 should be valid as an ideal.
Leviathan.Comeatmebro said: »
My point was that the period you're idling is extremely small, it's not providing much of any benefit.
Leviathan.Comeatmebro said: »
also, re: repeating the experiment

what target/setup did you use to make it easy? ceizak uragnite? Not opposed to doing another test if it can be easily automated.
Fenrir.Snaps said: »
I used Jaochim for Poisona, one mage to cast Flurry every 90 seconds, and did uraganites basically afk'd while collecting data. Also gonna try and move all of these posts over to the ranged attack testing thread where I intended to put them in the first place.
 Fenrir.Snaps
Offline
サーバ: Fenrir
Game: FFXI
user: Mojopojo
Posts: 1139
By Fenrir.Snaps 2017-02-12 23:34:43  
I went through and calculated the TP per strike for the weapons and used them to get a rough assessment of base TP rate using my preshot build results.

Code
Weapon      Delay TP/s
Atalanta    130   26.433886
Shortbow    360   46.115011
Self Bow    450   53.678657
Longbow     540   61.098961
Shigeto Bow 600   58.724473

It's unsurprising but the lower delay weapons don't hold up so well. There's more to DPS than this (weaponskill delay, x hit builds and such) but it is an interesting result.
Offline
By Verda 2017-02-13 01:33:51  
Cool :D thanks for this data man. Good stuff.

I believe 1.8 is pretty high, I will try to do a similar test but it might take me a while. I'm very sure the reload delay is 1 second except when packet scheduling or lag messes it up. They mystery is the shifting divisor and what seems a static value added to every shot which I'm going to guess is packet delay.

Fenrir.Snaps said: »
Assuming the model delta = delay * A + B where A is the mean reduction from Snapshot/Velocity Shot/Rapid Shot and applying linear regression to all of the data except Musketoon and yields A = 0.001257002 and B = 1.807010262 with R^2 = 0.993407499 (please someone double check this.) This would imply that the ranged cool down is actually 1.8 seconds. The percent error from A using Verda's model is 0.69%.

Lets add in some things we know.
Delay = Reload Delay + (Weapon Delay/114) * A + B
Delay = 1 + (600/114) * .195 + B = 2.0263
This would make B, which is probably your network delay or packet scheduling delay or some combination of them = .562 or about 256ms ping, round trip which seems reasonable. It's also a bit over half of the packet scheduling delay of .4 seconds so also seems reasonable.

Quote:
If you have a good preshot set, the overwhelming majority of the resulting delay is not from the weapon itself

That's actually true for most weapons because reload is 1 sec delay you can do nothing about, and then you factor in this other delay which is probably network lag. A 600 delay weapon should shoot at 1 + (600/114 * .3 * .65) + NetworkDelay = 1 + NetworkDelay + 1.0263 so if your NetworkDelay variable is higher than .0263 seconds then most of the ranged delay isn't from the weapon itself even on a 600 delay weapon.
Code
Atalanta    130 1.967172  76%
Shortbow    360 2.276916  87.9%
Self Bow    450 2.365931  91.4%
Longbow     540 2.438667  94.2%
Shigeto Bow 600 2.588359  100%
Musketoon   600 2.617526  101.1%


I added some %. Lets ignore Atalanta for now, I made Shigeto Bow what we compare everything to, since so many weapons are 600 delay.

What this shows is the self bow has about an 8.6% increase in attack speed, and Longbow about 7.8%. Assuming you are able to make 3 hit builds for all these weapons, that's an advantage. Not as big as we'd want but still an advantage. It would be interesting to know your ping to the servers listed in resource manager at the time of your tests.

When comparing Delay per point of TP don't forget to add in ammo as free TP, that isn't included in delay:

Adjusted with Ammo included
Code
Weapon      Delay     TP/hit  TP/s
Atalanta    130+192   95.711  48.654
Shortbow    360+90    134.33  58.99
Self Bow    450+90    149     62.977
Longbow     540+90    154     63.149
Shigeto Bow 600+90    161.7   62.472


But, you also have to factor in Arcadian Beret with Recyle, as it grossly favors low delay weapons for % gain. +45 since we're doing 50 * .9 = 45 for average.
Code
Weapon      Delay     TP/hit      TP/s
Atalanta    130+192   95.711+45   71.529
Shortbow    360+90    134.33+45   78.76
Self Bow    450+90    149+45      81.997
Longbow     540+90    154+45      81.6
Shigeto Bow 600+90    161.7+45    79.8575


Now some of this will go back the other way, when you start adding STP.

To me the most apparent difference in practice you should ask with low vs high delay weapons is do you value tp overage more or time till weaponskill more?

Lower delay weapons will have less tp overage and better time till WS because they will get their 3 hit sets done up to about 12% faster. Which means more weaponskills on average which in some situations translates to more damage, outside Atalanta which you can't 3 hit with. However higher delay weapons will have more TP overage. It comes down to WS. Jishnu's doesn't benefit a ton from tp overage, Last Stand and Trueflight do. TF however is already strong enough without lots of Tp overage, but one thing that makes the Aeonic Gun good is the tp overage it can get along with tp bonus. Jishnu's should also get an honrable mention for more TP return on the 3rd hit over Last Stand. Combine either build with Conserve TP being so high on RNG especially with Fotia's and you got a lot of TP. It gets even more complicated than this, like factoring in how big of a time is the WS time vs the TP phase. But in the end, and based on experience, both high and low delay weapons have a lot to offer ranger, and each have a different set of strengths and weaknesses. While the reload delay and B delay hit them harder, this is offset by things like they can still 3 hit so can WS faster, and Arcadian Beret +1 does more for them and for xbows, they have a pretty good Ammo delay which is delay free TP gain. The biggest downfall of lower delay weapons is usually lower base damage. It's just that with magical WS and am3 procs and abrasion bolts available that becomes a non issue.

As usual with Ranger, my advice is play the part of the hunter job class you are. Fit your gear to what you need for a particular fight, you get a slew of weapons with different advantages and disadvantages and it's one of the most fun things about the job.
 Lakshmi.Byrth
VIP
Offline
サーバ: Lakshmi
Game: FFXI
user: Byrthnoth
Posts: 6137
By Lakshmi.Byrth 2017-02-13 13:22:52  
I could rationalize up to a 1.4 second offset, but 1.8 is higher than expected. It looks like it's one packet off the prediction.

The slope of the regression (0.001172~0.001305) is also lower than I'd expect, indicating less of a dependence on delay than we'd anticipate. Assuming you were using all the enhancing gear for Velocity Shot/etc. and Rapid Shot works in the most optimistic way (0.71875*average delay per proc) proposed, you'd expect a slope of 0.001390. Perhaps that is still in the noise, but it also might be that some of the delay exists in an unmodified static term.

I could see SE forcing a 1 packet cycle delay onto every ranged attack (as a static addition) because they don't want to send the start and finish packets in the same UDP packet.
Offline
By Verda 2017-02-13 13:58:29  
I didn't get 1.8 from his data

Verda said: »
Lets add in some things we know.
Delay = Reload Delay + (Weapon Delay/114) * A + B
Delay = 1 + (600/114) * .195 + B = 2.0263
This would make B, which is probably your network delay or packet scheduling delay or some combination of them = .562 or about 256ms ping, round trip which seems reasonable. It's also a bit over half of the packet scheduling delay of .4 seconds so also seems reasonable.

I get reload + .562, and I don't really like counting reload since the delay divisor is more favorable on ranged attack vs melee specifically because there is a reload delay. I actually wouldn't be surprised if on the server the delay divisor is 120, but 114 is about what I measure on my tests above. It shifts though with the delay of each weapon as well as how much snapshot you have. Both of these indicate there's packet/network delay added on. If it was 120, vs the 60 of melee, the result is the 1 second of reload delay is calculated into your tp gain as if you were doing damage during that time.

Ex: (Edited this part)
Delay divisor for melee with 600 Delay weapon = 600/60 swing every 10 seconds
Delay divisor for ranged with 600 delay weapon = 600/120 shoot every 5 seconds, with 1 second of reload delay added on to the shot = 6 seconds

Tl;dr it's not 1.8
 Lakshmi.Byrth
VIP
Offline
サーバ: Lakshmi
Game: FFXI
user: Byrthnoth
Posts: 6137
By Lakshmi.Byrth 2017-02-13 14:21:05  
Where did your numbers come from, though? 2.0263 appears for the first time in your post.

If you just look at his data, y = 1.8 seconds when x = 0 delay.
 Leviathan.Comeatmebro
Offline
サーバ: Leviathan
Game: FFXI
user: Rairin
Posts: 6052
By Leviathan.Comeatmebro 2017-02-13 14:34:23  
If he's clocking average from one shot start to next start as he said, network delay shouldn't really be a factor(roughly the same will be added to each shot start). As he was using my method(inject a ranged action on every outgoing UDP), the only overhead will be how long it takes from server allowing next shot until an incoming requests it(0-400ms).
Offline
By Verda 2017-02-13 15:25:43  
Lakshmi.Byrth said: »
Where did your numbers come from, though? 2.0263 appears for the first time in your post.

If you just look at his data, y = 1.8 seconds when x = 0 delay.
From snaps data:
Shigeto Bow 600 2.588359

The useful information to me is knowing how much of the delay is in each category. We know reload is 1 second. We know delay reduction minus rapid shot procs is going to be .3 * .65 = .195. We are trying to find how much packet/network delay was added to each shot, though not having the network delay recorded at the time of the test makes this hard. Doing each category you get:
reload: 1 second
aiming delay: 1.0263 seconds
this accounts for 2.0263 = 1 + 1.0263
packets delay: 2.588359 - 2.0263 = .562

That leaves about .562 seconds for packets/noise/network delay. Which seems high compared to what I typically notice which makes me wonder how his net connection was at the time of the test.

Leviathan.Comeatmebro said: »
If he's clocking average from one shot start to next start as he said, network delay shouldn't really be a factor(roughly the same will be added to each shot start). As he was using my method(inject a ranged action on every outgoing UDP), the only overhead will be how long it takes from server allowing next shot until an incoming requests it(0-400ms).

Model is this yes?
(1) Client Starts Shot => (2) Packet Travels To Server => (3) Packet Arrives to Server => (4) Packet is scheduled for ranged end => (5) Packet is sent to client => (6) Packet travels to Client => (7) Packet arrives at client => (8) Client is allowed to send packet to start new shot, 1 second after ranged_end arrives.

If we assume from your model of testing, you can eliminate (2) by bombarding the server with packets, (6) will still add delay from network delay. If we don't, then both (2) and (6) will add network delay to the shot time. This leaves:
(2) possibly adds delay
(4) definitely adds delay
(6) definitely adds delay

For (4) the average should be 200ms.
for (2) and (6), the average should be equatable to your entire network delay to the server.

This would make (4) + (2) + (6) added to every shot, or (4) + (6) using your method. But (2) would even with your method have to add the average of udp packet intervals / 2.

What I'm interested in, is the values for (2), (4) and (6) vs. the values for Effective Aiming Delay + Reload Delay. We know for a fact, in laggy zones, your DPS goes down, so there's no way I see for network delay = 0.

If we assume 200ms for (6) then (2) + (6) would have to be .562 - .2 = .362
.362 / 2 = .181
So network delay would've added 181 ms in (2) and (6), which is in the bounds of ping tests I've done. This could be revised with also including rapid shot, but I was never given the rapid shot value.
 Leviathan.Comeatmebro
Offline
サーバ: Leviathan
Game: FFXI
user: Rairin
Posts: 6052
By Leviathan.Comeatmebro 2017-02-13 15:38:27  
you're making it more complicated than it needs to be, as usual

server is receiving a ranged start packet every UDP communication, so the only time between constant shooting is the 0-400ms from when server is ready to start next shot until the next communication arrives

for example, let's say 250ms network delay, 2300ms minimum time between shots:

0 - Time server sends shot A start packet
250 - Time shot A start packet received by client
2300 - Time server will allow shot B to be readied
2300-2700 - Time first ranged packet is received by server after shot B is allowed to be readied, causing server to send shot B start packet
2300-2700 + 250 - Time shot B start packet received by client

(2300-2700 + X) - (0 + X) = 2300-2700

no matter what network delay is, time between shots can be represented as:
actual time server requires for shot fire and reload delay + 0-400ms

you might see slight variations if your ping is shooting up and down from shot to shot, but it'd be almost impossible to account for that and it could go either way so it should average out to essentially 0
Offline
By Verda 2017-02-13 15:52:57  
You're over simplifying things without explaining much as usual. Two can be snarky :D

Leviathan.Comeatmebro said: »
packet every UDP communication
What's the interval of this? If the interval is the same as the server packet interval, then you'd add it in as you did on the server side, either way it can't be zero. There could be a receiving packet scheduling too, or a queue that is processed on the same heartbeat as packets scheduled to go out, and this could be made worse if it ignores packets that it didn't expect to be in that queue. I get staggering it as you listed, though the interval network delay, there is network offset and any late shots or perhaps even going between ws and tp phase could introduce it again.
First Page 2 3 4