I wish you luck with your simulation program then.
Printable View
I wish you luck with your simulation program then.
Thats what he's saying. This is not for testing raid dps this is for simulating hundreds of thousands of parses to see EXACTLY what averages out to the most potency per second in a vacuum. People do this already using models and spreadsheets (which are incomplete and taken as fact even though they are less accurate than simulations) and simulations can take out a lot of the shitty work in allowing for large data sets in a short amount of time.
Uploading logs and parsers requires a lot of tedious work and has very little control in what kind of numbers you're getting. THAT is the anecdotal evidence that he's talking about. There is discrepancy in player skill and one player can be better than another and the better one uses the shitty opener, parses higher and says hey his opener is better just because he's a better player. The game needs this, stop trying to fool yourself into believing it doesn't.
I'd say my model is fairly accurate and representative of actual GCD rotations for an excel spreadsheet. It's also very dynamic and a vast majority of it is automated. A few tweaks here and there and I could make it handle dynamic oCDs if I wanted to (I'll need to do this for botd). It's good for what it needs to do, calculate optimal GCD rotations in a vacuum and stat-weights, which buffs (such as BFB) won't affect. Simulators take it to the next level however. Can't wait until this is finished, te-he.
Right now I want to get a working version of the sim out first, then I will be looking for others to help out. Likely this will be 1 week after heavensward releases.
Needed help, in order of helpfulness, are
1. Someone who wants to take the time to create an actual UI. I'm too lazy for this lol. Ideally this is someone comfortable with forms applications in C#, which frankly aren't that hard but you'll have to know what you're doing.
2. Someone to expand the parser grammar to include spell parsing and character parsing. This means all the stuff that is currently hardcoded should be able to be scripted instead, leading to easier changes if/when spells change or are added. However this may lead to a performance hit, which i'm not really sure is needed. The reason it was hardcoded at first was I wasn't sure if skill effects could be generalized enough. Thinking about it now however, the skills in ff14 really aren't that complicated, and we could move to a script instead. However, this will be a pretty significant change to the engine so likely won't happen for a while.
3. Class leads in charge of class formulas and telling me why something doesn't work. It isn't gonna be glamorous, you'll have to test a lot of rotations and stuff to see if the engine works the way it should. Ninja is a must because it is my only non-50, and I have no idea how it works.
Well, I can't help on the programming side, but I'm always willing to stab things in the face for hours on end (though preferably after the HW leveling rush). And NIN is my main, though I'm 2 levels shy of having all DoW/DoM at 50. . .
Edit:
I forget, what potency did you base this off of? Is it accurate for your Phlebotomize dot ticks?
I think as long as the damage formulas are fairly accurate, what I need most is actual delays.
These are
1. Animation delays for instantcasts and oGCD abilities. This is vital for obvious reasons, as it impacts dps.
2. Cast delays for spells (travel time). This is necessary mostly for BLM (firestarter procs) and possibly SMN (bio > fester delay).
So far noone seems to have this information.
100, 150, 180, 360, 414 (ft*ht) raw potencies, ranging from 0-58 WD, 202-42X Det, and 277-663 STR. The solver ensures to take into account potency/100. No dot ticks. It will require additional testing to see if potency actually works differently than what we originally assumed.
Edit: it looks like every job will be getting their own formula. Jeez...
Also, that formula is the AA one :p. It's rather annoying how this game works. AA and AC are calculated differently, on top of Jobs scaling WD and maybe base damage, differently.
It's a ballache.
I dunno, I thought my NIN numbers kinda proved it. :p
30 pot min: 61
300 pot min: 629
B4B 100 pot min: 229
B4B 500 pot min: 1155
The 300 potency attack is more than just 10x the 30 potency, and the 500 potency more than 5x the 100 potency. My DRG is only 48 and it's hard to get a good amount of variation, but I see the same thing with Phlebotomize ticks compared to Full Thrust, though naturally I didn't save my numbers from that. >_>
Wow are you serious? Assume 100 Potency isn't 100%, but 101%.
299 -> 1155 = 404%.
"100 Potency" of 629 /303% = 207.591
101/30 = 3.366666
207.591/3.36666 = 61.66
lol Please double check and see if I'm not being a moron here. I rounded a few numbers here and there also. But could something like that... work? I want someone to say I'm a moron.
207.591*3.03 = 629
229*5.05 = 1156.45
Given how bad the games rounding is, I guess it kinda checks out... I'm gunna run some tests after I've broken my Archer and Rogue weapons.
Well, first you're assuming that the listed potencies are wrong, and then assuming that it's only the X00 potencies. :p
Also, the 61.66 looks okay if we ignore that it should round to 62, not 61, but then it breaks again when you add in that the minimum crit for that is 91. 61.66 x 1.5 is over 92.
Also also, if 229 is "101 potency" then you would still only multiply by 5 to get the "505 potency" of SA. Which still leaves you at 229 x 5 = 1145. And since my observed SA maximum was 1277. . .1277/1145 would have been 1.1152, which is way too big a spread.
Could of said I'm a moron :P I just get too happy when I observe random patterns. Nearly always turns up as a coincidence, haha. But yeah, the Crit Min/Max's completely throw what I said out of the window. RIP.
Nah, I'd much rather just provide more numbers. Besides, it's not like I put all my data points in that post. :p
Adding all my data points into one linear regression, I get a reasonably accurate formula:
DMG=2.21388(Potency)-2.00138
It doesn't quite hit some of my maximums, but we're talking a few tenths of a damage point away from values that would round up to my observed maximums. For example, that provides 695.26 for maximum unbuffed 300 potency, with an observed at 696. But, then, it gives 764.80 for the B4B max, with an observed at 765.
Edit: Note that you would do the subtraction before multiplying for buffs.
Something I've been looking into but have yet to find an easy way around solving for (lol distractions) is that if you can't trust the X-value of your solve to be error-free, then the slope is actually biased towards zero.
Given that my 40 potency dot can go from 58-65 resulting in 1.1206 , and either 64/58 and 65/59 still result in 1.10X, there must other stuff be going on.
Either the game forcefully creates more numbers than needed (for cases where a 1.1 value would result in only one number - level 1 BLM auto-attacking for 1-2) or some stuff happens after creating the damage range (Magic and Mend is applied after creating the damage range - combine that with rounding and you could get there), or you could even have both of these.
Damage ranges are a pretty pointless concept anyway. You'll only ever bother with their existence if they punish you, i.e. you get the bad end of the spectrum and your damage blows because of that. Hopefully going in Heavenswards with a lot of bigger numbers they'll notice that there are no benefits of damage ranges. The only way to counter that is to tune stuff around the worst case, but that would mean that if you get exceptionally lucky, it can seem pretty easy (10% "buff")
Well, one thing that I'm pretty sure happens with those damage ranges is that if the rounding is a .51 --> 1 or .49 --> 0 kind of situation, you will need a *lot* of tries to even see it happen. Pretty much why I take a mishmash of potencies (and include crits as x1.5 potency) when I test damage values; yeah, it's making assumptions that that's how it works, but in practice it makes that sort of thing less of a problem.
Yeah. The worst is when you're certain that a damage value should be possible, but the game refuses to give it up. Dunno how many times I sat there questioning my own sanity while gathering numbers. . .
Anyway, since I apparently volunteered myself to collect animation delays for some reason, I should probably make sure my methodology isn't gonna be stupid. Record myself doing actions, forcing animation delays, and count fractions of a second using good video editor until the next ability in line triggers a CD. Right? I'm not sleep-deprivation crazy? >_>
Assuming that's right, I have these values so far (based on like, one iteration each, so take with a grain of salt). . .
B4B: .6 seconds
Power Surge: .6 seconds
Life Surge: .7 seconds
Vorpal Thrust: 1.1 seconds
Full Thrust: 1 second
Jump: 1.4 seconds? That seems harsh, but it's what the video shows.
I would probably have more values, but I have a wonderful headache today.
This seems about right. Lower than what I expected, actually.
If anyone is interested, here's a heck load of Data Points for you lot to play around with. Crit Data is also included. Just to note, the stats used are either listed on the documents file name, or on the 1st page in a table. Ignore the stats listed inside the data points pages. Another thing, nearly all of it is done with 150 potency. The one that's at 100 potency should be listed as such, and I believe there's one datapoint with 180 potency somewhere in the "WD v DMG" sheets.
http://www.filedropper.com/datapoints-fix
I'm working on collecting 0 WD data now, so if you have anything you specifically want me to get for you, I can do that.
So much info. . .Unfortunately, some of your Disembowel stuff is labeled as 150 potency? I assume that's just a c/p error. Anyway, if you're collecting more info, do you mind taking a few minutes to get some dot tick values? They have a pretty small range usually, and you can have them ticking on multiple dummies at a time, so if it's not a hassle, that would be great.
Edit: Also, are we to trust the file names, the sheet names, or the information in the sheet? @_@
For example, DET VS 573 STR - 150 Potency has a 372 DET sheet, but the info in the sheet says 362 DET, 653 STR. >_>
Yuuuuuuuuuuuuup. That's all bad copypasta stuff. As I mentioned, the exact stats used are linked in the table on the first page. And sure thing! I'll get DoT damage done for ya. Also, how are you organising your linear regression graph for potency btw? Are you stacking all of the jobs together, or giving them all their own separate tables/graphs? Very interested to see the work you've done on it.
Also, 1.4 for Jump is pretty reasonable. Instinctively, I know that if I have a jump available and I use it more than 1/3 through my GCD, I end up with a GCD clip.
EDIT: Yeah. Whatever is on the first sheet with the table and what the sheet is actually labelled, is what you should trust. The WD/STR/DET info inside sheet is all messed up. I got too lazy fixing it. It's like that for nearly all my datapoints, lmfao. And sunny thinks he's bad... If you want, I can quickly fix it up for you then send you another dl link? hahaha
EDIT 2: I'll send you another download link. I understand my own stuff, even if it's incorrectly labelled, but it'll be annoying for others to decipher what the heck is going on :P
EDIT 3: http://www.filedropper.com/datapoints-fix
Okay, removed all necessary junk and it all should be correctly labelled now. One thing to note, as you might of already noticed, is that I never used the Crit values, as I never achieved a complete min/max on most of them. But it's all there either way.
I believe spell travels times are static at very close to 0.5 seconds if there is one. There was discussion about that in the BLM thread somewhere. Lessee if I'm not too lazy to find it.
E: Lots of 0.5s thrown around, but the videos that were to prove travel time is static regardless of distance are not up anymore. I can confirm, though, that your spells travel slower in melee compared to max range. I've never timed it myself, but the 0.5 seconds static sounds right.
For Summoners, Bio has at least a 0.5 second delay before you can Fester or Bane as well. Wouldn't be surprised if it was the same as BLM.
I've ran into an error recording DoTs. I just realised that ACT simulates DoT ticks can I can't get the debug mode working either. Should I use logrep or FFXIV-APP then I wonder...
http://puu.sh/ipEcx/d2b440e769.png
58 WD, 642 STR, 398 DET on a Dragoon.
30->100 potency is a 3.36% increase, which is similar to what I posted yesterday.
If we include crits:
http://puu.sh/ipED2/0873d30a30.png
N/A means a comfortable min/max was not achieved.
Yup. It's fixed. Gonna do a 60min blast at 58 WD, 665 STR, 409 DET during Microsofts E3 and try get absolute min/max values.
EDIT:
Here's some more, 0 WD
http://puu.sh/ipKKB/470fc5ff52.png
Oh shit, I was thinking about doing something similar o.o
Herp I didn't get any work done today, busy busy and then steam summer sale lol.
I'm trying to figure out what you need in terms of access for the parser.
So far it will have
cast sequences - so you can do your stupid combos (seriously no other game has these, combos suck, why not just have one button that does 3 attacks)
actor.aura - whether aura exists
actor.aura.remaining - how much longer on the remaining
actor.cd - whether cd exists (since cooldowns are auras this is just shorthand for a specific index of aura)
actor.cd.remaining - ditto
gcd.last - time since last gcd, useful for timing oGCD events
gcd.next - time till next gcd, probably more useful for timing of oGCD
attr.[attr] - your current attribute
there are also several macros, which signify different sections of script
[SETUP] - setup vars and character
[PRECAST] - currently not supported, will just be ignored.
[GCD]
[OGCD]
There will also likely be a translator table of skill names...so you don't have to type in LNC_BLOOD_FOR_BLOOD you can just type blood_for_blood.
The format (for the rotation it is currently using) will likely be something like this:
Code:[SETUP]
#sets up an alias for our player
player=p1
#sets up an alias for our target
target=t1
#load skills and traits
p1.load.lnc
p1.load.drg
#setup attributes
p1.attr.str=500
p1.attr.dex=200
#setup server variables
sim.duration=600
sim.execute=200
#setup diagnostic or no - diagnostic runs 1 run with log output, for testing your rotation
sim.diagnostic=true
#otherwise setup sim trials
sim.trials=100000
#i/o
sim.output=./output.txt
[PRECAST]
# currently does nothing
[GCD]
(!p1.aura.heavy_thrust){heavy_thrust}
(t1.aura.chaos_thrust.remaining<10){impulse_drive,disembowel,chaos_thrust}
(!t1.aura.phlebotomize){phlebotomize}
(){true_thrust,vorpal_thrust,full_thrust}
Hm, the multiple trials thing reminded me of something... you might want to have a special accumulator for tracking damage distribution in addition to the normal ol' damage accumulation. For completely static rotations, while it could get a bit funky towards the extreme end of damage, it would give you a really accurate picture of just how high/low you can typically get while obviating the need to monte carlo the thing.
By that I mean if you could produce actual charts of the bell curve and it'd be an actual curve that would be sooooo cool *flutters eyelashes*
So what the sim actually does is it outputs everything, all the time.
The different modes are just the amount of listeners that are attached to the events.
Diagnostic - all listeners (event, aura, damage, and output) are present, so fairly slow. All output is sent to the output file
Light - only damage listener is present. Damage only accumulates total damage, and total damage for each trial is outputted.
Full - damage, and event listeners are present. # of procs, # of casts, and other spell metrics (crit %, avg damage, etc) are tracked and outputted. This is also moderately slow, and will likely require a decently powerful machine to run in a decent time.
As for UI, you can do whatever you like with the data that is presented. You could write your own UI too! Its not high on my list of priorities right now.
How would your sim handle remainder DoTs in a "looped" rotation in a vacuum? EG, if you set it to do a full rotation, which is like 60s for a Dragoon, how would the sim handle the remaining 2-3 CT + PH ticks?
They just won't happen.
The engine stops processing events once past duration. It only checks after the event is executed, so you might go like 0.5 sec or so over, but its pretty much just going to end.
This is realistic as this simulates the boss simply dying.
Also I dunno I got really pissed at the program today, I will see if I can muster the willpower to finish before Heavensward, though this is unlikely since I haven't been really interested in the game recently =/
The effect of determination on auto-attacks has been reduced.
Critical hit rate now affects damage dealt with a critical strike.
That's really bloody annoying, but it does make sense. Determination scaled more than twice as much than it does for Weapon Skills. It also does kinda support that other stats could possibly scale different with AA's, kinda like what my model shows.
In other news, AP scales differently per job... Massive difference how it scales between a Dragoon and Ninja at least. It's weird, Strength scales better on a Dragoon, but a Ninja has a higher base damage value, lmao. Not too sure about WD, but I think WD also scales differently... So yes, it looks like every job will be getting their own damage formula, which I feared.
Who's gonna volunteer to do Crit work? :D