EnhSim, DPS simulator - Page 183

Extenze · 11/23/09, 12:53 PM

Using the same config as Jessamy. 10k hour sims
edit: Wouldn't it be more helpful to find the high-low rather than the stdev?
edit2: you're correct, I'll figure it out

edit3: Alright I figured out the issue with the config files. My regular expression is matching a decimal value, and if the original config.txt has a 0 for the combat_length_rng_factor then my expression doesn't return an array and thus doesn't get edited. So, don't have it = 0. I'll add some error checking on that.
edit4: I just made the decimal not mandatory, I'll have a new build up after I'm done simming. 159m left

• Jessamy · 11/23/09, 1:28 PM

Extenze, are you sure your rng is changing? Your numbers seem to all be the same as the 0% case. Try opening up config0.15.txt (or whatever) and check the combat_length_rng_factor line. To produce my output I manually edited that line.

Extenze · 11/23/09, 5:43 PM

I double checked this time. 10k hour simulations with the BIS config.

Revision 7
*Added: Added a file open dialogue to find config.txt easier
*Fixed: fixed derivative configs not updating combat_length_rng_factor

I'm also gonna work on auto setting cpu affinities so I can get this done 2x as fast.

Variance %	Data	Data	Data	Data	Data	Data	Data	Data	Data	Data	Std Deviation
0	9358.89	9360.55	9360.05	9360.13	9359.05	9359.7	9360.62	9361.28	9361.6	9361.2	0.92
0.05	9375.89	9375.56	9376.53	9375.32	9374.53	9375.39	9375.8	9375.28	9374.83	9374.19	0.69
0.1	9378.28	9378.29	9378.68	9379.47	9378.36	9379.22	9379.39	9377.87	9378.32	9379.09	0.56
0.15	9376.36	9377.09	9378.44	9377.07	9376.44	9376.11	9376.77	9376.55	9377.67	9377.18	0.69
0.2	9377.81	9376.49	9375.91	9377.71	9376.88	9376.61	9376.35	9377	9376.1	9377.78	0.7
0.25	9378.18	9378.71	9377.89	9377.62	9378.01	9378.37	9379.07	9377.68	9377.84	9378.45	0.47
0.3	9383.45	9381.71	9382.54	9384.37	9383.08	9384.35	9383.61	9383.39	9383.88	9383.73	0.81
0.35	9387.08	9386.04	9387.59	9387.84	9386.41	9387.71	9386.11	9387.52	9387.18	9387.84	0.7
0.4	9386.13	9386.65	9387.61	9386.46	9387.07	9387.66	9387.28	9386.1	9387.99	9386.85	0.66
0.45	9386.25	9385.88	9384.84	9385.61	9384.99	9385.97	9386.12	9384.51	9386.67	9384.51	0.77
0.5	9385.02	9384.74	9383.81	9384.85	9383.97	9384.94	9384.57	9383.64	9383.66	9384.34	0.54
0.55	9386.14	9384.98	9383.3	9384.91	9384.54	9384.34	9383.76	9384.12	9382.23	9384.5	1.05
0.6	9386.46	9386.65	9387.22	9385.85	9386.23	9386.11	9386.24	9386.09	9386.47	9384.75	0.64
0.65	9389.82	9387.69	9388.24	9387.47	9387.18	9389.05	9388.39	9388.38	9388.36	9387.69	0.78
0.7	9387.73	9388.47	9388.55	9387.69	9389.14	9389.35	9388.18	9387.82	9388.9	9387.12	0.71
0.75	9387.71	9386.58	9386.11	9387.38	9387.01	9386.93	9387.7	9387.19	9386.15	9387.98	0.65
0.8	9385.88	9385.9	9386.57	9387.25	9385.55	9386.99	9386.75	9387.26	9385.99	9386.46	0.61
0.85	9385.7	9386.02	9385.43	9384.63	9386.15	9386.89	9388.01	9386.12	9385.37	9386.55	0.93
0.9	9385.62	9385.75	9387.51	9387.89	9387.26	9387.74	9385.88	9386.74	9386.51	9388.04	0.92
0.95	9387.98	9388.65	9389.05	9387.45	9387.63	9388.5	9389.48	9387.42	9389.59	9389.62	0.91
1	9386.63	9386.6	9385.97	9385.2	9388.44	9387.09	9386.15	9387.5	9387.07	9387.39

Levva · 11/23/09, 6:33 PM

Guys for these tests PLEASE use more than one config.txt you are getting large samples on the data which is great but if that only holds true for that file and is completely different for other files we are screwed.

Please use the default config.txt file as supplied in the download + say 3 or 4 random Enh Shammy's. Please note the BiS thread config.txt file is invalid as its a v1.7.0 config file.

Rouncer · 11/23/09, 6:50 PM

Also could you start formating the data as a table before I go blind trying to look for truth inside those walls of numbers.

[ table ] and use | for breaks between data points and hit enter for the next line of the table

Maybe something like this:

Variance %	Data	Data	Data	Data	Data	Data	Data	Data	Data	Data	Std Deviation
0	9358.89	9360.55	9360.05	9360.13	9359.05	9359.7	9360.62	9361.28	9361.6	9361.2	0.92
0.05	9375.89	9375.56	9376.53	9375.32	9374.53	9375.39	9375.8	9375.28	9374.83	9374.19	0.69
0.1	9378.28	9378.29	9378.68	9379.47	9378.36	9379.22	9379.39	9377.87	9378.32	9379.09	0.59

Or just skip the Table=head part and have your script output swap all the commas for | then you could just copy/paste the output between [ table ] and [ /table ] and it would be far more legible and easy to comprehend.

Levva · 11/24/09, 10:08 AM

Graphing it makes it easier to see...

From zero theres a sharp rise at 5%, a levelling off between 5% and 30% then a sharp rise again at 35% which remains fairly constant thereafter.

This is the source of my concern. I'm wondering if the sharp rises are nothing more than haste sweet spots for that specific config file. If it can be re-run for other characters.

eg: Levva, Khadgar, EU
Rouncer, Mal'Ganis, US
Barawr, Blade's Edge, US

NB. v1.9.0.0 of EnhSim will be released in around 2 hours, so better using that and it's config file as a fresh baseline.

[Edit]: v1.9.0.0 now released

Rouncer · 11/24/09, 2:04 PM

So I started playing with 1.9 and it seems that haste is gaining even more value with the introduction of Fire Nova because of GCD starvation (e: scratch most of that - seems to be an issue with Magma Totem refreshment - move that to a much higher priority and haste drops down to a more normal level. Most likely due to the inability to refresh Magma Totem early in the Sim).

Would it be possible to add a "cleave" option to EnhSim? So that it would run the simulations with a primary target and a selectable number of additional targets? Maybe lock that option to 10 at most so the AoE cap wouldn't have to be incorporated (or just don't lock it but have it throw an error to the board saying that the results will be inaccurate due to the AoE cap)?

I'd love to be able to work out better priorities/rotation for fights like Twins or Anub.

Shammiewow · 11/24/09, 4:42 PM

Is there any kind of recommendation about how to run Enhsim to limit run-to-run variance?

I'm running 1.8.5.2, using 10,000 hours, and even with that I'm seeing DPS numbers running from 6893 to 6921, using the same set-up. Should I use an even longer sim?

I understand that Haste can be odd, but my Shammie is not a high-haste build, so I would think that the effects would be lessened.

It's hard to evaluate gear and talent choices when the Sim numbers bounce around so much from run to run.

Extenze · 11/24/09, 5:46 PM

I left it running 20k simulations when I went to sleep, it took 5h45m D:
This is using my characters setup.

20,000 hours

10000

5000 hours

I also made another revision, but didn't feel like posting till I had the graphs done. I'm finishing off my 10k simulation atm, it should take an hour. Although I doubt it'll be any different, the 5k and 20k are pretty much identical.

Revision 8
*Added: EJ Table formatting, It's now completely copy-paste friendly. You will have to manually add STDEV values, however.
I did include that column in the header.
*Added: Hours to time estimation
*More tuning

Levva · 11/24/09, 7:41 PM

@Shammiewow

We really cannot help unless you post your config.txt file. BTW please use v1.9.0.0 to see if that makes a difference.

@Rouncer

Yes I suspect that MT needs to be a lot higher in the priority - on testing on the PTR it just felt that way too often MT wasn't down. The new values in the sim show the fire totem uptime so it should be easy to test this theory.

Re: "Cleave"

1) Lets not call it that, way too much confusion

2) Are you basically thinking "Additional targets" and that all that is calculated is the extra dps to these additional targets?

If so perhaps we have simply an additional output line for "additional target AOE damage" and only AoE damage skills are affected ie: Magma totem, Fire Nova, Fire Elemental (Fire Nova), Chain Lightning. ie: these damage abilities have an extra tracking value for "additional_aoe_damage".

Config parameters could be "additional_targets" with as you suggest a default of zero and a max of 10. Would it be an idea to have a "additional_target_presence" which would be a percentage. 100% would be like twins where the targets are always present and say 40% for Anub? I'd see this as implements with a random factor, if ability is AoE and roll <= additional_target_presence then add damage multiplied by additional_targets to additional_aoe_damage.

This would give a non patchwerk style couple of parameters to play with.

BTW verification of FN spellpower co-efficient is required. I used the figure on wowwiki and not sure its up to date.

Rouncer · 11/24/09, 8:14 PM

Originally Posted by Levva

Re: "Cleave"

1) Lets not call it that, way too much confusion

2) Are you basically thinking "Additional targets" and that all that is calculated is the extra dps to these additional targets?

If so perhaps we have simply an additional output line for "additional target AOE damage" and only AoE damage skills are affected ie: Magma totem, Fire Nova, Fire Elemental (Fire Nova), Chain Lightning. ie: these damage abilities have an extra tracking value for "additional_aoe_damage".

Config parameters could be "additional_targets" with as you suggest a default of zero and a max of 10. Would it be an idea to have a "additional_target_presence" which would be a percentage. 100% would be like twins where the targets are always present and say 40% for Anub? I'd see this as implements with a random factor, if ability is AoE and roll <= additional_target_presence then add damage multiplied by additional_targets to additional_aoe_damage.

This would give a non patchwerk style couple of parameters to play with.

BTW verification of FN spellpower co-efficient is required. I used the figure on wowwiki and not sure its up to date.

Probably don't need to get that complicated to actually work it by percentage of presence. Wouldn't really be that useful in this circumstance since your priority list should be different when you have multiple targets versus just a single target. Which is actually the reason why we now need this since our priorities actually can affect our AoE damage potential. So just adding an option to specify additional targets are present (and those only being affected by Chain Lightning, Magma and Fire Nova damage) with a value between 1 and 10 would be ideal.

Also would probably be a good idea to add an option to control the refresh time on Magma - so that we could say refresh based on priority provided there was 10 (or whatever value is specified) seconds or less on the timer. Set up the option similar to how it handles Lightning Shield or FS except based on time instead of ticks or charges.

Totentanz · 11/25/09, 2:27 AM

Originally Posted by Rouncer

Would it be possible to add a "cleave" option to EnhSim? So that it would run the simulations with a primary target and a selectable number of additional targets? Maybe lock that option to 10 at most so the AoE cap wouldn't have to be incorporated (or just don't lock it but have it throw an error to the board saying that the results will be inaccurate due to the AoE cap)?

I'd love to be able to work out better priorities/rotation for fights like Twins or Anub.

please add, maybe under:

EnhSim - View Issue #4968: Add more Boss parameters

Rouncer · 11/25/09, 9:05 AM

Originally Posted by Totentanz

please add, maybe under:

EnhSim - View Issue #4968: Add more Boss parameters

This comment added to that thread

Keep it simple since there is no reason to have the sim model every aspect of a combat encounter.

Things that are definite necessities
- option to simulate additional targets that would only be affected by Magma Totem, Fire Nova and Chain Lightning
- option to control when the simulator will refresh Magma Totem. Current system only refreshes when the totem expires which means no clipping of ticks but does mean there will be time where the totem won't be active. Option should let the user select the minimum number of seconds remaining before it will try to refresh the totem based on your priority list)

Things that would be nice but are not required
- percentage of time behind target. Would be nice to see if expertise does have value past the dodge cap for specific encounters.
- percentage of time in melee range. Would be nice to see if AP is valued higher then Haste when there are periods of time where the only action possible is shocking. Ideally it would only be modeling times when have to run out for regularly defined AoE attacks from the primary target. So basically would be random sporadic short periods of time (say 5 second windows) where no melee would be possible but shocking and using MW4/5 would be possible.

Anything more complicated falls into the realm of fluff and really isn't necessary or useful. That melee range percentage is pretty much already in that category and the time behind the target is pretty close as well. Considering it would require very specific encounters that would make us want to gear differently based on findings from those parameters. The multiple target thing was mostly fluff before 3.3 but with Fire Nova entering the picture it may have a large effect on our priorities when there is more then one target and the sim would be very helpful in working them out.

Levva · 11/25/09, 9:41 AM

I've actually posted two new issues EnhSim - View Issue #5501: Magma time left option and EnhSim - View Issue #5500: AoE damage with specifics of how we could possibly quickly implement these issues.

I'll leave it to those that know the C++ better than I to implement though as I tried to implement Black Magic enchant the other day and the result was the sim just hung in some sort of loop

Slowly getting to understand C++ wierdnesses but its taking time.

Rouncer · 11/25/09, 9:49 AM

Originally Posted by Levva

I've actually posted two new issues EnhSim - View Issue #5501: Magma time left option and EnhSim - View Issue #5500: AoE damage with specifics of how we could possibly quickly implement these issues.

I'll leave it to those that know the C++ better than I to implement though as I tried to implement Black Magic enchant the other day and the result was the sim just hung in some sort of loop

Slowly getting to understand C++ wierdnesses but its taking time.

I saw your issues and made comments and then escalated them both so hopefully someone will work on them for the next release.