Homestead Theorycrafting & Feedback

CaptainPocky · January 2017

Good stuff, I always like seeing people that also actually enjoy this game's sometimes-crazy math.

I haven't had the time to fully read through this thread yet, but I wanted to mention something just fyi.

On uptimes. For proc sets, a very easy-to-remember but useful equation you can derive from the binomial distribution is:
P = 1-(1-p)^n where p = Tooltip chance, n = Opportunities/sec (times 1 sec for the exponent units), and P = Proc chance/1sec

So for example BSW: You can show MagDKs do about 5.29 flame damage hits per second. This gives P = 69.3%, or average 1.4 seconds to proc. With a cooldown of 12s, that's a total period of 13.4s or an uptime of 8/13.4 = 59.5% -- approximately what I believe you found earlier. BSW in this sense is also what I call a "cooldown-limited set", e.g. even with only 1 opportunity per sec (like just throwing down a fire wall), the uptime only drops to 47.1%. Many sets in the game are like this. The sets that aren't (ex. Selene's: avg. proc time = 4.9s vs. CD = 4s) are usually balanced between proc time and CD.

Anyway, hopefully this helps you to speed up some calculations, if you didn't know it already.

(Note: Of course we have to be careful as to when the cooldown actually begins, because occasionally you'll find a set that doesn't actually begin the cooldown until the proc ends. If it were the case here, the uptime would only be 8/(8+12+1.4) = 37%, but I believe this type of effect is unintentional and has mostly been removed from the game.)

CaptainPocky · January 2017

Also, I'm sure at one point while writing your spreadsheet you came to a realization that I had while writing my own -- it's a lot of pain just to obtain results specific only to one or two setups.

So I started thinking, "Hm. Wouldn't it be nice to have a program that with the click of a button would tell you your DPS and optimal Champ Point distribution with any specific setup by calculating everything from the ground up?" Thinking about it more, I realized that it wouldn't even be *too* hard to write! So I might do that. Or not if I'm lazy. The biggest challenges I see currently are:

1.) Finding a reliably updated list of data for each skill (e.g. in the "No buff" Tooltip Damage equation, DMG = (M+d*D)*r*x, what are the multipliers d (usually ~10.4) and x for each skill? Also, does the ability count as melee damage? Direct damage? Is it affected by Thaumaturge? Etc.), or doing it myself. Does anyone here know a good list?

2.) Making an interface that someone other than me could use. (I know how I'd code it up in Matlab or Java, but I have absolutely no experience with making an actual Java-based GUI haha)

NightbladeMechanics · January 2017

SublimeSparo wrote: »

NightbladeMechanics wrote: »

Proc sets weren't nerfed for pve.

As in they were nerfed because of pvp, or despite the nerf they aren't nerfed to the ground?

They were nerfed for overperforming in PvP.

Jeckll · January 2017

Very good stuff. Thanks for sharing.

GilGalad · January 2017

CaptainPocky wrote: »

Good stuff, I always like seeing people that also actually enjoy this game's sometimes-crazy math. I haven't had the time to fully read through this thread yet, but I wanted to mention something just fyi.

On uptimes. For proc sets, a very easy-to-remember but useful equation you can derive from the binomial distribution is:
P = 1-(1-p)^n where p = Tooltip chance, n = Opportunities/sec (times 1 sec for the exponent units), and P = Proc chance/1sec

So for example BSW: You can show MagDKs do about 5.29 flame damage hits per second. This gives P = 69.3%, or average 1.4 seconds to proc. With a cooldown of 12s, that's a total period of 13.4s or an uptime of 8/13.4 = 59.5% -- approximately what I believe you found earlier. BSW in this sense is also what I call a "cooldown-limited set", e.g. even with only 1 opportunity per sec (like just throwing down a fire wall), the uptime only drops to 47.1%. Many sets in the game are like this. The sets that aren't (ex. Selene's: avg. proc time = 4.9s vs. CD = 4s) are usually balanced between proc time and CD.

Anyway, hopefully this helps you to speed up some calculations, if you didn't know it already.

(Note: Of course we have to be careful as to when the cooldown actually begins, because occasionally you'll find a set that doesn't actually begin the cooldown until the proc ends. If it were the case here, the uptime would only be 8/(8+12+1.4) = 37%, but I believe this type of effect is unintentional and has mostly been removed from the game.)

The binomial distribution in the way you use it is not the way to go in my opinion, and your results don't match the reality. BSW uptimes on a DK are at 62-64%. So let's check the calculation:
A binomial distribution could be used to calculate the probability of having one proc after one second, like you did I guess and you used that probability (69.3%) to calculate the average. But you you have to use the average based on the 20% chance of the binomial distribution with p=20% and n the number of fire ticks.
Average is defined as A = n * p.
Normalizing to seconds and using your 5.29 ticks per second we get:
A = 1.058 procs per second
So finally, it takes 1/A = 0.95 seconds to proc on average leading to an uptime of 8/(12+0.95)=61.7%. Wich is still too low, but closer.

GilGalad · January 2017

CaptainPocky wrote: »

Also, I'm sure at one point while writing your spreadsheet you came to a realization that I had while writing my own -- it's a lot of pain just to obtain results specific only to one or two setups.

So I started thinking, "Hm. Wouldn't it be nice to have a program that with the click of a button would tell you your DPS and optimal Champ Point distribution with any specific setup by calculating everything from the ground up?" Thinking about it more, I realized that it wouldn't even be *too* hard to write! So I might do that. Or not if I'm lazy. The biggest challenges I see currently are:

1.) Finding a reliably updated list of data for each skill (e.g. in the "No buff" Tooltip Damage equation, DMG = (M+d*D)*r*x, what are the multipliers d (usually ~10.4) and x for each skill? Also, does the ability count as melee damage? Direct damage? Is it affected by Thaumaturge? Etc.), or doing it myself. Does anyone here know a good list?

2.) Making an interface that someone other than me could use. (I know how I'd code it up in Matlab or Java, but I have absolutely no experience with making an actual Java-based GUI haha)

I also thought about programming it but as you wrote the problem is to get all the coefficients for the different abilities including their global cooldowns. Even a perfect simulation would not match reality since a decent amount of dmg is done by weaving and player skill (perfect weaving, all dots perfectely refreshed, etc). All you can do here is to introduce a weaving coefficient that can be used to somehow simulate player skill, like I did in the spreadsheet.
The error from player skill will be bigger than the ability coefficient error you get by just taking a mean ability coefficient.

The perfect solution would be a real rotation simulation tool with an adjustable error rate, etc. but in that case it would be much easier to write a macro and let it perform the rotation in game automatically.

GilGalad · January 2017

gard wrote: »

When does the bonus ulti on enemy hit from shooting star get applied?
If I have shooting star on one bar, cast it, then swap bars before it lands do I still get the credit?

Just tested it on the PTS. You also get the 12 ultimate per target if you are on the other bar. Tested it with no ultimate on bar 2 and shooting star on bar one with no ultimate regeneration active.

@Panth141:
I did some testing and found the following buffs are additive:

Minor Slayer
Staff Passive
Minor Berserk

For elemental dmg there was another additive buff around 5% involved (could have been either the High Elf passive or the Mage lightning dmg passive). But it seems that all these buffs are additive.
I will check how they interact with skills like Sweeps and executes tomorrow.

All the data can be found in the "Experiments" tab in the spreadsheet.

CaptainPocky · January 2017

GilGalad wrote: »

The binomial distribution in the way you use it is not the way to go in my opinion, and your results don't match the reality. BSW uptimes on a DK are at 62-64%. So let's check the calculation:
A binomial distribution could be used to calculate the probability of having one proc after one second, like you did I guess and you used that probability (69.3%) to calculate the average. But you you have to use the average based on the 20% chance of the binomial distribution with p=20% and n the number of fire ticks.
Average is defined as A = n * p.
Normalizing to seconds and using your 5.29 ticks per second we get:
A = 1.058 procs per second
So finally, it takes 1/A = 0.95 seconds to proc on average leading to an uptime of 8/(12+0.95)=61.7%. Wich is still too low, but closer.

Well ok, I left something out for the sake of simplicity. The equation I wrote isn't totally correct, but the full answer also isn't quuuiiiite as simple as 1/N*p. Click the spoiler for a full explanation. Long story short, you can get to the correct answer of 62.2% using my complete equation, though 1/N*p is still a very good approximation.

Imagine I take 2 coins and define a trial to be flipping both of them. I do this 100 times, waiting 1 second between each trial. We both agree that obviously, you would get 1 head (0.5*2) per trial. Over 100 trials, that would then be 100 heads. The trick here then is that we aren't interested in how many heads *total* you got, but rather how many times you got a head *at all*.

So specifically, for each trial we have 3 possibilities. HH, TT, and HT. From the Binomial then we'd most likely have 25 HH, 25 TT, and 50 HT. Adding up the number of heads, we have 50+25*2 = 100, like before. But what if we define a success as just getting a H at all (e.g. P(#H>=1))? Now, we only have 75 successes -- not 100.

Using my equation: (1-(1-.5)^2) = 0.75. Average = 0.75*100 = 75 successes, the correct number.
1/0.75 = (100 trials * 1 sec/trial)/75 successes = 1.333 sec/success; or the time to proc.

Now though, I did leave something out just for the sake of approximation. I warn you that usually this doesn't matter too much, but if we want to be totally accurate I suppose it is necessary. Say now we are still flipping two coins every second for a total of 100 seconds, but rather than defining a trial to be 2 coin flips, we define it to be 1. Therefore rather than having 1 trial every second for a total of 100 trials like before, we now have 2 trials every second for a total of 200 trials.

So though we still flip 200 coins, and we still have 100 heads, we now have 100 successes rather than 75!
Now: (200 trials * 0.5 sec/trial)/100 successes = 1 sec/success.

So what did I leave out? My equation uses a 1 trial/second base just for the sake of simplicity. In reality though, you would have to adjust this based on whatever time-step you decided you wanted to work with. The game (I believe) works with a discrete time-step of 30 frames/sec, though you could apply a continuous (0 sec) time-step too if you really wanted. Blah blah, let's get to some examples.

2nd Coin example: (2 trials/s)*(1-(1-0.5)^((2 coin flips/s)/(2 trials/s))) = 1 success/s = 1 sec/success (correct)
BSW Uptime (1 trial/s): 8/([1/{1*(1-(1-0.2)^(5.29))}]+12) = 59.5% (I figured good enough)
BSW Uptime (30 trial/s): 8/([1/{30*(1-(1-0.2)^(5.29/30))}]+12) = 62.2% (Correct answer, matches your experiment)
BSW Uptime (Infinite trial/s): lim(x->inf) 8/([1/{x*(1-(1-0.2)^(5.29/x))}]+12) = 62.3%

You are not totally wrong though! 1/N*p is a great approximation, but not quite for the reason you were thinking. (Though I happily admit it is still better here than the somewhat crappy 1 trial/s approximation I made!) You can simplify my full equation to get 1/N*p for small p and/or N/x. Use the Binomial Approximation that: (1-p)^(N/x) ~= 1-p*(N/x)
x*(1-(1-p)^(N/x)) ~= x*(1-(1-p*(N/x))) = x*(p*(N/x)) = p*N. Ta-da.

GilGalad wrote: »

I also thought about programming it but as you wrote the problem is to get all the coefficients for the different abilities including their global cooldowns. Even a perfect simulation would not match reality since a decent amount of dmg is done by weaving and player skill (perfect weaving, all dots perfectely refreshed, etc). All you can do here is to introduce a weaving coefficient that can be used to somehow simulate player skill, like I did in the spreadsheet.
The error from player skill will be bigger than the ability coefficient error you get by just taking a mean ability coefficient.

The perfect solution would be a real rotation simulation tool with an adjustable error rate, etc. but in that case it would be much easier to write a macro and let it perform the rotation in game automatically.

All very true. I was thinking I'd indeed have adjustable error rates for things like weaves and Moondancer uptimes, with suggestions as to reasonable values for each. E.g. a good player on console would likely hit maybe 75% uptime on Moondancer (you have to look for the dumb visual effect on console...) where a bad player'd have about 50%. I wouldn't expect it to be perfect of course, but rather good enough for the point of simple comparison assuming that the skill error would be approximately constant between sets.

And yes, I do play on console. Suppress your disgust, I know, I know. Haha. That's why I was thinking the code'd be nice too, since DPS testing can be a bit of a pain when you have to get a group to take to the Bloodspawn! Hopefully the Target Skeleton will talk me off of the ledge.

Ashamray · January 2017

del.

Asayre · January 2017

I actually finished programming a combat simulator. I wrote in Matlab and @Panth141 tried it out for a while. The rough idea I used is to create a priority cast list like
Shooting Star -> Blockade of Fire -> Force Pulse
And then put things on a periodic cast so you would only cast Blockade of Fire every 8 seconds. The interface is not well designed but works.

Skill coefficients are readily available. My error in damage calculation is usually within 5 points.

I have a basic stat page. Some of my inputs are a bit odd, I admit but its what I'm used to from my spreadsheets.

The second tab allows you to put your abilities in a priority. The script tries to pick the first castable skill from the list. Once it's cast the ability is not allowed to be cast for time, t_Period. The execute time, t_Execute, is the global cooldown. There is an option to LA weave with that skill or not. min health and max health are used to control when an ability can be casted. So I would put max health = 0.2 to start casting Mages Wrath at 20% for example. I haven't implemented SD yet for reasons that will soon become obvious but my intention was that would pick a number from a standard deviation to add to t_Period to simulate errors in rotation.

To the right there are periodic buffs and debuffs. In the example picture, a magicka potion (with Major Sorcery) is drank every 45 seconds starting at 0 seconds. The bottom is just target stats and where to save files.

The third tab outputs a single damage parse. You have a damage log and a damage summary. There are some buttons to open up graphs that plots your stats.

The final tab aggregates all the simulations and calculates statistics. Again there are some buttons to make plots of stats.

I'm pretty happy with it so far. I can simulate most commonly encountered DPS abilities. An excel spreadsheet of abilities I can simulate right now can be found here.

So I've been thinking of what I want to simulate and just messing around with convergence and simulation time. Below is a quick summary of my convergence and time test so far

Slimecraw simulations take about 7 seconds each while Bloodspawn takes around 39. Time taken should be linear to target health. Convergence is achieved in only 10 simulations! That surprised me a lot. But as expected, standard deviation scales as sqrt( Health) thus the standard deviation of Bloodspawn is ~ sqrt(5) smaller than Slimecraw.

In the images of my combat simulator above you might notice that for that particular simulation I predict a mean DPS of 40254 with a SD of 492. That's 1.2% which is a bit on the large side since some of the effects of interest are smaller than that. And those simulations initially took around 15 minutes. But then I use parallel computing in matlab and got them down to 6 ish minutes. I would ideally want a SD of 200 (at 40k DPS) so I would need the target health to be around 50 million which means each simulation would take 30 ish minutes. I was hoping to run simulations in the 5 - 15 minutes duration. (I don't like waiting ...) So this is why I haven't messed around with adding a standard deviation to t_Period. As an aside, I'm using a Core i5-3570k.

Slightly back on topic, I have two options for simulating Moondancer, which are already implemented, one is a smart synergiser which only synergises when you don't have the spell damage buff and another random synergiser which as the name suggest synergises every synergy. The number of available synergies is dictated by a periodic buff called 'Synergy' (panel 2)

So overall I find that while the simulation is nice, in order to get a nice low SD the simulation time has to be quite long. Perhaps I have to just deal with it and accept that things will take long and create batch simulation files before I sleep or something.

If you want to use the simulator feel free to PM me, I can compile it into a Windows executable. I don't have a Mac with Matlab so I can't compile to a Mac environment.

Edit:
SD - standard deviation

And for those who want some graphical representation of the results from the 4th panel. It's an older simulation thus the lower numbers but it shows a histogram of total DPS for 100 simulations and histograms for the top 9 damage dealing abilities. The top right shows the name and percentage contribution.

Ch4mpTW · January 2017

Asayre wrote: »

I actually finished programming a combat simulator. I wrote in Matlab and @Panth141 tried it out for a while. The rough idea I used is to create a priority cast list like
Shooting Star -> Blockade of Fire -> Force Pulse
And then put things on a periodic cast so you would only cast Blockade of Fire every 8 seconds. The interface is not well designed but works.

Skill coefficients are readily available. My error in damage calculation is usually within 5 points.

I have a basic stat page. Some of my inputs are a bit odd, I admit but its what I'm used to from my spreadsheets.

The second tab allows you to put your abilities in a priority. The script tries to pick the first castable skill from the list. Once it's cast the ability is not allowed to be cast for time, t_Period. The execute time, t_Execute, is the global cooldown. There is an option to LA weave with that skill or not. min health and max health are used to control when an ability can be casted. So I would put max health = 0.2 to start casting Mages Wrath at 20% for example. I haven't implemented SD yet for reasons that will soon become obvious but my intention was that would pick a number from a standard deviation to add to t_Period to simulate errors in rotation.

To the right there are periodic buffs and debuffs. In the example picture, a magicka potion (with Major Sorcery) is drank every 45 seconds starting at 0 seconds. The bottom is just target stats and where to save files.

The third tab outputs a single damage parse. You have a damage log and a damage summary. There are some buttons to open up graphs that plots your stats.

The final tab aggregates all the simulations and calculates statistics. Again there are some buttons to make plots of stats.

I'm pretty happy with it so far. I can simulate most commonly encountered DPS abilities. An excel spreadsheet of abilities I can simulate right now can be found here.

So I've been thinking of what I want to simulate and just messing around with convergence and simulation time. Below is a quick summary of my convergence and time test so far

Slimecraw simulations take about 7 seconds each while Bloodspawn takes around 39. Time taken should be linear to target health. Convergence is achieved in only 10 simulations! That surprised me a lot. But as expected, standard deviation scales as sqrt( Health) thus the standard deviation of Bloodspawn is ~ sqrt(5) smaller than Slimecraw.

In the images of my combat simulator above you might notice that for that particular simulation I predict a mean DPS of 40254 with a SD of 492. That's 1.2% which is a bit on the large side since some of the effects of interest are smaller than that. And those simulations initially took around 15 minutes. But then I use parallel computing in matlab and got them down to 6 ish minutes. I would ideally want a SD of 200 (at 40k DPS) so I would need the target health to be around 50 million which means each simulation would take 30 ish minutes. I was hoping to run simulations in the 5 - 15 minutes duration. (I don't like waiting ...) So this is why I haven't messed around with adding a standard deviation to t_Period. As an aside, I'm using a Core i5-3570k.

Slightly back on topic, I have two options for simulating Moondancer, which are already implemented, one is a smart synergiser which only synergises when you don't have the spell damage buff and another random synergiser which as the name suggest synergises every synergy. The number of available synergies is dictated by a periodic buff called 'Synergy' (panel 2)

So overall I find that while the simulation is nice, in order to get a nice low SD the simulation time has to be quite long. Perhaps I have to just deal with it and accept that things will take long and create batch simulation files before I sleep or something.

If you want to use the simulator feel free to PM me, I can compile it into a Windows executable. I don't have a Mac with Matlab so I can't compile to a Mac environment.

@Asayre Has anyone ever told you that you're like the Tony Stark of ESO? Lol. This is incredible. Why ZOS hasn't hired you, and replaced a certain someone with you (who's in charge of balance) is beyond me. Keep up the great work.

Saturn · January 2017

NightbladeMechanics wrote: »

Proc sets weren't nerfed for pve.

Considering the fact that all proc sets won't crit, the people that will suffer the most under this nerf will be PvE players, since it basically takes a dump on all damage proc monster sets. If you think it'll change anything in PvP, like ganking, prepare to be disappointed.

Just because the nerf was intended to change the state of PvP, it doesn't change the fact that it will ultimately affect PvE the most. That's the name of the game, when it comes to ESO nerfs. ZOS tries to fix something in PvP ---> *** over PvE in the process and somehow PvP doesn't change much.

Taonnor · January 2017

Saturn wrote: »

Just because the nerf was intended to change the state of PvP, it doesn't change the fact that it will ultimately affect PvE the most. That's the name of the game, when it comes to ESO nerfs. ZOS tries to fix something in PvP ---> *** over PvE in the process and somehow PvP doesn't change much.

The same issue went to destro ulti. The dmg of destro ulti was increased by 20% because of pve players wanted it compared with meteor (What failed). ZOS balancing hurts in both directions from patch to patch. So i can say ---> *** over PvP in the process and somehow PvE doesn't change much.

GilGalad · January 2017

Panth141 wrote: »

Hi @GilGalad !

4) Bonus test: are the above passives additive or multiplicative with execute bonuses? Given that the execute bonus typically fits into the base damage calculation pre-modifier, I would expect it to be multiplicative - but you never know with ZoS. I can test this myself on PTS, but it'd be nice to have a second person test, too!

Ok so I went ahead and did some more testing:
1. Sweeps
Sweeps are increased correctly by all dmg buffs. The bonus dmg on the nearest target is multiplicative with minor slayer, minor berserk and the lightning staff passive.

2. Executes:
Since radiant destruction is scaling linear it is quite hard to get nice numbers on it (oh I miss you unkillable NPCs). So the only skill I could test is the nightblade execute Impale and I found that the dmg bonis (staff, minor slayer, minor berserk) are added to the base dmg and are additive with the +300% below 25%. Therefore they have only 1/4 of the correct impact.
Data:

non crit 	
Basse:                                12574	
minor slayer:	                      12731,	1,25%
minor berserk	:                     12825,	2,00%
minor slayer + minor berserk:	      12982,	3,24%
Staff passive:	                      12825,	2,00%
minor slayer + Staff:	              12982,	3,24%
MS + MB + Staff:	              13233,	5,24%

All data can be found in the experiments tab in the Spreadsheet.

@ZOS_GinaBruno could you please forward this to the delevopers and also test the scaling of radiant destruction and maybe all other executes and passives like the dual wield one. These passives have a huge impact on the dmg especially for templars where the execute makes arround 20% of the total DPS. Missing 10% worth of bonus dmg on that one means loosing 2% overall DPS and thats huge.

GilGalad · January 2017

@Asayre:
Impressive work with your simulator!
Did you think about adding an error rate for the light attacks?
8k DPS from light attacks looks like perfect weaving to me!

Did you also think using it to simulate sets like burning spellweave and moondancer?
As far as I see it you can only put in constant set bonis. It would be really interesting to use it on order to test all sets and rotations in combination. Therefore you could test stuff like how much BSW uptime do you loose on a templar when you go with a lightning staff and lightning wall instead of an inferno staff, etc.

GilGalad · January 2017

Changed title back to the original one in order to match the content. I hope it does not confuse anyone.

Asayre · January 2017

I did think of adding an error rate to LA but I was so worried my standard deviations would increase I removed it XD

For the unusual sets, I have implemented the following so far

Scathing Mage - only procs of direct damage and all ticks of Twisting Path (in game it can proc off the first tick of all DoTs)
Burning Spellweave
Silks of the Sun
Moondancer Smart - only synergises if you don't have the spell damage buff
Moondancer Random - synergises all the time

The simulations you listed are possible at the moment

GilGalad · January 2017

Asayre wrote: »

I did think of adding an error rate to LA but I was so worried my standard deviations would increase I removed it XD

For the unusual sets, I have implemented the following so far
Scathing Mage - only procs of direct damage and all ticks of Twisting Path (in game it can proc off the first tick of all DoTs)

Burning Spellweave

Silks of the Sun

Moondancer Smart - only synergises if you don't have the spell damage buff

Moondancer Random - synergises all the time

The simulations you listed are possible at the moment

Well then let them run and share your results!

For the light attacks you could also add a correction factor of e.g. 0.90 to the base dmg. Then they might not match the individual hits, but the total contribution to DPS would be more in line with actual results.

Izaki · January 2017

Asayre wrote: »

I actually finished programming a combat simulator. I wrote in Matlab and @Panth141 tried it out for a while. The rough idea I used is to create a priority cast list like
Shooting Star -> Blockade of Fire -> Force Pulse
And then put things on a periodic cast so you would only cast Blockade of Fire every 8 seconds. The interface is not well designed but works.

Skill coefficients are readily available. My error in damage calculation is usually within 5 points.

I have a basic stat page. Some of my inputs are a bit odd, I admit but its what I'm used to from my spreadsheets.

The second tab allows you to put your abilities in a priority. The script tries to pick the first castable skill from the list. Once it's cast the ability is not allowed to be cast for time, t_Period. The execute time, t_Execute, is the global cooldown. There is an option to LA weave with that skill or not. min health and max health are used to control when an ability can be casted. So I would put max health = 0.2 to start casting Mages Wrath at 20% for example. I haven't implemented SD yet for reasons that will soon become obvious but my intention was that would pick a number from a standard deviation to add to t_Period to simulate errors in rotation.

To the right there are periodic buffs and debuffs. In the example picture, a magicka potion (with Major Sorcery) is drank every 45 seconds starting at 0 seconds. The bottom is just target stats and where to save files.

The third tab outputs a single damage parse. You have a damage log and a damage summary. There are some buttons to open up graphs that plots your stats.

The final tab aggregates all the simulations and calculates statistics. Again there are some buttons to make plots of stats.

I'm pretty happy with it so far. I can simulate most commonly encountered DPS abilities. An excel spreadsheet of abilities I can simulate right now can be found here.

So I've been thinking of what I want to simulate and just messing around with convergence and simulation time. Below is a quick summary of my convergence and time test so far

Slimecraw simulations take about 7 seconds each while Bloodspawn takes around 39. Time taken should be linear to target health. Convergence is achieved in only 10 simulations! That surprised me a lot. But as expected, standard deviation scales as sqrt( Health) thus the standard deviation of Bloodspawn is ~ sqrt(5) smaller than Slimecraw.

In the images of my combat simulator above you might notice that for that particular simulation I predict a mean DPS of 40254 with a SD of 492. That's 1.2% which is a bit on the large side since some of the effects of interest are smaller than that. And those simulations initially took around 15 minutes. But then I use parallel computing in matlab and got them down to 6 ish minutes. I would ideally want a SD of 200 (at 40k DPS) so I would need the target health to be around 50 million which means each simulation would take 30 ish minutes. I was hoping to run simulations in the 5 - 15 minutes duration. (I don't like waiting ...) So this is why I haven't messed around with adding a standard deviation to t_Period. As an aside, I'm using a Core i5-3570k.

Slightly back on topic, I have two options for simulating Moondancer, which are already implemented, one is a smart synergiser which only synergises when you don't have the spell damage buff and another random synergiser which as the name suggest synergises every synergy. The number of available synergies is dictated by a periodic buff called 'Synergy' (panel 2)

So overall I find that while the simulation is nice, in order to get a nice low SD the simulation time has to be quite long. Perhaps I have to just deal with it and accept that things will take long and create batch simulation files before I sleep or something.

If you want to use the simulator feel free to PM me, I can compile it into a Windows executable. I don't have a Mac with Matlab so I can't compile to a Mac environment.

Edit:
SD - standard deviation

And for those who want some graphical representation of the results from the 4th panel. It's an older simulation thus the lower numbers but it shows a histogram of total DPS for 100 simulations and histograms for the top 9 damage dealing abilities. The top right shows the name and percentage contribution.

This guy... Thank you so much for all the things you do.

CaptainPocky · January 2017

@Asayre:

Incredible stuff! That is great work!!
I assume you are having the program do a "perfect" rotation then? E.g. it casts the most damaging ability it can at each given second?

One thing I was thinking, and I'd be interested to hear your thoughts on it, is if you put in something like the following somewhat popular rotation:
Liquid Lightning --> Wall --> Trap (or Curse) --> Pulse/Frag x2 --> Curse --> Pulse/Frag x2 --> Curse
Then quickly calculate the total damage done for the rotation as a result of putting a point into each candidate champion point (Ele Expert, Thaumaturge, Elfborn, Staff Expert). Pick the highest number, iterate 188 more times -- and ta-da! You'd have the absolute optimal champ point setup for that rotation and gear. It'd be a bit more complicated of course depending on the set, but you get the idea.

(Note: I leave out spell pen mainly because in a top raid you'd already be pen-capped. Also there's that weird passive in the Ritual that give 10% bonus damage to off-balance enemies -- probably worth putting 75 into Thaumaturge for that alone if your healers are running Lightning Wall.)

Again, great work! It looks like you put a lot of effort into it!

Asayre · January 2017

@CaptainPocky,

I've approached CP optimisation in a different way. I have a website implementation of it.