Cataclysm Mage Simulators and Formulators - Page 10

SpartAdept · 01/27/11, 12:50 AM

Originally Posted by Lhivera

SpartAdept, was that chardev profile meant for Frost or Fire? From context I had got the impression you were talking about the Frost profile, but it appears the talents are set for Fire.

Fire, someone else had mentioned Frost, I never really specified, sorry.

Ektoplasme · 01/27/11, 2:17 AM

Originally Posted by Silverwind

Int/Hit is Purple unfortunately, so that's not an option.

I understand that being below the cap may be optimal from a DPS standpoint, but many of us have other assignments like interrupting/spellstealing too, so I think the BiS should include as much Hit as possible while not sacrificing any Int from sockets.

I corrected my post. Of course it's purple, so you would gem int/hit in a blue socket with a strong bonus. This doesn't invalidate my point.

And I think you are misunderstanding the purpose of BiS. The only parameter we optimize to find best in slot is the DPS. If you want to add a restriction (like being hit capped) then it is no longer strictly BiS. If you really want to know what would be a hitcapped BiS, please do it and publish it, but mention that it's not optimal and publish the real (maybe uncapped) BiS alongside.

mysteltainn · 01/27/11, 3:25 AM

Originally Posted by dedmonwakeen

I am ready to tackle Ignite in SimC. I have been combing EJ/WoW forums for data and some patterns are emerging. When trying to implement something with bizarre behavior I find the best place to start is understanding Blizzard's intent instead of just trying reverse-engineer the model from datasets.

I understand that "intent" is subjective, but I still think it is valuable exercise. So:
(1) A crit that occurs shortly after another crit should not be munched
(2) Refreshing Ignite should not defer ticks
(3) A crit that occurs while Ignite is ticking should not get its extra dmg accelerated too much.

By #3 I mean the following:
T0.0: Ignite starts ticking
T1.9: Pyroblast crits
T1.9: Fireblast crits
T2.0: Ignite tick occurs

If the crits at T1.9 gets rolled into the T2.0 tick then Blizzard would have significantly accelerated the total damage of Pyroblast and Fireblast.

Blizzard will often do bizarre things to prevent burst damage. There is probably a time-threshold between Crit-Time and Ignite-Tick-Time below which Blizzard chooses to defer the damage to the following two ticks, resulting in 4+ sec Ignite times. It is possible we get a divide-by-three scenario here. It is also possible that the imminent tick is simply unchanged and new crit damage is deferred to the following two ticks.

This is not an accurate description of ignite's behavior. Ignite's total damage is always divided evenly between all of its ticks. Ignite always has a maximum duration of 6s (or '>4s') and three ticks, into which the total damage pool is divided evenly, if it has been refreshed at least once on the target.

I assume you've read my posts on this topic: Fire Cataclysm Discussion: OP Updated for Release

I'd consider the 'Ignite's behavior is working as intended' postulation if ignite wasn't otherwise riddled with bugs or if the talent included a disclaminer to the effect of "Ignite may only trigger once every 2 seconds"; indeed, one of the considerations included was simultaneous crits - which have plagued ignite since its inception. I would consider ignite's problems to be sloppy implementation (a better one perhaps restricted by server resources) and latency. Strict simulation of ignite could be problematic because of the latter.

We understand that 4+sec Ignites can cause munching. However, what I have been unable to determine is which crit gets munched. When crit damage is deferred to the following two ticks what happens to subsequent crits that occur prior to the next tick? Are they munched or do they overwrite the previously deferred crit?

Simultaneous crits are munched as they've always been. The second recorded crit is the only one considered when ignite refreshes.

However, an interesting bug arises when simultaneous crits occur on a target without ignite: the resulting ignite ticks as hard as if it was a 4s ignite (damage pool divided by two ticks) but it ticks three times at that amount (resulting an ignite that does 50% more damage than expected). Probably caused by simultaneous "Ignite applied to Target" events firing - and suggesting to me that ignite tick damage and debuff duration are independently calculated.

If you want to simulate absolutely everything about ignite, there's also another bug that you might consider (one iteration gives a 'free' ignite tick, the other drops 2/3 of a crit's damage pool - both caused by similar event sequences) but it's heavily based on latency and the damage gained/lost may be inconsequential.

dedmonwakeen · 01/27/11, 11:09 AM

Apparently, I did not search far enough back in time. That was a very helpful post.

More recent conversations seem to imply that simultaneous crits were not munched specifically, but were more vulnerable to the refresh-munch mechanic: Cataclysm Fire Mage Compendium

The always-divide-by-three mechanic would fit well in Blizzards desire to mitigate burst scenarios where possible.

SimC currently models munching (and rolling) by adding a random delay between the calculation of the ignite bank and the actual refresh mechanic. When crits occur close together the second one is working with "stale" data, essentially "munching" the previous one. When a crit occurs right before Ignite fades, the damage in the last tick gets rolled into the new Ignite.

EDIT: Implementing the "three-tick" ignite and the munching due to lost refreshes on 4+sec Ignites brought Ignite dmg down from 23% of total to 16% of total. It also put Fire in an unfavorable light compared to Arcane/Frost which was surprising. The PTR changes bring Fire almost all the way back, but not quite.

EDIT2: There is a now a "max_refresh_duration" option that defaults to 4.0 seconds. I'll push a release so folks can play.

mysteltainn · 01/27/11, 7:02 PM

Originally Posted by dedmonwakeen

Apparently, I did not search far enough back in time. That was a very helpful post.

More recent conversations seem to imply that simultaneous crits were not munched specifically, but were more vulnerable to the refresh-munch mechanic: Cataclysm Fire Mage Compendium

I have not seen a single log that supports this - the example you linked was better explained by the scenario I proposed (ignite tick damage being independent of duration), but it's hard to tell because the mage's mastery at the time is unknown.

The always-divide-by-three mechanic would fit well in Blizzards desire to mitigate burst scenarios where possible.

I would say it's a technical limitation of ignite doing damage directly based on spells and the recent change to a new system of 'unclippable' dots. Regardless, intent is moot - I would suggest looking for patterns in logs since we both know the occasional discrepancy between intent and execution.

SimC currently models munching (and rolling) by adding a random delay between the calculation of the ignite bank and the actual refresh mechanic. When crits occur close together the second one is working with "stale" data, essentially "munching" the previous one. When a crit occurs right before Ignite fades, the damage in the last tick gets rolled into the new Ignite.

These are more or less the bugs I alluded to at the end of my last post.

EDIT: Implementing the "three-tick" ignite and the munching due to lost refreshes on 4+sec Ignites brought Ignite dmg down from 23% of total to 16% of total. It also put Fire in an unfavorable light compared to Arcane/Frost which was surprising. The PTR changes bring Fire almost all the way back, but not quite.

EDIT2: There is a now a "max_refresh_duration" option that defaults to 4.0 seconds. I'll push a release so folks can play.

What's the length/range of the random delay? Perhaps those latency-based-bugs are occuring more often in this simulation than in practice.

Lhivera · 01/27/11, 10:10 PM

I have begun a run to update the output in the usual location. I have updated the 372 profiles for the PTR only, using SpartAdept's Fire profile (and copying its gear list for Frost -- so far I haven't been able to improve upon it) and Silverwind's for Arcane. Give it 30-60 minutes and results should start getting updated.

dedmonwakeen · 01/27/11, 10:20 PM

The aura delay used for Ignite modeling is a gaussian distribution centered at 400ms with a stddev of 100ms.

However, the majority (by far) of Ignite munches (in-sim) are due to the duration refresh limit.

Silverwind · 01/28/11, 2:08 AM

Originally Posted by Lhivera

I have begun a run to update the output in the usual location. I have updated the 372 profiles for the PTR only, using SpartAdept's Fire profile (and copying its gear list for Frost -- so far I haven't been able to improve upon it) and Silverwind's for Arcane. Give it 30-60 minutes and results should start getting updated.

Very interesting results.

Fire: Seems like the sim uses Scorch just to keep Critical Mass up now, so scorch weaving will be a thing of the past because Fire can sustain it's mana now forever with evocation. Ignite Munching seems to be much closer to real logs now.

Arcane: The sim now uses the mirror image glyph, but I think it isn't modelled correcty. Here's how Arcane Blast from images works: The images cast ABs and gain their own AB debuffs. But their own debuff doesn't do anything, it' actually the mage's AB debuff which matters, so if the mage is at 4 stacks of glyphed AB, the images gain the full 52% damage buff. Arcane Power works on them, too.

I'll still have to experiment with different approaches on how to react to Bloodlust in the Arcane action list, there could be possibly more small gains. But otherwise, Arcane seems pretty optimized.

Edit: Found a small mistake: Arcane 359 uses AB4 in conserve mode, while it should be using AB3 without the Shard of Woe (also during Bloodlust).

Nathyiel · 01/28/11, 5:03 AM

When I see the mana line on Frost and the uptime of Molten Armor, I think that things can be optimized. In the Action List, we can change:

mage_armor,if=mana_deficit>80000
molten_armor,if=mana_deficit<25000&buff.molten_armor.down
molten_armor,if=mana_deficit>80000&(buff.bloodlust.react|buff.icy_veins.react|target.time_to_die<=40)
mage_armor,if=mana_deficit>40000&(buff.bloodlust.down|buff.icy_veins.down|target.time_to_die>40)

With this, we have Molten armor for the start, burst phase and if you have ~75% of your mana max. It switch to Mage armor if we are under 60% mana and if we aren't in a burst phase. I think it's secure for not to be OOM.

edit: I don't have time for testing it before sunday

SpartAdept · 01/28/11, 5:15 AM

The Fire Ptr 372 sim devalues crit extremely, the meta gem 'seems' to be active, but something must be off somewhere, that doesn't make much sense.

• Wizeowel · 01/28/11, 6:05 AM

The 359 set doesn't put haste over crit Simulationcraft Results. Is the 372 set reaching some kind of haste apex?

Originally Posted by Lhivera

I have updated the 372 profiles for the PTR only, using SpartAdept's Fire profile

Or did you mean "I have updated only the 372 profiles ..."?

Edit2: My bad then, I saw yesterday's date also on the 359 set and assumed it was similarly updated.

Power · 01/28/11, 6:40 AM

PTR-Frost:

actions+=/mage_armor,if=mana_pct<20
#actions+=/evocation,if=mana_pct<5&target.time_to_die>60 (never use evocation)

This will improve Frosts DPS by ca. 100.

PTR-Frost-Frostfire:

glyphs=molten_armor/deep_freeze/frostfire

actions+=/mage_armor,if=mana_pct<5
#actions+=/evocation,if=mana_pct<5&target.time_to_die>60 (never use evocation)

This will improve Frost-Frostfires DPS by ca. 500.

PTR-Fire-Frostfire-Fireball:

glyphs=molten_armor/frostfire/fireball

actions+=/frostfire_bolt,if=dot.frostfire_bolt.remains<6
actions+=/scorch,if=mana_pct<5
actions+=/fireball,if=target.time_to_die<60
actions+=/fireball,if=mana_pct>39

This will do ca. 250 more DPS then normal Fire-Frostfire.

PTR-Fire:

head=crown_of_the_twilight_queen,heroic=1,type=cloth,ilevel=379,quality=epic,stats=1136armor_264crit_244haste_351int_617sta,reforge=crit_hit,gems=chaotic_shadowspirit_20hit_20int_30int,enchant=60int_35crit
neck=valionas_medallion,heroic=1,ilevel=372,quality=epic,stats=143haste_215int_143mastery_322sta,reforge=mastery_hit
shoulders=firelords_mantle,heroic=1,type=cloth,ilevel=372,quality=epic,stats=1009armor_191haste_171hit_266int_429sta,reforge=haste_crit,gems=20hit_20int_10haste,enchant=50int_25haste
shirt=thug_shirt,ilevel=1
chest=firelords_robes,heroic=1,type=cloth,ilevel=372,quality=epic,stats=1346armor_247crit_227haste_345int_578sta,reforge=haste_hit,gems=40int_20hit_20int_20int,enchant=20all
waist=belt_of_arcane_storms,heroic=1,type=cloth,ilevel=372,quality=epic,stats=757armor_171crit_191haste_266int_429sta,reforge=haste_hit,gems=40int_40int
legs=firelords_leggings,heroic=1,type=cloth,ilevel=372,quality=epic,stats=1177armor_257haste_217hit_345int_578sta,gems=20crit_20int_40int_20int,enchant=95int_80sta
feet=einhorns_galoshes,heroic=1,type=cloth,ilevel=372,quality=epic,stats=925armor_191haste_266int_171mastery_429sta,reforge=mastery_hit,gems=40int_10haste,enchant=50hit
wrists=bracers_of_the_bronze_flight,heroic=1,type=cloth,ilevel=372,quality=epic,stats=589armor_143haste_215int_143mastery_322sta,reforge=mastery_hit,enchant=40int
hands=firelords_gloves,heroic=1,type=cloth,ilevel=372,quality=epic,stats=841armor_171crit_266int_191mastery_429sta,reforge=mastery_hit,gems=40int,enchant=50haste
finger1=planetary_band_of_the_wildfire,heroic=1,ilevel=372,quality=epic,stats=321sta_214int_143hit_143crit,suffix=129
finger2=signet_of_the_fifth_circle,heroic=1,ilevel=372,quality=epic,stats=143haste_215int_143mastery_322sta,reforge=mastery_hit
trinket1=bell_of_enraging_resonance,heroic=1,ilevel=372,quality=epic,stats=363crit,reforge=crit_haste,equip=onspellcrit_2178sp_30%_20dur_100cd
trinket2=darkmoon_card_volcano,ilevel=359,quality=epic,stats=321mastery,reforge=mastery_hit,equip=onspelldamage_1200+10fire_1600int_30%_12dur_45cd
back=shroud_of_endless_grief,heroic=1,ilevel=379,quality=epic,stats=699armor_133haste_209int_153mastery_344sta,reforge=mastery_hit,gems=20crit_20int_10int,enchant=lightweave_embroidery
main_hand=stormwake_the_tempests_reach_of_the_wildfire,heroic=1,ilevel=372,quality=epic,stats=2207sp_247sta_165int_110hit_110crit,enchant=power_torrent,weapon=sword_1.60speed_73min_137max,suffix=129
off_hand=book_of_binding_will,heroic=1,ilevel=372,quality=epic,stats=143haste_143hit_215int_322sta,enchant=40int
ranged=theresas_booklight,ilevel=359,quality=epic,stats=72hit_107int_72mastery_161sta,reforge=mastery_crit

This will improve Fires DPS by ca. 150.

Lhivera · 01/28/11, 7:38 AM

I updated only the *_T11_372_PTR profiles; was all I had time for last night.

Nathyiel, did you try out that change, and was it effective?

Power: I'll try out those first three adjustments tonight. Any chance you can provide a diff on the fourth? Would make it much easier to tweak the source chardev profile to match. Or better yet, click through the results to the chardev profile, adjust it, and save a copy, and point me at it; I can then just download your changes.

ETA: There is guaranteed to be some major skepticism from people about the Arcane results. Some focused examination of them to see if anything looks wrong would be good.

elluminea · 01/28/11, 7:47 AM

Originally Posted by Wizeowel

The 359 set doesn't put haste over crit Simulationcraft Results. Is the 372 set reaching some kind of haste apex?

I'm getting an error trying to access the gear profile of that 359 set, but from the stats table it shows it is not hit capped, and has a... strange... spread of secondary stats, given the stat weights taken for granted until these results showed up. If I had to guess I'd say reforging wasn't accounted for in the profile, and that may not be giving the desired output.

As for new plateaus, the 372 set lists 1527 haste rating on gear, which is sitting in a large gap between a second and third combustion tick, something like 811 and 1995 ratings. I can't imagine simcraft values the one tick of combustion over 480ish crit.

Maje · 01/28/11, 8:01 AM

It looks like the new Ignite modeling is very close to the real world results, although slightly below the real values. Most of the logs (single target) show Ignite doing about 10% more damage than Living Bomb.

This is probably tweakable via the aura_delay option.