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

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.

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.

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.

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.

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'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.

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.

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.

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.

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.