Item Search
     
BG-Wiki Search
+ Reply to Thread
Page 5 of 6 FirstFirst ... 3 4 5 6 LastLast
Results 81 to 100 of 102
  1. #81
    Ridill
    Join Date
    Apr 2011
    Posts
    23,736
    BG Level
    10
    FFXI Server
    Bahamut

    Quote Originally Posted by Classikmage View Post
    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%.
    af3+2 is listed as 5% and aurore is listed as +5. Hence my question about is +1 snapshot actually 2% like how the merits are. I'm fairly certain I remember reading as such and if you notice Iuitl Wristbands was tested at 10% but Iuitl Wristbands+1 have snapshot +5. Seeing as it's doubtful +1 would have less stands to reason +1 snapshot is +2%

    Actually just noticed it doesn't even say +5 just "snapshot"5 weird typo I guess?

  2. #82
    CoP Dynamis
    Join Date
    Mar 2013
    Posts
    275
    BG Level
    4
    FFXI Server
    Odin

    Quote Originally Posted by dasva View Post
    af3+2 is listed as 5% and aurore is listed as +5. Hence my question about is +1 snapshot actually 2% like how the merits are. I'm fairly certain I remember reading as such and if you notice Iuitl Wristbands was tested at 10% but Iuitl Wristbands+1 have snapshot +5. Seeing as it's doubtful +1 would have less stands to reason +1 snapshot is +2%

    Actually just noticed it doesn't even say +5 just "snapshot"5 weird typo I guess?
    what's the easiest way to test this? is there something I can use to time the delay in a shot?

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

    Not sure if there is an easy way that is accurate. iirc byrth's tests kinda showed old easy ones weren't that great. If you look at the first page he describes what he did

  4. #84
    CoP Dynamis
    Join Date
    Mar 2013
    Posts
    275
    BG Level
    4
    FFXI Server
    Odin

    snapshot testings sounds horrendous haha. it's especially hard testing pieces that can only be worn by jobs at levels which they'll have rapid shot already, Orz. (a.k.a. Mirador Trousers +1).

    how reliable would it be if say, I use a naked RNG/COR, shoot for an hour or two, then equip mirador trousers +1, shoot for another hour or two, then compare the DPS output? this is done with some kind of RA spamming script of course.

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

    Doubt it would be that accurate between the other stats possibly changing dmg not to mention distance/pdif adding another variable and variable time to get new mob. Probably better off counting shots/time period on something you can't kill/wont kill you. Wouldn't be perfect and probably couldn't just flat out say the snapshot from that but could probably get a decent average speed to be able to compare it to other pieces you might have to see if it's more/less. If you can't do the goldfish thing you could probably do pvp... or maybe some of the various soa terrain enfeeble things. They take reduced dmg and last a decent bit so if you lower your dmg some should be able to get a bit of time on one.

  6. #86
    CoP Dynamis
    Join Date
    Jun 2010
    Posts
    252
    BG Level
    4
    FFXI Server
    Siren

    So I wanted to confirm the delay reduction cap since Square Enix allegedly claims that the cap is 70% as opposed to the 80% listed on the wiki. I don't have a lot of gear for RNG since it had been on hiatus but I wanted to bring it back and wanted to confirm this cap. This test wasn't super extensive but I received some troubling results.

    Spoiler: show
    I used the following gear: Sylvan gapette +2 (+5%), unaugmented Iuitl Wristbands +1 (5%), Sylvan Caban +2 (allegedly makes Velocity Shot a 20% reduction), Lutian Cape (+3% augmented), Impulse Belt (3%), and Taeon Boots (+5% augmented). I used Relic Gun (w/ Bronze Bullets) since its high delay makes it easy to compare delay reduction results. I also have max Snapshot merits. I figured with merits, gear, enhanced Velocity Shot, and Flurry II, I could reach 80% Snapshot and I could compare measured delay at 71% Snapshot.

    I equipped one piece at a time to confirm their listed values (factoring in my merits) and they all fell within a reasonable range of (999/120) * (1 - Snapshot) + .4 seconds. I did this all without Velocity Shot (excluding Sylvan Caban). I also used trust Koru-Moru and confirmed a value of 30% Snapshot from Flurry II. So I proceeded to combine all of these pieces.

    The theory wasn't matching up with the experiment. I tried isolating what was causing the error and could only really come up with the Sylvan Caban. With head/hands/feet/waist/back/merits, I have a combined total of 31%, so a theoretical delay of (999/120) * (1 - .31) = 5.744 sec. I had an actual average delay of 6.148 sec (discarding obvious rapid shot data), and 6.148 - .4 = 5.748 which is pretty much exactly what you would expect. I added Flurry II (total 61% snapshot), and I had a maximum of 3.431 sec which falls within reason.

    However, when I add Sylvan Caban +2 and pop Velocity Shot on top of that, I recorded a maximum value of about 2.977 (I only did about 30 shots but most of them were around ~3 seconds). At 80% reduction, you would expect the delay to be about 1.665 sec, which clearly was not even close. I thought maybe the recorded value of the Sylvan Caban was wrong, but with just Caban, V Shot, and merits I got an average of about 5.825 sec, which isn't too unreasonable for a 20% reduction factoring in a .4 sec error.


    To conclude the test, I used Overkill to see if I could figure out the minimum delay via that. Assuming Overkill is truly Snapshot and doesn't just fraction the final delay further, I think the delay cap is probably 80% after all. I had everything above equipped/on and used it, recorded all of my shots in that 30 sec, and got an average value of 1.653 sec, and 1 - 1.653/(999/120) = 80.1%

    Can anyone really make sense of the Sylvan Caban thing though? I was going to try and upgrade it and see what happened. I was thinking it may not be in the same term as other Snapshot gear and may be multiplicative, but Byrth already debunked that.

  7. #87
    BG Content
    Join Date
    Jul 2007
    Posts
    21,104
    BG Level
    10
    FFXI Server
    Lakshmi
    Blog Entries
    1

    http://www.bluegartr.com/threads/116...=1#post5826122

    I actually raised the possibility that Velocity shot was multiplicative with Snapshot, but never followed up on it. Because the Caban is just enhancing velocity shot (iirc) that could explain your difference.

  8. #88
    CoP Dynamis
    Join Date
    Jun 2010
    Posts
    252
    BG Level
    4
    FFXI Server
    Siren

    The wiki lists the total delay reduction from Velocity Shot after the Caban enhancement as 20%. When I tested Vshot/Caban without any other sources of Snapshot, my results seemed to agree with that. It wasn't until I started stacking additional Snapshot gear that things didn't add up. I had 61% in buffs/gear/merits, and if Velocity Shot is multiplicative we would expect (999/120)*(1-.61)*(1-.2) = 2.5974. Add an additional .4 seconds and you're at 2.997, pretty close to my maximum value of 2.977. So, it could be multiplicative, I'll do some more testing.

    It's also suggested that Overkill may be a separate term with Snapshot. So while overall ranged delay reduction may be 80%, reduction due to Snapshot may still cap at 70%. I need to gather some more gear to reach the delay reduction range of 70%-80% through Snapshot/Flurry alone to confirm this.

  9. #89
    Melee Summoner
    Join Date
    Aug 2010
    Posts
    26
    BG Level
    1
    FFXI Server
    Bahamut

    I have some flurry testing since no one ever knew what it was that I knew of and it was never on the wikis and SE never told us. I used my own method (though probably others here did too) of using the windower lua library and lua sockets library to time when a packet comes in, there is one for when a ranged attack begins and one for when it ends. I then did a sample size of about 40 for each one, no flurry or snapshot, flurry 1, and flurry 2. I did this on THF instead of ranger to avoid having to worry bout getting much much bigger sample sizes to know what is going on due to rapid shot procs. I disabled all equipsets and gearswapping to eliminated variables.

    Here are the results:
    Flurry 2:
    1982.5040967987804000
    STD 189.00881267542783

    Flurry 1:
    2185.4365831163195000
    STD 184.15103718840558

    No Flurry:
    2469.3563988095240000
    STD 195.12986426281986

    What I can infer:
    Flurry 1: 11.4977% 120/1024 since 120 divisible by 8 and that's how these values tend to work is a good guess
    Flurry 2: 19.7158% 200/1024 since 200 divisible by 8 also

    This sample size isn't enough to say for certain but if it's 120/1024 and 200/1024:
    Flurry 1: 11.71875%
    Flurry 2: 19.53125%

    It's at least an improvement over having no idea, it seems odd it's less than haste and haste 2, but then again supposedly the cap (SE told us) for snapshot is lower (70%) and doesn't cap per category (magical, gear, JA) but all adds in.
    For the tech inclined I have the data here, in SQL format enjoy. mediafire.com/?alg52zyl3gbvznd

    I actually need to know this to optimize gear for ranger... it would be easier if SE publishes this but I think they enjoy us trying to figure the game out. If snapshot is capped, rapidshot gives you more gain since snapshot will do nothing. Without knowing when you are capped snapshot, you cannot know when it is better to equip rapid shot and when it is not. Testing showed that rapid shot will improve if snapshot is capped, but that wasn't done by me. It would be worth retesting though. But I would think it weird on SE's part to make things like adhemar legs and carmine hands that have loads of both snapshot and rapidshot with right path, if they didn't both do something. Supposedly the delay reduction of rapid shot is a random value, and I've seen both 80% and 95% and values in between proposed, in any case it's higher than 70% and a test did confirm done by Byrth i believe that if rapid shot is more delay reduction it takes that value instead.

    To anyone who doesn't like the word packet, most of this uses the same thing the damage parsers use, just far less of it, and they have been in use in ffxi for years. So I hope we can all use this information to better our understanding of ranged jobs, which have been not used at all for content since the enmity changes that I've seen. I have more tests to do namely:
    * Gather a large sample size with no snapshot or flurry, to test the theory of artifacts in the packet resolution of .4 seconds that others have proposed.
    * Use this base data and gather a large sample size for ranger with rapid shot to compare against, showing categories if any that rapid shot falls into, using a very high delay weapon and ammo combination.
    * Use that base data for ranger with a large sample size of velocity shot. Then use that data as base to compare with velocity shot with AF3 body.
    * Determine if magical snapshot and gear snapshot and velocity delay reduction are additive or if any have diminishing returns when used with each other (multiplicative).
    * Use that knowledge to determine if the snapshot cap really is capping at 70% from all sources as SE said.

    If any of you wizened testers believe any of that is unnecessary, please save me the trouble, thank you very much.

  10. #90
    New Spam Forum
    Join Date
    Sep 2014
    Posts
    181
    BG Level
    3

    You don't post what your numbers mean, are they milliseconds? If so, consider that packet delay will alter your ratios. Mean wait for packet is a flat value added to everything and not reduced by snapshot/rapid shot. This means that your percentages will always come out low without a good approximation of it. If you remove 200ms from each timer, the numbers come out much closer to what we expect. Furthermore, if you're using a weapon with only 2.4 seconds of delay, you're going to have a much lower precision than a slower weapon. These tests should probably be conducted using a relic bow on SAM, if you want to avoid rapid shot.

    Sorry to kind of shit on your data set, but without more information about your method I have to go on what I can infer from the numbers. If you plan to do further testing, strongly consider accounting for potential packet delay(a good way to do this would be to take the arithmetic mean over a few hundred shots using the same snapshot and subtract the lowest value seen over those shots) and using a higher delay weapon.

  11. #91
    BG Content
    Join Date
    Jul 2007
    Posts
    21,104
    BG Level
    10
    FFXI Server
    Lakshmi
    Blog Entries
    1

    Good point. I get 170ms latency (ping 202.67.54.124), which would be doubled in practice because my packet has to go there and their packet has to come back. Thus I should probably be subtracting about 340ms from my numbers.

    Edit: Nevermind, actually the delay is irrelevant because the addon calculates the difference between the ranged "readies" packet and the ranged result packet. Thus the same delay is baked in to both sides.

  12. #92
    New Spam Forum
    Join Date
    Sep 2014
    Posts
    181
    BG Level
    3

    The delay is still relevant because the server isn't completing the actions at the exact times the packet is sent. While both may be delayed, measuring the average additional overhead past the fastest will show how much effective delay is being added by it. If it is an even distribution as expected, it'd still give you the baseline packet interval you're working with more accurately than ~340ms.

  13. #93
    Melee Summoner
    Join Date
    Aug 2010
    Posts
    26
    BG Level
    1
    FFXI Server
    Bahamut

    Yes it is milliseconds. And my addon is really similar to Byrths and I would've just used his to be honest if I had read this thread before I started testing :D

    To math out lolwutt's statement and see if it holds up or not, lets make a model with easy numbers.

    Say you have a packet sent out. It then goes through networks and comes back to you with 100ms delay and you get the ranged_begin packet and your timer starts, tic toc. The server, not the client, should be the one then telling you when the ranged attack ends. So on their end, they will send out a packet to you for ranged_end, probably not adjusting at all for that 100ms delay you got because that would be silly. Network delay is not constant however over enough samples you should get a good average, what we are focused on is the interval here. To demonstrate more:

    the interval between 0 and 100 is 100, and the interval between say adding in the delay to both sides is 100 and 200 and the interval is thus still 100. So as Byrth has done prior, and as I am doing here, the interval is preserved assuming the network delay is added to both ends, so Byrth and my testing is right.

    The delay on Tsoabichi crossbow is 288, which according to the wiki 288/106 is 2.71 seconds but my tests are showing an average of 2.469, but they are withing 2 standard deviations of my data set so we could chaulk that up to a lower sample size. I can also double check all my gear to ensure there's nothing else, but I went over it 3 times to ensure no snapshot or rapidshot was on, and should probably shoot naked with -fSTR like byrth did.

    To clarify Lolwutt you're saying that the server isn't completing actions at the time it's sent, I think that's true, but what we are measuring isn't the time since the packet is sent to the time we get an incoming message that the shot finishes. We are measuring the time since the server tells us that our ranged shot begins, till the time the server tells us the ranged shot ends. So comparing two incoming packets rather than an outgoing to incoming, which would eliminate alot of the difficulty you describe I think, if you have more to add though or I didn't understand you correctly, please give more feedback it's important the tests are accurate. Edit: Also I think using huge delay weapons is the better way to go, but using any should tell us something

  14. #94
    BG Content
    Join Date
    Jul 2007
    Posts
    21,104
    BG Level
    10
    FFXI Server
    Lakshmi
    Blog Entries
    1

    I've always assumed it works like this and don't have a viable alternative model:

    ts1 = Server decides you've started shooting and cues a "readies" packet for your client
    ts2 = Server decides you've shot and cues a "shot" packet for your client
    TTS = Time to shoot = ts2 - ts1
    latency = Time between SE's server and your computer
    discretize() = SE sends UDP packets every 400-500ms with as many chunks from the cue as they can fit, so there's some discretization that goes on here in the time domain.


    Time1 = Time the readies packet arrives at your computer = discretize(ts1) + latency
    Time2 = Time the shot packet arrives at your computer = discretize(ts2) + latency


    Time2 - Time1 = discretize(ts2) - discretize(ts1)


    If this is how it works, just averaging your Time2-Time1 (as the poster did) would remove the latency and negate the discretization function. It's true, however, that using a longer latency weapon would get him a more accurate measurement.

  15. #95
    Melee Summoner
    Join Date
    Aug 2010
    Posts
    26
    BG Level
    1
    FFXI Server
    Bahamut

    I guess I'll have to get a Smith to make me a Culverin if one doesn't show up on the AH soon, and an Alchemist for the bullets since the Curio moogle doesn't carry the bullets :/ and I'll test with that, thanks guys.

  16. #96
    New Spam Forum
    Join Date
    Sep 2014
    Posts
    181
    BG Level
    3

    Before you go out and make a culverin, note that you can only fire cannon shells with it, other bullets won't work. Better off using relic bow on SAM if possible. Wasn't thinking about the packet for start also being discretized, so that does make sense.. if the interval is variable it could still require a very large sample size before your margins of error are low enough to be certain though, at least with that fast of a weapon. If your outgoing chunks timing is based on incoming chunks timing or vice versa, it's also possible that without zoning you won't have anything near an even distribution.

    This is problematic if say, a 2000 ms shot with 350ms incoming packet interval:

    0.00 - outgoing
    0.70 - outgoing received, shot started on server
    1.00 - shot start packet received(300ms late)
    2.7 - shot finished on server
    2.75 - next return packet after shot finished(50ms late)

    If ping is relatively constant and outgoing timing is based on incoming timing, you could be maintaining that -250ms bias for quite a while.

  17. #97
    BG Content
    Join Date
    Jul 2007
    Posts
    21,104
    BG Level
    10
    FFXI Server
    Lakshmi
    Blog Entries
    1

    Yeah, it would probably make sense to add a random factor to your delay between shots to avoid accidentally syncing with the server.

  18. #98
    New Spam Forum
    Join Date
    Sep 2014
    Posts
    181
    BG Level
    3

    Even adding a random factor to your delay may not be enough if the time distance between an outgoing packet and the following incoming packet(or vice versa) remains relatively constant.

  19. #99
    BG Content
    Join Date
    Jul 2007
    Posts
    21,104
    BG Level
    10
    FFXI Server
    Lakshmi
    Blog Entries
    1

    yeah, true. Might have to try in a few different zones to make sure that's not a factor.

  20. #100
    Melee Summoner
    Join Date
    Aug 2010
    Posts
    26
    BG Level
    1
    FFXI Server
    Bahamut

    I don't have SAM leveled beyond a subjob, and we have Relic Gun testing from byrth already so I think I'm going to go ahead with Culverin, and yes I know it takes special ammunition, but we might learn something from it, I get nervous thinking all data tests are done on relic weapons that are 999 delay, what if all the relic delays are special case? I think we might learn something using Culverin instead.

    Quote Originally Posted by Lolwutt View Post
    0.00 - outgoing
    0.70 - outgoing received, shot started on server
    1.00 - shot start packet received(300ms late)
    2.7 - shot finished on server
    2.75 - next return packet after shot finished(50ms late)

    If ping is relatively constant and outgoing timing is based on incoming timing, you could be maintaining that -250ms bias for quite a while.

    For the purpose of testing though all that would matter is this part:
    1) ??? - server sends out packet to start shot
    2) 1.00 - shot start packet received (Timer starts, doesn't matter how long it took we got it though, the client will only start shooting when you get this packet)
    3) 2.7 - shot finished on server, sends out packet
    4) 2.75 - next return packet after shot finished (Timer ends, with server taking on average the same time to reach us every time)

    How long the outgoing packet to tell the server we wish to start a ranged shot takes to get to the server won't matter in this case at all unless I am missing something. What we can count on is networks aren't static in their latency, there's latency spikes etc but those should be outliers and easily identifiable visually even with a scatterplot. Then there's the small discrepancies, usually within 0ms of each other on my network at least to google but the further it travels the more I imagine this is an issue, but with enough samples and taking a look at standard deviation matching up with network volatility I think we could make fair assumptions based on averages. Unless I'm missing something like the client also requests a shot ended packet from the server, that's what makes sense to me. Even if it did that however... you'd have the same delays in both, on average. It's not a bad idea to test in multiple zones for sure, testing is about eliminating variables but either I still don't' get what you're trying to communicate or one or both of us doesn't have a clear understanding of it's workings. The time between steps 1 and 2 due to network latency should equal the time between steps 3 and 4 on average, no matter how the outgoing packet works because it never enters into the timing, correct?

    This would give us a consistent interval to measure, subtract the timer from step 4 - the timer from step 2 and you get the true interval we seek, on average, to make it mathy:
    t1 = step 2 time
    t2 = step 4 time
    r = average random network latency variance
    r2 = artifacts from the .4 second resolution of the server sending out packets

    (t2 + r +/- r2) - (t1 +r +/- r2)
    simpliefies to
    t2 + r +/- r2 - t1 - r +/- r2
    simplifies to:
    t2 - t1
    if r2 is evenly distributed between + and -

    with the artifacts from r2 being the real true problem because it could pose biases of up to .4 seconds. However, if I did as byrth suggested and put random delays into my between shots, it would randomize any syncing to the server and over enough samples we could see the image of what is going on despite the bad resolution of packets. If the server never sends early upcoming events (which it probably doesn't tbh) then r2 would only be a +, which though, would skew things a bit toward longer delays, this is something that we'd need to understand too, but would still have equal chance of happening on both sides of the timer so we could still get accurate intervals because r2s would subtract from each other to create 0.