Elitist Jerks Cataclysm Mage Simulators and Formulators

 01/18/12, 4:35 AM #421 Kavan Bald Bull   Kavan Gnome Mage   Kilrogg Ok I have some initial results. First some words on the methodology I used. For a given set of gear I first perform a long simulation collecting data on distribution of combustion damage conditions. For computation of optimal policy I then assume this distribution is stationary. This wouldn't be strictly necessary, but not doing so would probably make it take way too long to do simulations at policy level. I then discretize this data to facilitate easier computations later and generate pdf and cdf of the distribution. The cdf is displayed in the charts shown below and means for a given combustion size what is the likelihood at any random point in time that using combustion at that point would be that much or lower. Second part is then using this distribution data to generate optimal combustion use policy. The policy is computed at a 60 second window in 1 sec interval precision. For each time point it gives a combustion size, saying if you're x seconds since combustion got off cooldown, what is the minimum condition to use combustion at that point in time. The policy is then optimized under stationary conditions. This means I compute the average dps of combustion in an infinitely long fight. Optimizing for fixed fight length might be possible, but way too complex for this initial study. Given the policy and combustion conditions distribution we can compute expected combustion damage and expected time till combustion is used. The average dps is then E(damage) / (cooldown + E(time)). First a comparison between average combustion dps for a set of crit/haste builds I had on hand using 2T13. This is just comparing expected combustion dps, not taking into account other effects crit/haste has on other spells. The policy shows the curve of minimum conditions of when to use combustion, with time going from 0 in the bottom to 60 on top. There's still some room for polishing the policies, but I think it's a good first result. The numbers in lower left corner are expected dps of combustion. 2T13, 1739 haste, 2004 crit 2T13, 2831 haste, 896 crit Some rough observations would say that this model makes crit build at least in this case slightly more favorable compared to current default combustion model used in calculations, but the difference doesn't seem to be very big. And another nonrelated 4T13 set example. 4T13, 1772 haste, 2009 crit
 01/18/12, 6:01 AM #422 Kavan Bald Bull   Kavan Gnome Mage   Kilrogg Just found an example of current ignite free tick (1.3443 flashburn): [20:19:33.535] Delritha Fireball Yor'sahj the Unsleeping *52419* [20:19:33.986] Yor'sahj the Unsleeping afflicted by Ignite from Delritha [20:19:35.421] Delritha Fireball Yor'sahj the Unsleeping *52936* [20:19:36.084] Yor'sahj the Unsleeping's Ignite is refreshed by Delritha [20:19:36.093] Delritha Ignite Yor'sahj the Unsleeping 18884 [20:19:37.331] Delritha Fireball Yor'sahj the Unsleeping *52309* [20:19:38.005] Yor'sahj the Unsleeping's Ignite is refreshed by Delritha [20:19:38.110] Delritha Ignite Yor'sahj the Unsleeping 21965 [20:19:38.666] Delritha Pyroblast! Yor'sahj the Unsleeping *65648* [20:19:39.165] Yor'sahj the Unsleeping's Ignite is refreshed by Delritha [20:19:40.070] Delritha Ignite Yor'sahj the Unsleeping 26410 [20:19:42.047] Delritha Ignite Yor'sahj the Unsleeping 26410 [20:19:43.186] Delritha Fireball Yor'sahj the Unsleeping *52972* [20:19:43.613] Yor'sahj the Unsleeping's Ignite is refreshed by Delritha [20:19:43.978] Delritha Ignite Yor'sahj the Unsleeping 18298 [20:19:44.361] Delritha Fireball Yor'sahj the Unsleeping *52912* [20:19:44.819] Yor'sahj the Unsleeping's Ignite is refreshed by Delritha [20:19:45.166] Delritha Fireball Yor'sahj the Unsleeping *52560* [20:19:45.427] Delritha Pyroblast! Yor'sahj the Unsleeping *65370* [20:19:45.616] Yor'sahj the Unsleeping's Ignite is refreshed by Delritha [20:19:45.982] Delritha Ignite Yor'sahj the Unsleeping 31103 [20:19:46.032] Yor'sahj the Unsleeping's Ignite is refreshed by Delritha [20:19:47.994] Delritha Ignite Yor'sahj the Unsleeping 42820 [20:19:48.205] Delritha Pyroblast! Yor'sahj the Unsleeping *66018* [20:19:48.828] Yor'sahj the Unsleeping's Ignite is refreshed by Delritha [20:19:50.017] Delritha Ignite Yor'sahj the Unsleeping 40380 [20:19:52.016] Delritha Ignite Yor'sahj the Unsleeping 40380 [20:19:54.003] Delritha Ignite Yor'sahj the Unsleeping 40380 [20:19:54.003] Delritha's Ignite fades from Yor'sahj the Unsleeping Free tick is the one at 20:19:45.982, everything else is clean. The question now is what makes this case different from the ones before. I've tried going through what simc would do with this case, but I'm not quite sure I understand the relation between ignite bank and refreshes used there.
 01/18/12, 8:54 AM #423 Aantu Glass Joe   Aantu Worgen Mage   Korgath When I was looking through logs a while ago it seemed as though ignite rolling depended not on a tick falling between a crit and a refresh, but rather the proximity of the refresh to the tick. For example, a crit that occurred right before an ignite tick (say, less than .2 seconds before) and the subsequent ignite refresh .5 seconds or so later would not initiate a free tick, even though the tick did in fact fall between a crit and a refresh. This is extremely anecdotal, though, and I plan to test the precise conditions for ignite rolling as soon as possible, but I have been a little busy lately. This is something to think about for anyone willing to look into it until then.
 01/18/12, 1:15 PM #424 Esarael Von Kaiser   Esarael Blood Elf Mage   Azralon It depends on the duration remaining on Ignite (and thus, the Ignite damage "left" on the bank) when the crit happens. The mechanics are still not entirely clear, as Kavan has pointed out with his findings, but surely you can remember those monstrous ignites on Alysrazor.
01/18/12, 6:48 PM   #425
Kavan
Bald Bull

Gnome Mage

Kilrogg
Ok I spent some time debugging simc to get really intimate with how it processes ignite. Here is how it works currently. It stores ignite bank data in the ignite on the target in the form of tick size and number of ticks. When a spell crits it uses current remaining ticks on active ignite and its tick size to determine bank size and adds that value to what would be the ignite bank of the spell that just crit. It then triggers travel event for ignite and stores the computed ignite bank in it. When ignite lands it refreshes tick size based on the ignite bank size stored in the travel event. So at any point in time there is the ignite bank on the ticking ignite and potentially a few in the travel events queued up.

Now lets see what would happen with the above mechanics under the previously posted event sequence.

 timestamp ignite tick size current tick num ticks travel bank 1 travel bank 2 20:19:33.535 28187 20:19:33.986 14093 0 2 20:19:35.421 14093 0 2 56651 20:19:36.084 18884 0 3 20:19:36.093 18884 1 3 20:19:37.331 18884 1 3 65896 20:19:38.005 21965 0 3 20:19:38.110 21965 1 3 20:19:38.666 21965 1 3 79230 20:19:39.165 26410 0 3 20:19:40.070 26410 1 3 20:19:42.047 26410 2 3 20:19:43.186 26410 2 3 54894 20:19:43.613 18298 0 3 20:19:43.978 18298 1 3 20:19:44.361 18298 1 3 65048 20:19:44.819 21683 0 3 20:19:45.166 21683 0 3 93312 20:19:45.427 21683 0 3 93312 100200 20:19:45.616 31103 0 3 100200 20:19:45.982 31103 1 3 100200 20:19:46.032 33400 0 3 20:19:47.994 33400 1 3 20:19:48.205 33400 1 3 102299 20:19:48.828 34100 0 3 20:19:50.017 34100 1 3 20:19:52.016 34100 2 3 20:19:54.003

We can see that it does not correctly model the behavior. The wrong part is the munching of consecutive crits before ignite gets refreshed. It appears that munching does not appear in that case. If instead ignite bank was stored separate from ignite tick and updated immediately upon crit and on ignite ticks, as well as updated from travel, we would get the behavior as seen in the log.

 timestamp ignite tick size current tick num ticks ignite bank travel bank 1 travel bank 2 20:19:33.535 28187 20:19:33.986 14093 0 2 28187 20:19:35.421 14093 0 2 56651 56651 20:19:36.084 18884 0 3 56651 20:19:36.093 18884 1 3 54767 20:19:37.331 18884 1 3 65896 65896 20:19:38.005 21965 0 3 65896 20:19:38.110 21965 1 3 43931 20:19:38.666 21965 1 3 79230 79230 20:19:39.165 26410 0 3 79230 20:19:40.070 26410 1 3 52820 20:19:42.047 26410 2 3 26410 20:19:43.186 26410 2 3 54894 54894 20:19:43.613 18298 0 3 54894 20:19:43.978 18298 1 3 36596 20:19:44.361 18298 1 3 65048 65048 20:19:44.819 21683 0 3 65048 20:19:45.166 21683 0 3 93312 93312 20:19:45.427 21683 0 3 128463 93312 128463 20:19:45.616 31103 0 3 93312 128463 20:19:45.982 31103 1 3 62209 128463 20:19:46.032 42820 0 3 128463 20:19:47.994 42820 1 3 85643 20:19:48.205 42820 1 3 121139 121139 20:19:48.828 40380 0 3 121139 20:19:50.017 40380 1 3 80759 20:19:52.016 40380 2 3 40380 20:19:54.003

Now lets see how this model works on the previous counter cases.

[19:09:17.233] Delritha Fireball Warlord Zon'ozz *47834*
[19:09:17.929] Warlord Zon'ozz afflicted by Ignite from Delritha
[19:09:19.973] Delritha Scorch Warlord Zon'ozz *28978*
[19:09:19.991] Delritha Ignite Warlord Zon'ozz 12815
[19:09:20.632] Delritha Pyroblast! Warlord Zon'ozz *89248*
[19:09:20.719] Warlord Zon'ozz's Ignite is refreshed by Delritha
[19:09:21.116] Warlord Zon'ozz's Ignite is refreshed by Delritha
[19:09:21.972] Delritha Ignite Warlord Zon'ozz 25386

 timestamp ignite tick size current tick num ticks ignite bank travel bank 1 travel bank 2 19:09:17.233 25630 19:09:17.929 12815 0 2 25630 19:09:19.973 12815 0 2 41155 41155 19:09:19.991 12815 1 2 28340 41155 19:09:20.632 12815 1 2 76154 41155 76158 19:09:20.719 13718 0 3 41155 76158 19:09:21.116 25386 0 3 76158 19:09:21.972 25386 1 3 50772

The model matches the observed behavior. We also see that in the first example an alternative interpretation could be to always take ignite bank from travel event if one exists, but we see here that updating the bank when ignite ticks has to be done to match the observed behavior.

And the last example.

[20:44:06.638] Lucid Fireball Shannox *48425*
[20:44:07.167] Shannox afflicted by Ignite from Lucid
[20:44:09.222] Lucid Ignite Shannox 13214
[20:44:10.903] Lucid Fireball Shannox *48266*
[20:44:11.164] Lucid Ignite Shannox 13214
[20:44:11.164] Lucid's Ignite fades from Shannox
[20:44:11.588] Shannox afflicted by Ignite from Lucid
[20:44:13.744] Lucid Ignite Shannox 13170

 timestamp ignite tick size current tick num ticks ignite bank travel bank 1 travel bank 2 20:44:06.638 26428 20:44:07.167 13214 0 2 26428 20:44:09.222 13214 1 2 13214 20:44:10.903 13214 1 2 39556 39556 20:44:11.164 39556 20:44:11.588 19778 0 2 39556 20:44:13.744 19778 1 2 19778

Here unfortunately the model does not fit. Well I'm done for now, but hopefully someone can look at this and find some better idea about how they might be storing the data to match with all the results.

 01/18/12, 9:14 PM #426 Kavan Bald Bull   Kavan Gnome Mage   Kilrogg I think the biggest question is what function does the delay between spell crit and ignite refresh play in the server-client architecture. I don't see any reason why latency would have to be involved in any way. I also don't know how distance to target could play any effect unless an important part of ignite calculations happens already when spell cast is complete as opposed to when it lands.
 01/20/12, 6:07 PM #427 Kavan Bald Bull   Kavan Gnome Mage   Kilrogg Thinking about this some more it would seem that the biggest difference in the last case is that ignite dropped off in between. It's quite possible that that case would be handled differently, just assuming that when you start a new ignite you can't take anything from previous ignite bank. This could be handled for example by storing two pieces of information in the travel data, total ignite bank and ignite bank from triggering crit. The above cases do not cover all possibilites of crit/refresh/tick combinations, so if anyone has any examples where they think ignite acted strange it would be really useful to see them to validate this theory.
 01/20/12, 9:01 PM #428 ♦ Carebare ::stare::     carebare Tauren Druid   Mal'Ganis I just filtered out a lot of shit posts from this thread. So, though it appears Kavan is double and triple posting like crazy please don't report him for it. I'm leaving his posts behind because they actually contribute/have merit. Thanks in advance. i miss raiding with carebare :< she makes me feel like i am not the only person that hates everyone Aldriana: I am an asshole, it just so happens that some of my colleagues are even *bigger* assholes. [R] [85:Neux:2]: i hear if you die on Good Friday they are going to make it where you can't get rezzed until easter sunday Khazal: Yeah, I don't know about Magic Rainbow Unicorn Land, but here in Reality, Rhyolith is the worst encounter Blizzard has ever designed.
01/26/12, 8:41 PM   #429
Kavan
Bald Bull

Gnome Mage

Kilrogg
I've been looking at logs to find more examples not covered before, here's an analysis of one of them.

Source: World of Logs - Real Time Raid Analysis
Flashburn: 1.3859

Ignite related sequence:

[22:03:42.708] Pichenci Fireball Ultraxion *60567*
[22:03:43.070] Pichenci Fireball Ultraxion *60297*
[22:03:43.117] Ultraxion afflicted by Ignite from Pichenci
[22:03:43.519] Ultraxion's Ignite is refreshed by Pichenci
[22:03:45.220] Pichenci Ignite Ultraxion 22335
[22:03:45.606] Pichenci Fireball Ultraxion *61362*
[22:03:45.606] Pichenci Pyroblast! Ultraxion *76407*
[22:03:46.345] Ultraxion's Ignite is refreshed by Pichenci
[22:03:46.345] Ultraxion's Ignite is refreshed by Pichenci
[22:03:47.098] Pichenci Ignite Ultraxion 29009
[22:03:47.826] Pichenci Fireball Ultraxion *61488*
[22:03:48.428] Ultraxion's Ignite is refreshed by Pichenci
[22:03:49.116] Pichenci Ignite Ultraxion 30702
[22:03:49.116] Pichenci Fireball Ultraxion *62353*
[22:03:49.663] Ultraxion's Ignite is refreshed by Pichenci
[22:03:50.538] Pichenci Fireball Ultraxion *62351*
[22:03:51.100] Pichenci Ignite Ultraxion 31990
[22:03:51.191] Ultraxion's Ignite is refreshed by Pichenci
[22:03:53.132] Pichenci Ignite Ultraxion 43512
[22:03:53.255] Pichenci Combustion Ultraxion *21892*
[22:03:53.807] Pichenci Fireball Ultraxion *61480*
[22:03:53.994] Ultraxion's Ignite is refreshed by Pichenci
[22:03:54.577] Ultraxion's Ignite is refreshed by Pichenci
[22:03:55.154] Pichenci Ignite Ultraxion 44415
[22:03:55.802] Pichenci Fireball Ultraxion *61212*
[22:03:56.397] Ultraxion's Ignite is refreshed by Pichenci
[22:03:57.161] Pichenci Ignite Ultraxion 40921
[22:03:58.527] Pichenci Pyroblast! Ultraxion *77325*
[22:03:59.141] Pichenci Ignite Ultraxion 40921
[22:03:59.251] Ultraxion's Ignite is refreshed by Pichenci
[22:03:59.354] Pichenci Fireball Ultraxion *61765*
[22:04:00.059] Ultraxion's Ignite is refreshed by Pichenci
[22:04:00.633] Pichenci Fireball Ultraxion *61280*
[22:04:01.162] Pichenci Ignite Ultraxion 52983
[22:04:01.276] Ultraxion's Ignite is refreshed by Pichenci
[22:04:02.167] Pichenci Fireball Ultraxion *55782*
[22:04:02.838] Ultraxion's Ignite is refreshed by Pichenci
[22:04:03.203] Pichenci Ignite Ultraxion 74615
[22:04:03.718] Pichenci Fireball Ultraxion *56203*
[22:04:04.432] Ultraxion's Ignite is refreshed by Pichenci
[22:04:05.171] Pichenci Ignite Ultraxion 60129
[22:04:05.824] Pichenci Pyroblast! Ultraxion *69561*
[22:04:06.487] Ultraxion's Ignite is refreshed by Pichenci
[22:04:07.204] Pichenci Ignite Ultraxion 52941
[22:04:08.298] Pichenci Fireball Ultraxion *56121*
[22:04:08.954] Ultraxion's Ignite is refreshed by Pichenci
[22:04:09.233] Pichenci Ignite Ultraxion 45665
[22:04:09.794] Pichenci Fireball Ultraxion *55964*
[22:04:10.536] Ultraxion's Ignite is refreshed by Pichenci
[22:04:11.214] Pichenci Ignite Ultraxion 40785
[22:04:11.394] Pichenci Fireball Ultraxion *56156*
[22:04:12.150] Ultraxion's Ignite is refreshed by Pichenci
[22:04:12.980] Pichenci Fireball Ultraxion *55935*
[22:04:13.235] Pichenci Ignite Ultraxion 37567
[22:04:13.703] Ultraxion's Ignite is refreshed by Pichenci
[22:04:15.248] Pichenci Ignite Ultraxion 35381
[22:04:15.530] Pichenci Pyroblast! Ultraxion *70140*
[22:04:15.530] Pichenci Fireball Ultraxion *56003*
[22:04:16.129] Ultraxion's Ignite is refreshed by Pichenci
[22:04:16.129] Ultraxion's Ignite is refreshed by Pichenci
[22:04:17.104] Pichenci Ignite Ultraxion 33936
[22:04:18.211] Pichenci Fireball Ultraxion *56218*
[22:04:18.892] Ultraxion's Ignite is refreshed by Pichenci
[22:04:19.140] Pichenci Ignite Ultraxion 33012
[22:04:21.241] Pichenci Ignite Ultraxion 33013
[22:04:23.262] Pichenci Ignite Ultraxion 33013
[22:04:23.262] Pichenci's Ignite fades from Ultraxion

Analysis (I'm listing travel bank only from the actual crit, without stacking):

 timestamp ignite tick size current tick num ticks travel bank 1 travel bank 2 notes 22:03:42.708 33576 22:03:43.070 33576 33426 22:03:43.117 16788 0 2 33426 22:03:43.519 22334 0 3 22:03:45.220 22334 1 3 22:03:45.606 22334 1 3 34017 22:03:45.606 22334 1 3 34017 42357 22:03:46.345 26228 0 3 42357 22:03:46.345 29008 0 3 munched 22:03:47.098 29008 1 3 22:03:47.826 29008 1 3 34086 22:03:48.428 30701 0 3 22:03:49.116 30701 1 3 22:03:49.116 30701 1 3 34566 22:03:49.663 31989 0 3 22:03:50.538 31989 0 3 34565 22:03:51.100 31989 1 3 34565 free tick (crit-tick-refresh) 22:03:51.191 43511 0 3 22:03:53.132 43511 1 3 22:03:53.255 43511 1 3 12136 22:03:53.807 43511 1 3 12136 34082 22:03:53.994 33053 0 3 34082 22:03:54.577 44414 0 3 22:03:55.154 44414 1 3 22:03:55.802 44414 1 3 33933 22:03:56.397 40920 0 3 22:03:57.161 40920 1 3 22:03:58.527 40920 1 3 42866 22:03:59.141 40920 2 3 42866 free tick (crit-tick-refresh) 22:03:59.251 41569 0 3 22:03:59.354 41569 0 3 34240 22:04:00.059 52982 0 3 22:04:00.633 52982 0 3 33971 22:04:01.162 52982 1 3 33971 free tick (crit-tick-refresh) 22:04:01.276 64306 0 3 22:04:02.167 64306 0 3 30923 22:04:02.838 74614 0 3 22:04:03.203 74614 1 3 22:04:03.718 74614 1 3 31157 22:04:04.432 60128 0 3 22:04:05.171 60128 1 3 22:04:05.824 60128 1 3 38562 22:04:06.487 52939 0 3 22:04:07.204 52939 1 3 22:04:08.298 52939 1 3 31111 22:04:08.954 45663 0 3 22:04:09.233 45663 1 3 22:04:09.794 45663 1 3 31024 22:04:10.536 40783 0 3 22:04:11.214 40783 1 3 22:04:11.394 40783 1 3 31131 22:04:12.150 37566 0 3 22:04:12.980 37566 0 3 31008 22:04:13.235 37566 1 3 31008 no free tick? 22:04:13.703 35380 0 3 22:04:15.248 35380 1 3 22:04:15.530 35380 1 3 38883 22:04:15.530 35380 1 3 38883 31046 22:04:16.129 36548 0 3 31046 22:04:16.129 33935 0 3 munched 22:04:17.104 33935 1 3 22:04:18.211 33935 1 3 31165 22:04:18.892 33012 0 3 22:04:19.140 33012 1 3 22:04:21.241 33012 2 3 22:04:23.262 33012 3 3

We see that there is no munching in the initial double crit from legendary (simc would munch this). Also aggregating the ignite stack there does not depend on there actually being ignite already applied. The simultaneous crit at 22:03:45.606 however is munched. Then again at 22:03:53.255, we have nonsimultaneous, but sequential crits before refresh result in no munching. Towards the end we then have another example of munching with simultaneous crit at 22:04:15.530. This would indicate that munching is not reliant on crit-crit-refresh-refresh sequence, but it needs to be simultaneous. It's possible that two very close but not simultaneous crits would also munch, but I wasn't able to find an example of this so far.

The most interesting case however is at 22:04:12.980. There we have an example of a crit-tick-refresh sequence, which has in all previous cases resulted in a free tick. What makes this situation different I don't know, but it shows that we don't have the whole thing quite figured out yet. One theory I have at the moment is that for a free tick scenario the time between tick and refresh has to be very short, but I'd need more examples to verify this.

Last edited by Kavan : 01/26/12 at 8:50 PM.

 01/26/12, 11:39 PM #430 Kavan Bald Bull   Kavan Gnome Mage   Kilrogg It is becoming clear that these results can't be explained just by fluctuations in delay between server and client when reporting log messages. In addition using the current model the exceptions would require Blizzard almost to try very hard to get wrong results. After looking at this for a long while now I've finally got a comprehensive theory that explains all the cases and makes sense on Blizzard side. My theory is that the delay between crit and ignite application/refresh is due to some form of a deferred calculation going on. This delay seems to be usually around 0.4-0.7 seconds. Some of the variation we see may be due to variation in server-client lag, some due to how busy the server is with other computations. The key observation was the different cases of crit-tick-refresh free ticks. Whenever there was a free tick we had a close time between tick and refresh, usually around 0.1 second. Now if we accept that computation of new ignite tick is deferred, then there must be some point in that calculation where the current ignite is sampled. If this happens about 0.1-0.2 seconds before the refresh, we can explain all the cases of munching and rolling we've examined so far. This also gives us a nice way to model this. Instead of performing ignite calculation at the point of the crit, we just move the whole calculation further ahead by some delay, and then another delay until ignite is applied/refreshed.
 01/27/12, 7:36 AM #431 fateswarm Von Kaiser     fateswarm Goblin Mage   Lightning's Blade (EU) It might be worth collecting samples from two different clients with different latencies that are quite stable in latency or at least latencies that are monitored closely side by side with the gameplay results. It might be an algorithm that drops/defers information only under certain delays. edit: Come to think of it, a single person might do it if he has access to another area of realms.
 01/27/12, 9:25 AM #432 angayelle Piston Honda   Angayelle Human Mage   Nordrassil (EU) Calculating ignites with the delays you speak about have no real use, I think. From a theorycrafting point of view, it's very interesting but the practical use of it is quite small if you're not able to have this info right after your spell crit. By delays, are you speaking of theses 0.4 - 0.7 secs ? Anyway I didn't include any part for free ticks in the ignite prediction function of CombustionHelper, look like theses cases are the one causing some glitches in the predictions. I will have to work on it then. Creator of CombustionHelper, MageManaBar, MageBombTracker and CauterizeCooldown.
 01/27/12, 5:27 PM #433 Kavan Bald Bull   Kavan Gnome Mage   Kilrogg In terms of realtime prediction you're right, it presents some problems, but not more than you had so far. The current model already needed you to predict how long it will take until the refresh will take place. The difference is that now you have to predict two times. The delay between crit and refresh is relatively easy because we have both points in the log. The delay between crit and ignite sampling is different. That part we can only infer by looking at how far the tick-refresh can be in a crit-tick-refresh sequence that will still cause a free tick or how close two crits have to be to cause a munch. This might also be possible to use for testing by intentionally delaying hot streak pyro after fireball for a split moment and examining the double crit results. However if you have a good estimate for these two, you can still make the prediction at the time of the crit about what the next ignite tick will be. You only need to run through the future steps ahead of time to get that.
 01/28/12, 4:52 AM #434 angayelle Piston Honda   Angayelle Human Mage   Nordrassil (EU) One thing different from your way of getting the timestamps of the crit and the refresh is that you use the combat log events for both whereas i'm using the combat log events for the crit timestamp only and the UnitAura query for the refresh one. Building the prediction engine from the combat log events may lead to discrepancies when using it ingame because of the difference of latency between combat log events and the method of retrieving info about ignite refresh (done by reaction to crit event or by OnUpdate query every Nsecs). I hope i'm not too unclear with what I want to say, in short we need to build this engine by using the same datas that we'll be using ingame, sadly that means thoses logs aren't the best sources we should use. Guess we'll have to collect ourselves theses datas, I'll code a little something if you want. Creator of CombustionHelper, MageManaBar, MageBombTracker and CauterizeCooldown.
 01/28/12, 5:41 AM #435 Kavan Bald Bull   Kavan Gnome Mage   Kilrogg I'm pretty sure the refresh events are available from the ingame COMBAT_LOG_EVENT_UNFILTERED. At least wowwiki lists the _AURA_APPLIED and _AURA_REFRESH suffixes for it, but I haven't tried myself ingame. My understanding was that the text version of combat log directly corresponds to those events.

 Elitist Jerks Cataclysm Mage Simulators and Formulators