Forum Settings
       
Reply To Thread

Epona's on WSsFollow

#52 May 04 2011 at 4:18 PM Rating: Excellent
***
2,236 posts
Quote:
How do I quote the parse data like pchan did?


For the tab you want to copy, have that tab up and go to the Edit menu and pick Copy as BBCode. You can then paste that directly into your post.

Note that Alla uses a bad font for preformatted text (which I've disabled via Stylish) that doesn't have the same character width when bold as its non-bold version, ******** up the alignment. You may wish to delete the B tags to clean that up, if you're feeling picky.


Getting that into matlab certainly makes it easier to do the longer analysis, though my suggestion was simply to analyze the first 6-9 minutes of the data. If SD does indeed fall off without renewal, then averaging the first few minutes in with all the other intervals wipes out any possible indication of that.

As for the overall graph, I'd suggest getting ((timestamp-offset)/60) % 3) for your x coordinate to group into 1-minute blocks, and then getting the mean, count and std dev for each of those blocks.

#53 May 04 2011 at 4:39 PM Rating: Decent
**
983 posts
Oh, I did the check for that already and it doesn't seem to be the case (6 DAs in the first three minutes, 10 DAs in the second three minutes). It's difficult to say conclusively though, because I only attack about 10 times per minute.

Edit: I'll add that the only reason we believe Saber Dance works on 1 minute windows is because of a wiki post ages ago. Every other piece of information that post provided was shown to be wrong, so I guess I was just clinging onto the 1 minute window idea for simplicity's sake.

If you remove that as an assumption and look at the unsmoothed data (and accept that I was "using Saber Dance" just before the end of the graph), it looks like it starts around 50% and decays by about 5% per swing to a floor of around 15% (8 steps to the floor), similar to the way Fan Dance works (100%->20%, 8 steps to the floor). I am going to try and feed Saber Dance activation timestamps from my log to the program and see if I can align to them and simply look at probability per round after that, but a friend just proposed so I need to go out for drinks first!

Edited, May 4th 2011 6:56pm by Byrthnoth

Edited, May 4th 2011 7:02pm by Byrthnoth
____________________________
Yay for Jhereg!
http://www.ffxiah.com/player/Lakshmi/Byrth
#54 May 04 2011 at 7:00 PM Rating: Good
**
415 posts
I'm going to assume that the DA rate is linearly decreasing between 0 and 5 minutes. Without going into the math it's quite obvious that

* If you use saber dance every 5 minutes you average DA rate is 1/2 of it's inital value ( which I will call DA)
* If it overwrites itself then the DA rate is periodic over time and lineraly decresing from DA to 3/5 DA every 3 minutes so It averages to 4/5 DA.

So If saber dance overwrites itself 4/5 DA= 18.65 +/- 1.16 => 21.86% < DA < 24.76%

* If saber dance doesn't overwrite itself the da rate is still periodic : linearily decreasing from 0 to 5 minutes between DA and 0, and 0 between 5 and 6 minutes, and the average DA rate would be DA*5/12 (which is the average of the above function on its period).

In this case DA*5/12= 18.65 +/- 1.16 => 41.97% < DA < 47.54%

Before going any further, was your latest test done with zero DA gear ? If so it kinda shows that samba overwrites itself ( 50% initial DA would be noticable lol). To know accurately the initial DA value you just have to use saber dance every 5' instead of 3' and multiply the DA on the parse by 2.

Edited, May 4th 2011 9:01pm by lynnminmay

Edited, May 4th 2011 9:03pm by lynnminmay
#55 May 04 2011 at 8:26 PM Rating: Decent
**
983 posts
It seems that DA probably does decrease with Saber Dance, and probably linear (piecewise). I extracted Saber Dance timestamps in matlab and used them to separate on a first-swing, second-swing, etc. basis. This is what I came up with:
Picture

Now! The weird part is that I also went back and verified where I used Saber Dance on the previous graphs. It was 4 seconds before my first swing (the offset), so the 50% spike is probably real. I don't know if SE messed up the timescale or what, but it looks like it decays very very quickly (within the first 5-8 hits) to 15% where it pretty much stays.

I'm just leaving my parse to run overnight. If I remember stats correctly, doubling sample size decreases variance by root(2), but it's something. The current data set I'm running on is 7.5 hours, so 10 more hours should be worthwhile.

PS. Oh yeah, I was wearing 0 DA gear for the most recent data/graphs. Sorry. I'm a few drinks heavier.

PPS. I'm so ******* This **** looks like biological data. Why the **** do I play a game if I have to deal with the same ******** as at work? ANGRYFACE.

Edited, May 4th 2011 10:32pm by Byrthnoth
____________________________
Yay for Jhereg!
http://www.ffxiah.com/player/Lakshmi/Byrth
#56 May 05 2011 at 6:58 AM Rating: Decent
**
983 posts
Okay, aggregate statistics:

Box step: (62.67% Land rate +/- 1.32%)
used - 5192 times
Landed - 3254 times

Hit rate: (58.60% Hit rate +/- 0.73%)
Hits - 10138
Misses - 7162

Crits - 1353 (13.35% +/- 0.66%)
Extra attacks - 2652 (18.10% +/- 0.62%)

I realize that it would be better for me to have used a higher or lower Hit rate in terms of statistical power, but I was hoping to turn this into a test of "Enhances Step Accuracy" potency (3 different items) so I was saving my statistical power-ups for there. I'd always assumed there was an innate hit rate penalty on steps though, so I'm not sure how much I actually care about the potency of these items anymore. I might test Feather Step's crit rate boost first/at the same time.

I will get an Acerbic Sash and make myself a Lady Bell for my next tests, I think, as it should speed up data collection dramatically.

Edit: Oh yes, all of these tests were done on the same Hpmede (>315 DEF, so I assumed highest level).

Edit2: Less variance in Saber Dance use times this time. The unsmoothed version looks pretty striking <_<

What worries me more than anything else is that the spike decays over about 10 seconds. The highest point in the spike are oddities (low count, 1 and 5 for the first two points), but the rest are pretty high sample size.

So theories for how Saber Dance might work:
1) DA rate decays in 1 minute windows. - Not supported by the data
2) DA rate decays a lot faster than that (~10 seconds) - Somewhat supported by the most recent data.
3) DA rate decays with every swing, regardless of whether DA procs - Doesn't appear to, but maybe confounded by overlapping attack rounds
4) DA rate decays whenever a DA procs - Haven't even written the code for this yet.

Edit3, question for Kinematics:
Minor issue, but KParser determines groupings of attacks for the "Extra attacks" analysis and provides the average attack time for each group, correct? It seems much more likely to me that (if it were using a DA rate decaying with time) the DA rate would be determined slightly previous to the first attack of each round. Using the average round pushes back the timestamp and makes weird things like the 2 point in the unsmoothed graph above. Is there a way to do this without writing a grouping algorithm myself?

Edit4: I prefer this version
I aligned it to Saber Dance onset, but it's still relative to time. It is difficult for me to tell the difference between a fast decaying mechanism and one of the other options above, because they all come out looking about the same due to my relatively constant attack speed. When I make a Lady Bell and run the test I should know for sure.

Edit5: Summing everything after "50" where it looks like the crit rate has gone to baseline gives a crit rate of 16.75%. An odd number to be sure. Close to 1/6, but otherwise unremarkable!

Edited, May 5th 2011 10:45am by Byrthnoth
____________________________
Yay for Jhereg!
http://www.ffxiah.com/player/Lakshmi/Byrth
#57 May 05 2011 at 10:06 AM Rating: Excellent
***
2,236 posts
Quote:
Minor issue, but KParser determines groupings of attacks for the "Extra attacks" analysis and provides the average attack time for each group, correct?


The timestamp KParser gives each group is the time of the first attack in each group. All other attacks are considered to have 'actually' occurred at that point, but the messages show up later.

Quote:
Is there a way to do this without writing a grouping algorithm myself?


I'm not entirely sure what you're asking for, but I -think- KParser is doing roughly what you want.

Quote:
I aligned it to Saber Dance onset, but it's still relative to time. It is difficult for me to tell the difference between a fast decaying mechanism and one of the other options above, because they all come out looking about the same due to my relatively constant attack speed. When I make a Lady Bell and run the test I should know for sure.


At the moment it's looking like it behaves much more like Fan Dance, which decays per hit you take. From your data, I'm inclined to believe that Saber Dance decays either per DA or per hit you land. If the Lady Bell test takes longer to decay then I would believe it decays per hit; otherwise, decay per DA.

Quote:
Edit5: Summing everything after "50" where it looks like the crit rate has gone to baseline gives a crit rate of 16.75%. An odd number to be sure. Close to 1/6, but otherwise unremarkable!


You mean DA rate, right? :)


As a side note, I'm running my own confirmation of the DA/TA test. Unfortunately the results are looking rather problematic, and I'm restarting the test (noticed I'd had a torrent running, which could conceivably have caused lag spikes that messed up the results, even though it usually doesn't).

Setup: thf/whm, 13% DA (Brutal+Atheling+Pole+Epona), 13% TA (trait+merits+Epona)

Parse results:
6121 rounds, 792 DA (12.94 %), 471 TA (7.69 %)

So.. yeah.
#58 May 05 2011 at 10:44 AM Rating: Decent
**
983 posts
Kinematics wrote:
The timestamp KParser gives each group is the time of the first attack in each group. All other attacks are considered to have 'actually' occurred at that point, but the messages show up later.


Okay, that answers everything. I must have just looked at a strange case, or everything is offset.

"Kinematics" wrote:
Quote:
Edit5: Summing everything after "50" where it looks like the crit rate has gone to baseline gives a crit rate of 16.75%. An odd number to be sure. Close to 1/6, but otherwise unremarkable!


You mean DA rate, right? :)


Yep, sorry.

"Kinematics" wrote:
As a side note, I'm running my own confirmation of the DA/TA test. Unfortunately the results are looking rather problematic, and I'm restarting the test (noticed I'd had a torrent running, which could conceivably have caused lag spikes that messed up the results, even though it usually doesn't).

Setup: thf/whm, 13% DA (Brutal+Atheling+Pole+Epona), 13% TA (trait+merits+Epona)

Parse results:
6121 rounds, 792 DA (12.94 %), 471 TA (7.69 %)

So.. yeah.


errr... that's interesting. How would you go about calculating the variances on those? Maybe you can show which type of system it is using the variance? Upon reflection, by the time the variances differ significantly I'd expect the means would also differ significantly.

It's interesting that now we have all the possibilities represented though.
lore - TA is checked first
pchan - Mutually exclusive
kinematics - DA is checked first, kinda

The problem I see with your data is that your TA rate is significantly lower than what you'd predict in the "DA is checked first" case, right?
.87*.13 = .1131
Assuming DA procs before TA (lowering TA sample size), you'd still predict your value to be 7.69% +/- .71%.

Could the parser be splitting TA rounds into a DA and single round? How does your number of rounds compare to the number of hours you spent parsing and your effective delay?

Edited, May 5th 2011 3:43pm by Byrthnoth
____________________________
Yay for Jhereg!
http://www.ffxiah.com/player/Lakshmi/Byrth
#59lynnminmay, Posted: May 05 2011 at 5:17 PM, Rating: Sub-Default, (Expand Post) With 15% DA and 10% TA in gear I was getting 13,38 % DA and 8,31 % TA (this was the first parse I posted), which means I'm getting more TA than you even though I have 3 less TA in gear ... First step is to say that epona is broken, second step is to say what the @#%^. I don't believe the torrent lag to affect anything. I put money on epona's not doing what it says. Kine's data pretty much says "epona's is worse than 5% DA" or "3% TA is worse than 2% DA"... facepalm .
#60 May 05 2011 at 5:41 PM Rating: Excellent
***
2,236 posts
I'm currently looking into the code for the extra attack calculations in KParser. Am hoping I can resolve the issue there, if it's buggy or unreliable.

#61 May 05 2011 at 6:22 PM Rating: Excellent
***
2,236 posts
OK, ran through the code and found that one particular threshold that was under what it needed to be by 0.003 seconds was throwing everything off. Have confirmed results with a couple other test runs, but can't guarantee how it will behave under all conditions/weapons (which isn't any different than before, really). I need to come up with a better algorithm, but it's a real pain to work out.

Anyway, 13%/13% test results:

Melee Data 
 
Player               # Melee Attacks    # Melee Rounds    Attacks/Round    # Extra Attacks 
Motenten                        8072              5900                1               2172 
 
Player               # +1 Rounds   # +2 Rounds   # +3 Rounds   # +4 Rounds    # >+4 Rounds 
Motenten                     628           772             0             0               0 
 
Player               # MultiAttack Rounds    MultiAttack %     Kills w/Min Attacks    Kills w/<Min Attacks 
Motenten                             1400          23.73 %                       0                       0 
 
 
Treat As: 
 
Multi-attacks per attack (2x/3x): 
 
Player               # Double Attacks    DA Rate    Perc. DA     # Triple Attacks    TA Rate    Perc. TA 
Motenten                          628    10.64 %     44.86 %                  772    13.08 %     55.14 %


DA: 10.64% +/- 0.79% => 9.85% - 11.43%
Predicted: 11.31%

TA: 13.08% +/- 0.86% => 12.22% - 13.94%
Predicted: 13% or 11.31%

Total multi-attack: 1400/5900 = 23.73% +/- 1.09% => 22.64% - 24.82%
Predicted: 22.61% (xor) or 24.31% (priority)


This re-validates the December test data that indicated that TA had priority over DA, and implies lynn's data is incorrect.

I'll upload a new version of KParser so that you can check the parse with the corrected threshold value (does not need to be re-parsed). If the results are more in line with the expected TA>DA theory then this can be resolved as a bogus reveal based on a flaw in KParser. If it still shows the xor results then further investigation will be necessary.



New version uploaded. Installer for 1.5.12a is in the downloads section.

Edited, May 5th 2011 7:33pm by Kinematics
#62 May 05 2011 at 7:31 PM Rating: Decent
15 posts
Thanks for testing this yourself Kine. I tried to do a test of my own, but without a THF character to use, the lack of TA options (Only the 3% Epona's gives), I couldn't refute his evidence. I asked Lynn to upload his parse, but never got a reply. I have noticed that KParser consistenly had issues showing DAs as 2 seperate 1 hit rounds, and TAs as either 3 single rounds, or a DA round with a single hit round. Both greatly inflate the Attack rounds shown. I did a parse of about 2500 attack rounds that was in reality 2-300 less. I've been testing the set bonus for Monk Empyrian Armor, and have to look through the extended details, and sync them up with logger for the same reasons of round bleeding, and figured Lynn's parse had this problem. Should these updated threshold values help with h2h parsing issues? It seems it really has problems when double kicks occur, and in general always seems more wonky with h2h than single or 2H weapons.
#63 May 05 2011 at 8:29 PM Rating: Decent
**
983 posts
Okays, how do I apply the new version to my old parses? Just install it and reopen them?

I have a 15 hour parse scheduled to end at 9AM tomorrow, same conditions (0% DA) but with a lady bell and airy buckler. At the moment, switching from Cobra Staff to Lady Bell has pushed the DA rate up to 20%, which makes me think that it's time-related decay instead of something else. I'm collecting data so much faster this way... I'll probably have something conclusive by tomorrow.
____________________________
Yay for Jhereg!
http://www.ffxiah.com/player/Lakshmi/Byrth
#64 May 05 2011 at 8:40 PM Rating: Decent
15 posts
Okay, opened up a few old parses with the new version, seems much better for DA and TA rate estimates. Old parse had DA listed as 126, TA as 2 in 1348 rounds. New has DA 208, TA 47 in 1168 rounds. In reality it should be 207DA, 47TA, in 1177 rounds, so way closer to the actual in your updated KParser. However, H2H got way out of control. I had an old parse that showed:

#+1 Rnds= 158, +2=10, +3=16, +4=21, >+4=5

Now shows as:

#+1 Rnds=45, +2=1, +3=100, +4=33, >+4=25

In actuality it should show:

#+1 Rnds=241, +2=34

Is this just a speed issue, where attack rounds are too fast? or Dual-Wield/H2H related? My attack rounds would be at aprox 206delay, or 103 per fist.



#65 May 05 2011 at 9:44 PM Rating: Excellent
***
2,236 posts
Byrthnoth wrote:
Okays, how do I apply the new version to my old parses? Just install it and reopen them?

I have a 15 hour parse scheduled to end at 9AM tomorrow, same conditions (0% DA) but with a lady bell and airy buckler. At the moment, switching from Cobra Staff to Lady Bell has pushed the DA rate up to 20%, which makes me think that it's time-related decay instead of something else. I'm collecting data so much faster this way... I'll probably have something conclusive by tomorrow.


Yes, install the new version and reopen the old parses. It doesn't change any of the old data, just adjusts how it analyzes it.

If your current parse is already active, you don't have to do anything. Let it run its course, then install the new parser after that to look at the data.

#66 May 05 2011 at 9:57 PM Rating: Excellent
***
2,236 posts
Diasetsu wrote:
Okay, opened up a few old parses with the new version, seems much better for DA and TA rate estimates. Old parse had DA listed as 126, TA as 2 in 1348 rounds. New has DA 208, TA 47 in 1168 rounds. In reality it should be 207DA, 47TA, in 1177 rounds, so way closer to the actual in your updated KParser. However, H2H got way out of control. I had an old parse that showed:

#+1 Rnds= 158, +2=10, +3=16, +4=21, >+4=5

Now shows as:

#+1 Rnds=45, +2=1, +3=100, +4=33, >+4=25

In actuality it should show:

#+1 Rnds=241, +2=34

Is this just a speed issue, where attack rounds are too fast? or Dual-Wield/H2H related? My attack rounds would be at aprox 206delay, or 103 per fist.



It's largely a speed issue. There are a few different heuristics that it uses to determine if a new round has started, but it's also limited by certain thresholds, which are extremely touchy. I need to look into other new ways to determine which hits should be grouped together into a round.

If anyone feels like trying to come up with an idea, a few points:
1) Lines are grabbed at 1/2 second intervals (usually 0.5 seconds, but typically a smidge higher such as 0.501 or some such).
2) The game usually displays successive hits approximately 1 second apart (aside from bursts of attack rounds after a bout of lag), though occasionally they'll be captured 1.5 seconds apart, or slightly higher.
3) From that you can see that a triple attack round will have lines at timepoints 0.0, 1.0 and 2.0 seconds (roughly). A weapon with a delay of 180 (3 seconds) would hit its next round at 3.0 seconds, making it difficult to separate from earlier hits (new round, or quad attack proc?). Effectively the same issue with H2H.
4) I can collect time clusters of the differences in time between each hit, where you can see peaks of the most common times between hits, along with surrounding differences that are nearly the same.
5) I can do a "group by" clustering using adjacent hits with a variety of conditions in order to select into the group. This is not restricted to only 2 adjacent hits.
6) At the moment I'm doing strict thresholding. I'm mainly looking for ideas on a 'fuzzy' thresholding.
#67lynnminmay, Posted: May 06 2011 at 3:28 AM, Rating: Sub-Default, (Expand Post) With the new version : DA15 TA 10
#68 May 06 2011 at 3:53 AM Rating: Decent
**
415 posts
Next time I'll try not to interrupt the parse to check partial data. I added the total fight lengths in seconds of the different "fights" (I paused 5 times) and divided by my delay of 366 (signet staff) x 0.85 (15% haste) /60 and found 8317 rounds for the 15DA/10TA parse, so we are ~300 rounds off. I don't think lag can be the issue since you would DC after 30 sec at most.

Edited, May 6th 2011 5:54am by lynnminmay
#69 May 06 2011 at 3:59 AM Rating: Decent
**
983 posts
It looks like you're largely bound by the game display latency. Your parser just "parses" information from the chat log, correct?

It would be worthless for us here, hitting for 0s like the pros we are, but damage for the whole TA/DA is assigned when the first hit is displayed. You could use the number of times mob HPP changes to determine the number of attack rounds and attack round onset.

In general, I think you're hitting the limit of what's possible. It has been my experience that the times where kparser can't tell whether something was a DA, TA, or 4+ round, I also can't tell looking purely at the log. All the tricky programming techniques in the world aren't going to get around that.

PS. My graphics card decided to throw in the towel last night, so FFXI aborted itself. Still got 8000+ rounds out of it, averaging out to 20.5% DA. It looks like it decays over the same period (about 30 seconds from onset), but . . . it decays to a higher value somehow (~19% instead of ~17%). Theories 3 and 4 would have predicted a lower average rate and all the theories predict an unchanging floor. It looks like DA floor from Saber Dance might depend on Delay?
Either that, or it depends on something that's correlated for each Saber Dance use but decorrelates pretty quickly. I have lower hit rate with lady bell than I did with staff. The most annoying case would be case 4 with the additional stipulation that the DA proc has to land. We shall see!


Edit:
pchan, some people that do a lot of delay testing have proposed that it's actually closer to ~58 delay per second. They were more exact than that, but I can't remember exactly what they said.

Edited, May 6th 2011 6:01am by Byrthnoth
____________________________
Yay for Jhereg!
http://www.ffxiah.com/player/Lakshmi/Byrth
#70lynnminmay, Posted: May 06 2011 at 4:33 AM, Rating: Sub-Default, (Expand Post) Ah well if it's 58 delay the number of rounds seems correct at least which leaves us with another problem : TA rate is too borderline to validate anything. I guess I will run the same tests again with zero% haste and without interruption and I will check that both parse give the same delay.
#71 May 06 2011 at 5:20 AM Rating: Good
*
52 posts
I remember VZX back in old times translated from StudioGobli something like 1sec = 58.75 delay ? (but as usual 0 test data...)

Maybe slightly offtopic, but i discovered very weird parsing of DArate from KParser while testing Ravager set bonus. (33% DA equipped but ~17% observed, decent sample size)

I have also made 5 tests on Fortifications to "verify" KParser's results compared to RAWdata tab imported into Excel => own parsing(+ manual counting) using the timestamps. It shows quite some divergences...
i'm wondering if KParser can use the PC clock instead of timestamps for more precision at parsing multiattacks? Not sure but maybe PC clock has "more" millisecs precision than timestamps limited to :xx ?

I'll post those 5 tests in same issue tag already posted 2 months ago in KParser Issues page.

Edited, May 6th 2011 8:30am by Masamunai
#72 May 06 2011 at 5:28 AM Rating: Decent
**
415 posts
I just thought of this idea for checking the accuracy of the rounds count : I'll parse my self together with my mule on a low level job with a signet staff equipped, while wearing no haste gear. It seems to be a 100% safe way to have the exact value of the average #hits/round since the parse of my char will give the exact number of hits landed while the parse of my mule will give the exact number of rounds (assuming of course that I have them engage at the same time and stop at the same time altough it should resuslt in +/- 2 rounds at worse).
#73 May 06 2011 at 6:38 AM Rating: Decent
**
415 posts
As far as the alogorithm for finding DA and TA rates goes ... Would it not be simpler to only identify the rounds without extra attack (seems simple as they are the majority and they are the rounds with 2 attacks clearly sperated by > 2 sec) ? Then by a delay calculus ( the delay is the majority of the delay between 2 attacks observed, and not the maximum delay, to avoid lag), extrapolate the global amount of rounds (since delay is constant and not a random variable it should be exactly the real number of rounds unless you have 100% extra rate or something dumb).

Call N_1= total number of rounds, N_2= total number of single rounds and N the number of attacks.
If DA is the effective DA rate and TA is the effective TA rate (effective means what you see in the game not in the stats) then
N/N_1= 1+ DA+2*TA
(N_1-N_2)/N_1= DA+TA
Which you can solve easily :
DA=-(N-3*N_1+2*N_2)/N_1 and TA=(-2*N_1+N_2+N)/N_1

I think you will be losing the confident interval though if you don't consider checking the amount of attack per individual round. But at least it gives the exact DA rate and TA rate in your data. (After thinking about it you should actualy be able to find a CI since you know excatly the amount of DA and the amount of TA that occured).

For instance : If I find, with the algorithm,
N_1=10,000 rounds with my algorithm
N_2=8,000 rounds without extra attacks
N= 13,000 swings

Then NECESSARILY I had exactly 1000 tripple rounds and 1000 double rounds, which allows me to compute the confident intervalls...


EDIT : If you use my data for the DA15/TA10 parse and you assume that Kparser is counting the rounds correctly, then you have
N_2:=8655-1161-812-4-3-2;N_1:=8655;N:=11474;
Which gives using the above formula
da=13.23% +/- 0.71 and ta=9.67% +/- 0.62%
ta : [9.05,10.29]
da : [12.49,13.95]

Now this time it is really matching TA being checked first and excluding DA first and xor.

Now for the parse with 17DA/10TA
N_2:=8464-1323-802-9-3-1;N_1:=8464;N:=11435;
Using the above formula
da=15.41 +/- 0.77 and ta=9.84 +/- 0.63
da : [14.64,16.18]
ta : [9.21, 10.47]

This time it is also matching TA checked first and excluding DA first and xor.



Edited, May 6th 2011 9:13am by lynnminmay
#74 May 06 2011 at 7:38 AM Rating: Decent
**
983 posts
Doh ; ; haha. The new parser version tells me my double attacks are triples. If we don't suspect the old version was having issues with double attacks, maybe I'll just keep using it.


1113 DA/3903 rounds (+8% DA) went to 1071 DA rounds with 16 +2 rounds and 41 +3 rounds out of 3790 rounds total.

3790 + 42*2 + 16*2 = 3904, but that implies that the +3 rounds were previously interpreted as one DA and two single hits, and the +2 rounds were previously interpretted as three single hits.
____________________________
Yay for Jhereg!
http://www.ffxiah.com/player/Lakshmi/Byrth
#75 May 06 2011 at 7:52 AM Rating: Good
*
52 posts
Rounds count isnot a prob for KParser: my own parsing on Excel gets very close results if not exact same numbers.

It's the parsing of multiattacks that pose problem...

From that discovery you can guess the repercussion on the validity of all tests done in this topic regarding DA/TA...
#76 May 06 2011 at 8:00 AM Rating: Decent
**
983 posts
Well, the number and type of multi-attack are entirely determined by when it chooses "rounds" to begin. I can provide the problematic data if anyone is interested in taking a look.

Gear was:
Lady bell/Airy Buckler/______/________
AF3+2/_______/_______/Brutal
AF3+2/AF3+2/Hoard/Malflame
Atheling/Taru RSE waist/AF3+2/AF3+2
16% Haste, +8% DA, Saber Dance used every 181 seconds. Box Step ~10 times per cycle and Reverse Flourish ~5 times per cycle.

I can see why it was having trouble, 216*.84 = 181.44, so I'm very close to 3 seconds between rounds.
____________________________
Yay for Jhereg!
http://www.ffxiah.com/player/Lakshmi/Byrth
Reply To Thread

Colors Smileys Quote OriginalQuote Checked Help

 

Recent Visitors: 1 All times are in CDT
Anonymous Guests (1)