Elitist Jerks
Register
Blogs
Forums


Go Back   Elitist Jerks » Mages

Reply
 
LinkBack Thread Tools
Old 01/18/12, 9:14 PM   #426
Kavan
Bald Bull
 
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.

Offline
Reply With Quote
Old 01/20/12, 6:07 PM   #427
Kavan
Bald Bull
 
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.

Offline
Reply With Quote
Old 01/20/12, 9:01 PM   #428
♦ Carebare
::stare::
 
Carebare's Avatar
 
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.

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

United States Offline
Reply With Quote
Old 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):

timestampignite tick sizecurrent ticknum tickstravel bank 1travel bank 2notes
22:03:42.708   33576  
22:03:43.070   3357633426 
22:03:43.1171678802 33426 
22:03:43.5192233403   
22:03:45.2202233413   
22:03:45.606223341334017  
22:03:45.60622334133401742357 
22:03:46.3452622803 42357 
22:03:46.3452900803  munched
22:03:47.0982900813   
22:03:47.826290081334086  
22:03:48.4283070103   
22:03:49.1163070113   
22:03:49.116307011334566  
22:03:49.6633198903   
22:03:50.538319890334565  
22:03:51.100319891334565 free tick (crit-tick-refresh)
22:03:51.1914351103   
22:03:53.1324351113   
22:03:53.255435111312136  
22:03:53.80743511131213634082 
22:03:53.9943305303 34082 
22:03:54.5774441403   
22:03:55.1544441413   
22:03:55.802444141333933  
22:03:56.3974092003   
22:03:57.1614092013   
22:03:58.527409201342866  
22:03:59.141409202342866 free tick (crit-tick-refresh)
22:03:59.2514156903   
22:03:59.354415690334240  
22:04:00.0595298203   
22:04:00.633529820333971  
22:04:01.162529821333971 free tick (crit-tick-refresh)
22:04:01.2766430603   
22:04:02.167643060330923  
22:04:02.8387461403   
22:04:03.2037461413   
22:04:03.718746141331157  
22:04:04.4326012803   
22:04:05.1716012813   
22:04:05.824601281338562  
22:04:06.4875293903   
22:04:07.2045293913   
22:04:08.298529391331111  
22:04:08.9544566303   
22:04:09.2334566313   
22:04:09.794456631331024  
22:04:10.5364078303   
22:04:11.2144078313   
22:04:11.394407831331131  
22:04:12.1503756603   
22:04:12.980375660331008  
22:04:13.235375661331008 no free tick?
22:04:13.7033538003   
22:04:15.2483538013   
22:04:15.530353801338883  
22:04:15.53035380133888331046 
22:04:16.1293654803 31046 
22:04:16.1293393503  munched
22:04:17.1043393513   
22:04:18.211339351331165  
22:04:18.8923301203   
22:04:19.1403301213   
22:04:21.2413301223   
22:04:23.2623301233   

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.

Offline
Reply With Quote
Old 01/26/12, 11:39 PM   #430
Kavan
Bald Bull
 
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.

Offline
Reply With Quote
Old 01/27/12, 7:36 AM   #431
fateswarm
Von Kaiser
 
fateswarm's Avatar
 
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.

Offline
Reply With Quote
Old 01/27/12, 9:25 AM   #432
angayelle
Piston Honda
 
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 and MageManaBar.

France Offline
Reply With Quote
Old 01/27/12, 5:27 PM   #433
Kavan
Bald Bull
 
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.

Offline
Reply With Quote
Old 01/28/12, 4:52 AM   #434
angayelle
Piston Honda
 
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 and MageManaBar.

France Offline
Reply With Quote
Old 01/28/12, 5:41 AM   #435
Kavan
Bald Bull
 
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.

Offline
Reply With Quote
Old 01/29/12, 5:15 AM   #436
angayelle
Piston Honda
 
Human Mage
 
Nordrassil (EU)
Indeed they are present in the combat log. Seems I didn't made myself clear enough in english.

I'll try again : you're building your prediction theory based on the timestamps of events collected after a fight whereas ingame we won't have the timestamps of the refresh events available as they haven't occured yet, so we'll have to rely on UnitAura queries which can have different delays in retrieving the information.

Though, I had think about it a bit more and come the conclusion that we can use events to get the timestamp of the next AURA_REFRESH by using the previous timestamp + 2 seconds.

Creator of CombustionHelper and MageManaBar.

France Offline
Reply With Quote
Old 01/29/12, 8:07 AM   #437
Kavan
Bald Bull
 
Gnome Mage
 
Kilrogg
Actually that wouldn't work, you can use that to predict next tick only, not refresh. There is no way to know in advance exactly how long the delay between crit and refresh will be. The only thing you can do is collect samples about past delays and use that to predict future delays, but you won't be able to be 100% certain.

Offline
Reply With Quote
Old 01/29/12, 9:18 AM   #438
angayelle
Piston Honda
 
Human Mage
 
Nordrassil (EU)
Ah I understand better now, I thought you were using timestamp of the application of ignite as data to know if free ticks are happening instead of actual refresh caused by a previous critical.

All my calculations in CombustionHelper are done by comparing the timestamp of the critical and the timer of the ignite debuff on the target, i'll have a look at calculating this with the Refresh of ignite instead to see if i can get better results then.

Creator of CombustionHelper and MageManaBar.

France Offline
Reply With Quote
Old 01/29/12, 2:20 PM   #439
Aantu
Glass Joe
 
Worgen Mage
 
Korgath
Some data regarding munching can be found here, under the latest three logs: World of Logs - Real Time Raid Analysis

I tried to line up scorch and fireball to see under what circumstances a spell is munched, and got the following data with 32 to 45 ms of lag. All of the samples were with ignite not currently on the target. Not a huge number of samples here, but good enough for a passable model at my latency.

Munched spells (seconds apart)
.000
.000
.000
.000
.098
.101
.102
.120
.123
.132
.133
.156
.160
.178
.229
.230
.240
.241
.241
.274
.340

Non-Munched spells (seconds apart)
.085
.134
.137
.144
.209
.211
.215
.239
.253
.323
.328
.344
.372
.372
.404
.408
.411
.418
.424
.439

Notes

-Spells occurring closer than .250 seconds apart tended to get munched, while those occurring farther than .250 seconds apart tended not to get munched. There was a lot of variability, especially for spells that didn't get munched (spells more than .250 seconds apart almost always did not get munched, while spells less than .250 seconds apart would occasionally not get munched)

-Spells occurring less than .100 seconds apart were "crunched" together, and ended up hitting at the exact same time (not sure if this was common knowledge, but I wasn't aware of it)

-The one instance of three crits occurring in succession (due to a staff proc) resulted in none of the three spells getting munched, even though the first two hit .085 seconds apart. There was only one instance of this in the data, so you can't really draw conclusions from it, but it is something to look for in other logs.

Last edited by Aantu : 01/29/12 at 4:08 PM.

United States Offline
Reply With Quote
Old 01/29/12, 4:49 PM   #440
Kavan
Bald Bull
 
Gnome Mage
 
Kilrogg
Very nice data there, I haven't had time to double check everything, but this highlights a very interesting mechanic that I wasn't aware of (flashburn=1.4261).

[10:05:53.843] Aantu Fireball Training Dummy *1* (O: 42959)
[10:05:53.975] Aantu Scorch Training Dummy *1* (O: 17288)
[10:05:53.975] Aantu gains Hot Streak from Aantu
[10:05:53.989] Aantu gains Stolen Time (4) from Aantu
[10:05:54.344] Training Dummy afflicted by Ignite from Aantu
[10:05:54.344] Aantu gains 470 mana from Aantu's Master of Elements
[10:05:54.746] Training Dummy's Ignite is refreshed by Aantu
[10:05:54.746] Aantu gains 419 mana from Aantu's Master of Elements
[10:05:54.749] Training Dummy's Critical Mass is refreshed by Aantu
[10:05:55.970] Aantu's Hot Streak fades from Aantu
[10:05:56.409] Aantu Ignite Training Dummy 1 (O: 4931)
[10:05:56.870] Aantu begins to cast Fireball
[10:05:58.213] Aantu begins to cast Fireball
[10:05:58.448] Aantu Ignite Training Dummy 1 (O: 4930)
[10:06:00.395] Aantu begins to cast Scorch
[10:06:00.395] Aantu Ignite Training Dummy 1 (O: 4931)
[10:06:00.395] Aantu's Ignite fades from Training Dummy

This was a munched sample. The interesting part is when the scorch crit samples current ignite it has nothing on target at the moment, so it computes the bank which is 9861.8, and it applies it to 2 ticks of 4930.9 each. However since fireball ignite was applied in between that, when scorch ignite lands it sets tick to 4930.9, but since it's refreshing it creates 3 ticks of it.

This would indicate to me that Blizzard doesn't store any bank data in ignites, but just pure tick size, and number of ticks on ignite is computed completely independently when ignite lands.

I'll have to look more at this, but the examples where I've seen no munching with close crits seem to have larger distance between application and refresh of ignite. So it would be interesting to also group up all examples by application-refresh distance to see if that is more predictive.

Last edited by Kavan : 01/29/12 at 5:09 PM.

Offline
Reply With Quote
Old 02/21/12, 2:16 PM   #441
fateswarm
Von Kaiser
 
fateswarm's Avatar
 
Goblin Mage
 
Lightning's Blade (EU)
Is there a statement for the current size of Ignite in SimCraft? The application would be to test results with a Combustion under a minimal Ignite size.

Offline
Reply With Quote
Old 02/21/12, 2:51 PM   #442
Kavan
Bald Bull
 
Gnome Mage
 
Kilrogg
There isn't currently, but there is an issue open already on the topic (Issue 1136 - simulationcraft - [Question/Request] Ignite tick damage - World of Warcraft DPS Simulator - Google Project Hosting). If it was just a question of the current value of ignite on the target that wouldn't be hard to do. The problem comes from the fact that it would have to behave more in the react style since you can't know in advance what the tick will be (at least until we create better prediction models). Still doable, but would require a bit more bookkeeping.

Offline
Reply With Quote
Old 03/12/12, 2:04 PM   #443
angayelle
Piston Honda
 
Human Mage
 
Nordrassil (EU)
As posted in the Fire Compendium thread, here is the LUA function describing the combustion Tick predicted as used in CombustionHelper. I'm not the original formula creator (original thread here), but I made the LUA version.

function CombuDamagePredicter ()

local combuhasteplateau = {{0,10}, -- haste rating, tick number
                            {639,11},
                            {1922,12},
                            {3212,13},
                            {4488,14},
                            {5767,15},
                            {7033,16},
                            {8309,17},
                            {9602,18},
                            {10887,19},
                            {12182,20}}

        combufirepower = 1 + (select(5,GetTalentInfo(2,5))/100)
        combucriticalmass = 1 + ((select(5,GetTalentInfo(2,20))*5)/100)

	if select(1,UnitAura("target",pyro1,nil,"HARMFUL")) or select(1,UnitAura("target",pyro2,nil,"HARMFUL")) then
		combupyrodps = (164 + (0.180*GetSpellBonusDamage(3)))*(combufirepower)*(1.25)*((0.00015618*GetCombatRating(26)) + 1.224)
	else combupyrodps = 0
	end
	
	if select(1,UnitAura("target","Living Bomb",nil,"HARMFUL")) then
		combulbdps = (234 + (0.258*GetSpellBonusDamage(3)))*(combufirepower)*(1.25)*(combucriticalmass)*((0.00015618*GetCombatRating(26)) + 1.224)
	else combulbdps = 0
	end
	
	combucurrenthaste = UnitSpellHaste("player") * 128.05701
	
	for i = 2,#combuhasteplateau do
		
		if combucurrenthaste < (combuhasteplateau[i])[1] then
			combuhastetick = (combuhasteplateau[i-1])[2]
			break
		end
	end
	
	combuexpectedtickdmg = ceil(combupyrodps/3 + combulbdps/3 + combuigndamage/2)
	-- the variable combuigndamage need to be stored from the combat log event so it can included in the calculation
	
	return format("Tick : %.0f x %0.f",combuexpectedtickdmg,combuhastetick)

end
As you can see, we no longer take in account the DPS of the dots, only their power, as haste is only used to calculate the number of Combustion ticks.

Of course to get the whole Combustion spell prediction, we'll need to add the front damage of Combustion and simulate the crit chance for each of the portion of damage (front + ticks). I haven't included it into this formula as the way I'm averaging crit damage is not the best possible.

Last edited by angayelle : 03/12/12 at 7:33 PM. Reason: Added comment for combuigndamage variable

Creator of CombustionHelper and MageManaBar.

France Offline
Reply With Quote
Reply

Go Back   Elitist Jerks » Mages

Thread Tools

Similar Threads
Thread Thread Starter Forum Replies Last Post
Cataclysm Mage Changes Narcosleepy Mages 570 09/07/10 7:07 PM