Ah ok. I commented on the DRG thread before I saw your post here, but like I said over there I have UI almost ready to go. Just need to make the appropriate calls to your code and test/polish.
Printable View
Ah ok. I commented on the DRG thread before I saw your post here, but like I said over there I have UI almost ready to go. Just need to make the appropriate calls to your code and test/polish.
Hello hello,
0.4.3 has been released.
It contains the DRG jump/ssd fix, as well as a decent code revamp, but most importantly, has documentation!
...for some of it. The core parts that are exposed as public members, at least. If you have any more questions about undocumented aspects of the code let me know.
Also included in the /Samples/ folder is the entire UI (its very small) that I created. It is somewhat commented and should give you a reasonable idea of how to hook your own UI into it.
Note: casting event is currently unused and won't ever fire.
Enjoy!
https://mega.co.nz/#!s89GzAqD!vvX7xw...xshvYCUipH3-to
Have you tried implementing Heavens UI for your Sim?
EDIT: based Kim dotcom
I would imagine it would be heavensword that would implement his UI for my sim.
Oh uh, for people unfamiliar with programming, the simulator is a set of libraries.
Anyone who wants to can write their own UI, so I don't need to implement his UI, he just needs to call my libraries. Maybe that makes more sense.
They can be developed separately and then used concurrently. As long as the public API does not change all that needs to happen is calling updated libraries if/when they are updated.
Right. I've been making a stub UI while panda has been refactoring and commenting his library. Basically have dockable/undockable panels for navigating and editing the rotation scripts along with an output panel for the actual sim. I plan to support the basics first like saving/loading/creating rotation scripts and exporting output. I'd like to get some basic syntax highlighting to make reading the script easier and of course would like to add more features and polish as things progress.
When panda says his stuff is ready, I just need to grab the new DLL and read his docs to see what functions I need to call and what to pass them.
Hmm, if you want to get syntax highlighting for the script working, you might want to look at how Irony's grammar explorer does it.
However, I broke the highlighting when I added the AST nodes, so whomp whomp. Might be easier than doing it yourself from scratch.
Download Irony source, set the executable project to GrammarExplorer, build and then run the program. In the program, click the ... and add SimFF.Parser into the program, it should automatically load the grammar.
Then load or type in a sample script and it will generate the parse and AST trees for you.
Update on behind the scenes work, I've started converting a lot of the hardcoded stuff to allow it to be scripted.
The upside to this is that if hotfixes or other things happen, only things that need to be updated are some text files and you will not need to compile and I will not need to release a new build.
Downside is a performance hit, but the sim is already plenty fast, and the latest changes are all on startup performance hits, not trial-based hits (in laymen speak, its a fixed cost rather than variable, and very small at that since it isn't being run on the order or ~1-10 million times).
I have a plan in mind but I have to write 2 more grammars as well as rewrite the ability code (and add in the new ability database text files) so this will be a fairly long undertaking.
Understood; I may just mock some calls for now to test parts of the UI and continue on my way. Will continue to check this thread for updates.
Updated for 0.4.4
Download
v0.4.4 - Download
DRG Phlebotomize duration fixed
simff.config file added for formula customization
NCalc.dll included as part of program. License updated.
Please note attr.aapotency and attr.aadelay have been renamed attr.aap and attr.aad . You must change your rotation scripts or else it will break.
Limited support for configuration has been added. You may now enter your own custom damage formulas. Look at simff.config for information.
The file "simff.config" must exist in the same directory as simffui.exe or the program will not run. Please ask if you have any questions regarding the damage formula syntax. It should be fairly straightforward.
Also fixed a bug with phlebotomize duration, it is now 24 seconds.
Are delayed skill effects represented in SimFF?
e.g. The Disembowel debuff is applied on the target a few moments after Disembowel's animation lock ends. If you use an off-GCD right after Disembowel's animation lock, your off-GCD won't get buffed by Disembowel.
Same thing for B4B. The reason why we can get a 9-GCD B4B with higher GCD recast times (e.g. 2.47s) is because the buff is added close to the end of B4B's animation lock, rather than immediately after B4B is used.
It technically is but I have no timings for any delays.
Someone needs to either get that data or we need to get someone to "not-datamine" it.
NOTE: I "definitely" don't "condone" "datamining" "wink".
You should totally make a PS4 add on for us PS4 folk ;)
i am kidding, but would be nice to have a parser :(
Either way kudos to you for doing this for the community :D
Its an offline program anyhoo, and everyone has a laptop, so it doesn't even matter what platform you play the game on.
I did some hard thinking (giggity) today about the next steps with the sim, and while I am taking a few shortcuts that I would not want to take if I had infinite time to think about it, I think it will be a good compromise, if ugly code, that will allow more on the fly customizations.
Since this is kinda the Damage Formula thread, and I have this wonderful tendency to look at potency and hate life, I figured I'd post this:
http://imgur.com/hxWKFhN.png
These are all numbers taken from my NIN with the WD/AP/Det posted above and 0 SS from gear to throw off the 30/40 potency numbers. Potency is listed twice each; top being min and bottom max. Formula in the F column is D*3.037-1, which I admit I made up to get the 1517.5 at 500 potency. G column is F*.95, and H is F*1.05, so as to get the min/max of everything if the F column is actually right (I didn't feel like alternating formulas, so I was lazy and just made it redundant as ****). The notes in I are for which way the value needs to go in order to actually align with observed values.
Now, you've probably noticed that 180 potency and 360 potency are listed as "Way Down." Those are Katon/Raiton numbers. I really don't want to think about the possibility that magic ninjutsu (and possibly Fuma, even) have their own formula. But even if we ignore those, Mutilate and Armor Crush (missed positional) need to go up, while Death Blossom, Mug, and Armor Crush (correct positional) need to go down.
So, yeah, anyone wanna take a crack at bringing two values up and simultaneously bringing 5 values down?
Thanks for the data.
I patiently wait for someone else to plug the formulas into the sim =)
See, the end goal of the sim is that I do nothing and everyone else does the work for me.
Muahahahaha. Best thing is, it is better this way.
Herp derp an update, learning about Reflection.Emit to see if thats a venue I want to pursue. Probably not for the time being. But thinking about it if someone figures out how to get spelldataa from the client.
Time to break more stuff!
This is the formula Dervy has listed for AA DPS, right? And since the (1/AA_DELAY) part gives the "per second" part of DPS, the rest of the formula should be the "damage" part. Now, one of the numerators is AA_DMG, which I'm assuming is what the game labels as "Auto-attack" on weapons, right? So things with a higher "Auto-attack" stat should do more damage if STR/DET are held equal…
My Expanse Machetes aren't doing that. I'm doing some comprehensive WD testing today, but here are the numbers I have from a few weeks back:
Both tests with 569 Dex, 267 Det.Code:AA_DMG AA_Min AA_Max
i175: 54.40 196 199
i160: 53.76 199 220
Like I said, I'm doing more WD testing today. I'll make sure to confirm this when I get to those ilvls…
Not necessarily.
We know we have base damage, we know base damage is multiplied with other stuff - for balance sake we do want base damage to be affected by Weapon Delay, else faster weapons would significantly outperform slower weapons (they apply base damage much more often).
Weapon stats have the following relation: AA_DMG == AA_Delay * WD / 3 - so whatever you do, AA_Delay has practically no impact on base damage after the /33 division in Dervys model.
Why does the formula work for Dragoons? Well - all their Heavensward Weapons are 2.8 speed.
That's the thing, though. Output damage should be a factor of WD scaled to Delay, right? And AA_DMG is WD scaled to Delay. The problem is that AA_DMG seems to be meaningless when it comes to predicting the damage of individual auto-attacks, as I have weapons with higher AA_DMG doing less damage per strike.
Maybe I'm just not understanding what you're getting at, but this doesn't seem to resolve the issue.
Your second formula can be re-written as (1+WD)*STR*Delay/X without changing the outcome. Which can be written as STR*(Delay + WD*Delay)/X. If STR (and Det, which you don't have listed) stay the same, a larger (Delay + WD*Delay) component would cause an increase in output damage. Baldur Daggers are 63 and 2.56, for a De+WD*De of 163.84; Expanse Machetes are 68 and 2.40 for 165.6.
So even your second formula predicts that Expanse Machetes would do more damage per hit than the Baldur Daggers, when they don't. At 378 AP and 298 Det, the Expanse Machetes do 131-144 AA hits versus 133-147 for Baldur.
It would be (x + WD)*STR*Delay/X. And that's changing the outcome.Quote:
Your second formula can be re-written as (1+WD)*STR*Delay/X
What Viridiana is saying is that higher AA damage is not giving you higher total damage.
Delay is simply how fast the autoattacks come out.
So the formula is not doing the right thing.
In the sim, delay is not a factor in the damage - whether or not that is how the weapon is balanced is sort of irrelevant. The sim fires off autoattack events every DELAY seconds, using stats and AA_DMG to figure out the damage of each autoattack. So if that is incorrect or isn't how the game does it then we need to revisit this.
The damage Dervy models for his spreadsheet normalizes AA for this.
Blarg. Well, I missed that it would be X+WD, but the formula you wrote there would be the same outcome as your original, because you can do multiplication and division in any order as long as you don't botch the parentheses. So we now have (X*Delay + Delay*WD) as being the determining factor. In order for Baldur to beat Expanse…
X*2.56 + 2.56*63 > X*2.4 + 2.4*68
2.56*X - 2.4*X > 2.4*68 - 2.56*63
.16X > 163.2 - 161.28
.16X > 1.92
X > 12
Alternately, I have multiple points where an increase in WD and decrease in Delay cause a higher ilvl weapon to output the same damage range as a lower ilvl one. If I set their formulas equal to each other…
X*2.56 + 6*2.56 = X*2.4 + 7*2.4
.16X = 16.8 - 15.36
X = 9
X*2.72 + 14*2.72 = X*2.56 + 16*2.56
.16X = 40.96 - 38.08
X = 18
X*2.56 + 20*2.56 = X*2.4 + 23*2.4
.16X = 55.2 - 51.2
X = 25
X*2.64 + 30*2.64 = X*2.56 + 32*2.56
.08X = 81.92 - 79.2
X=34
X*2.72 + 58*2.72 = X*2.56 + 63*2.56
.16X = 161.28 - 157.76
X=22
So, yeah, the formula still doesn't work.
Well, it kinda is even in the sim if you're using Dervy's formula, since delay is a factor of the AA_DMG term.
Yes. And i am saying that a higher AA_DMG stat on any weapon does not mean your auto-attacks will be higher.
Assume you have 20 Basedamage, and that is modified by AA_Delay to be added to your AA.
20 * 2.4 = 48
20 * 2.56 = 51.2
Basedamage modified by AA_Delay is a huge factor, and Dervy's formula has a significantly reduced interaction between these two. His dragoon formula works because virtually all heavensward dragoon weapons are 2.8 AA_Delay with a selected few at 2.88.
Are you saying that delay doesn't actually make autoattacks tick faster/slower, and is just a damage mod?
Because if so then
1. This game is stupid.
2. Super stupid.
3. There is no reason the two should be separate stats.
No I stripped it out, on the basis that the whole point of it was to normalize autoattack damage for his spreadsheet, since it doesn't do dynamic stuff. You can check the formula used in the latest version, inside simff.config which has all the damage formulas. aap is Autoattack Damage (potency) while aad is Autoattack Delay.
That's not what i'm saying. I'll try to explain it a little bit simpler.
Imagine two itemlvl 175 weapons - one with 2.56 speed and one with 2.4 speed.
Both will have 68 physical damage.
The 2.56 speed weapon will have 68/3 * 2.56 = 58.02 AA_DMG and hit every 2.56 seconds
The 2.4 speed weapon will have 68/3 * 2.4 = 54.4 AA_DMG and hit every 2.4 seconds
Now let's insert these values into Dervy's formula:
(58.02/33.04+1) = 2.756
(54.4/33.04+1) = 2.646
Now assume you have 800 STR.
2.756*(800/6.92) = 318.61
2.646*(800/6.92) = 305.89
Divide by AA_Delay
318.61 / 2.56 = 124.45
305.89 / 2.4 = 127.45
The 2.4 Speed Weapon is actually better in Dervy's formula. Why? Because it applies the same amount of Base Damage - contained in (STR/6.9) - more often than the 2.56 Weapon.
If the game is designed properly, base damage is adjusted to AA_Delay. In the most simplistic case it would be similar to the WD/3 * AA_Delay relation, i.e. BaseDamage/3 * AA_delay.
In WoW there's weapon speed normalization (http://wow.gamepedia.com/Normalization) to account for that.
Given the fact that a slower speed weapon with lower AA_DMG does hit harder, base damage seems to be adjusted in some way.
Yes I know what you're saying, but even in your example the higher AA damage weapon is doing more damage per hit.
But in Viridiana's trials the higher aa damage weapon is doing less damage...per hit.
I do not care about this normalization for dps - let the devs figure that out.
I do not care if a weapon is better or worse dps than another.
I am simply worried if it turns out our AA damage formula, PER HIT, is incorrect.
But the "aap" in your formula, to use Expanse Machetes as an example, would be 54.40, right? Because that has aad as a factor, since it's equal to WD*aad/3.
Again, unless I'm just horrendously misunderstanding things, it does account for AA_Delay.
Also, just tested my Zeta versus the HQ i133 gear. Same WD, kept AP and Det the same. 2.40 Delay Zeta gives 115-128, 2.72 Delay Titanium Pugiones gives 133-147.
2.4/2.72 = .8823
(115+128)/(133+147) = .8679
Gonna look more into it, but it's pretty close to equal. Bear in mind that the 115-128 needs to be a rounded down 115 and a rounded up 128, or else it's too big a spread. So it's possible it might be very slightly higher than shown here.
Exactly, they're equal. Using the numbers of my previous post
2.4/2.56 = 0.9375
305.89/318.61 = 0.96
Assume a 2.72 weapon: 61.65 AA_DMG - 2.866 * (800/6.92) = 331.32
2.4/2.72 = 0.8823
305.89/331.32 = 0.923 to get to ~0.88 i'd need 345 hits
331.32/2.72 = 121.8 dps
The slower the weapon is - the lower the dps on dervy's formula. Your numbers even have the slower weapon slightly higher in terms of dps.
Well, the best I can get without just making a whole new AP/Det point and trying again is the 2.4 doing about 87% of the damage of the 2.72 when it should in theory be just over 88%. That's using Venom and Venom+DE numbers to weed out some rounding issues. I mean, that's still pretty close, but I'm not yet willing to say they're equal. I might go get a whole new data set, though…
Well, my only assumption going in was that a higher Auto-attack stat would lead to a higher auto-attack per hit. I only referenced Dervy's formula after realizing that this was not the case. And Dervy's formula makes the same prediction I had going in, which has been shown inaccurate. Any references I've made to it since then have only been to reinforce that it makes predictions that don't pan out in practice, which Dervy is working to fix.
Edit: Well, a second assumption I had would have been that equal WD would yield equal DPS.
I'm not about to read through allllll that, but when I tested it in 2.5, the hypothesis that autoattacks were normalized to do the same base damage at the same WD, AP, and DET was correct.
That may or may not be the case with these oddball ilvl items from Heavensward.
I took a week off because I was stressed at work and wanted to actually play the game.
Expect a small update tomorrow with macro functionality added (to better support scripting static rotations if you wish, or other more advanced state tracking), and a bigger update sometime middle of next week with the spell scripting functionality change.
That is the last large engine update I have planned - afterwards, adding more jobs should be simple and won't take more than a week or so.
I am unconcerned with the formulas for now. You guys work it out, and plug into the sim to test. It can be changed at any time.
I'm actually very interested about simming tank damage - maybe help some tanks improve their rotations as well as put some common myths to ground.
Oh one other engine update that I forgot about - adding mp/tp support and actually checking that. It won't be hard, but as you guys may have noticed the engine currently lets you cheat and ignores tp. Will likely be a toggle, something like "sim.enforce_tp_mp = true" to force checking. Needless to say that will probably need to be toggled on for BLM...
Oh and another thing, on Friday will likely see the introduction of another option, "sim.jitter = 10.0" which adds a randomized (uniformly distributed) duration range to the sim duration to better gauge the benefit of sks/sps.
5 wars need rotation sims? I thought it was basically just rotate between eye and path and every time you berserk just triple fell/decimate (depending of course) and go on with your merry day... Wars also fall into an odd situation where unless your in a dungeon its MORE raid dps to unchained in defiance for 2 combos then deliverance triple fell even though its less dps for the war...
I added jitter, and it works fine, but in the process I seem to have broken something with the rotation, so dps is down.
Oh well. Probably not going to see a release today as I need to fix some bugs.
For obvious reasons, putting in jitter gives us a much more realistic value of SKS, and it should be valued higher than it has been.
EDIT: fixed the bug, hooray.
Still going to delay release to add macros, sorry.
Good news is all bugs so far have been me being retarded, rather than a problem with program logic or inconsistencies. So I am happy about that. Human error ftw.