Cardynal

You're not going to be able to cast the fireblast and have it still go through with this "fudge" factor since your cooldown in is the client side. I don't believe the request would even go to the server since you're hitting a cooldown. If so...you'd be able to cast during GCD...or under 1.5 seconds...and have it go through. I'm at work as well so I'm unable to test this. =/

Good point about the added MS though.

And Clairecakes....wrong place to post this.

 

ebbv

It could be the human factor, but please note that 125ms being added to a Fireblast is equivallent to 250ms being added to a Fireball, which is a far cry from the 92ms average I saw.

Again, much more testing needs to be done, I just did a quick test to see if how bad Fireblast interacted with the new cast system and with the bit of haste gear I have.

edit:

And yeah, that's correct, you cannot start the first Fireball of the next rotation "on time" because of the GCD from Fireblast preventing you from even sending the request, this is a big part of why the Fireblast rotation gets destroyed by latency.

Normal Fireball spam is able to overcome latency a bit due to the new system (and before it, via /stopcasting), but when you put a Fireblast into the rotation half of your fireballs are being delayed until the GCD is up.

 

Vannik

Your haste on your gear is going to obviously swing fireblast out, because as haste increases the advantage of fireball spam increases due to your 7.5 second cooldown. I don't know why you can't see this, but your fireblast rotation will always be 7.5seconds given any ammount of haste, so you can also see that the GCD is clipping.

All I am saying is that just generally saying fireball spam is the way to go is completely incorrect, no matter what attainable +dmg you have. Fireball spam is more closely related to your haste gear.

Try a 3 fireball/fireblast rotation to see if the latency kills it. This should both eliminate your haste gear effecting the global cooldown problem that you have. You should notice an increase in dps with fireballx3/fireblast over fireball spam. If not, we can conclude that instant casts have a different mechanic than non-instant spells, if that's what you're implying, in regards to spell queing.

 

Rouncer

Actually that's wrong.

GCD is client side. Which means there is no reason to fudge it at all. It starts running the instant you request the spell on your client and runs for exactly 1.5 seconds and then allows you to make additional requests. The fudge factor is built in since you have to wait for the 1.5 seconds to run before you can make an additional request.

0 - request Fireblast, GCD starts and cooldown starts for Fireblast
0.15 - server receives Fireblast request, casts Fireblast
1.5 - client completes GCD and is free to request new spell
1.65 - server receives next spell request

Thats why your client locks up in GCD whenever you request a spell, so that the server doesn't have to worry about the timing of the next spell request. I'm sure there are checks to make sure that you haven't hacked the client to shorten the GCD but otherwise even if the request goes in a bit early due to shifting latency the server will still honor the request.


True this is only my limited understanding of the way the new system functions but with GCD being fixed in duration and completely client-side there shouldn't be any issues with needing to fudge anything no matter how the new system works.

 

Pintofbrew

http://elitistjerks.com/f31/t16781-mage_help_me_please/ That way ->

Every day there's someone who wants advice on the TC thread.

For hydros, don't bother 5 talent balls aren't worth it. With no ignite to create synergy with Spell Power it's quite mediocre. I'm full frost and on Hydros I just AB/Scorch rotate, Unless DPS is an issue for your guild (and if it is, you should respec) it won't matter.

Al'ar likewise isn't particularly intensive on DPS. As long as you can manage a modicum of 500ish dps you're fine. many mages do Al'ar full fire using default AM and AB rotations which is quite low on output but adequate for what is primarily a heal-and-tank intensive encounter.

 

Dustwhisper

Respeccing for al'ar is something you'll only do your first kills anyways. I went deep frost for Al'ar 2 maybe 3 times then just stayed fire and used arcane-spells and did like 600 dps instead just means the fight will be a tad longer.

 

Etherealz

There are a few things to consider when looking at fireblasting.

1) Haste gear limits the effectiveness of this - as the rotation can never be under 7.5s
2) Mana - If rotating in fireblast causes you to have to evocate - that's 8-10s of dps loss.


Generally it's really not worth it unless it's a fight that requires movement such as gurtogg bloodboil rotations (perfect time to rotate in fireblasts)

Edit: Also - once you've "beat the game" in gear - it's not even a consideration on standstill fights :P

 

Rouncer

I don't get why people keep saying this. One aspect of the "fix" to the casting mechanics is that it should turn 1.5s casts into true 1.5s casts. Thats why the GCD occurs whenever you request a spell.

I think the real problem is that we are all relatively proficient at using Quartz and /stopcasting so that we can aim for "button up" right when the casting bar hits the red but since Quartz doesn't run with an instant cast spell we lose that frame of reference and our "button up" occurs with a slight delay.

Just did some testing on the PTR. Cast 20 Fireballs and 28 for each of the other spell sets.

Casting with Quartz and aiming for "button up" at the red
Fireball - average 3.046
Scorch - 1.602


Spamming cast button as fast as I could
Scorch - 1.56
Ice Lance - 1.593


With all the sets I had several casts under the 1.5s mark which leads to an interesting question; is the lag due to me or the mechanics of the new system?

Fastest Casts (no haste gear)

Fireball - 2.719
Scorch - 0.969

Scorch Spam - 1.312
Ice Lance Spam - 1.375

Being able to cast under the supposed minimum casting time also seems like it should be worth exploring to see if it is real or just due to the data being recorded on my client and the latency between my client and the server causing the discrepancies.

So does anyone want to pull out a G15 and go after Dr Boom with Ice Lance and Scorch spam again (Manly)?

 

Dustwhisper

It's not the spam they are referring too, they are referring to weaving in a different spell between fireballs where you aren't chaining the same cast. Go 2xfireball 1xinstacast.

 

Vhad

You've always been able to cast under the "supposed minimum casting time" It's just, you can't cast a new spell before the GCD is over - or am I misunderstanding you?

What!?

 

◊ manly

The wow general threads at the time of implementation were touting that instant cast spells were being handled differently and not affected by the spell queue. Although I did hear a wide amount of different theories about how it works, the ones that seemed the most appropriate are the one with the 250ms latency window and the one about the instant casts.

In any case, 3.046ms average lag out of 20/28 fireballs would indicate that there is in fact no spell queue. If you think a bit about it, the only time we should see the effect of lag would be at the last fireball (ie: the local timestamp of the last fireball can be misleading) and also at the first fireball if you begin your stopwatch as you begin to hit your key. As such, if true spell queue existed, I would expect maybe 300 ms lag in total, not much above that. In other words, 0.3s of lag spread out over 20 casts, which would give 3.015s average fireball casts.

With this said, I can give it a shot with a G15. I might also try a G15 macro of (/cast /wait 100ms /cast /wait 3s /cast /wait 3s /cast /wait 3s ...) which would properly test out what were looking for.

Log on with different model:
1- Create a character of the desired model. Log on/off.
2- At character selection screen, select your actual character; mouseover the new, desired model character, and hold down left click; hit enter and release left click at the same time.
bug Arcane Potency only applies to the first Arcane Missile bolt.

 

ebbv

The "below minimum" cast times are due to latency fluctuations. Such that your "start cast" from the server to your client is delayed more by latency than the "cast complete" message. I figured this out after my testing yesterday revealed those faster fireballs.

Also those who keep bringing up my haste gear, it was already addressed on the previous page. Even if you take the haste gear out of the equation, and just ignore the 0.26s that in theory I had to wait for my Fireblast cooldown (though latency on the Fireballs should have reduced that somewhat), the Latency impact on Fireblast was still much greater than Fireball.

Alright, so I'm tired of the haste gear being brought up which I was afraid it might be, along with the Fireblast cooldown. So I swapped out the haste gear and respecced to have full 3/3 Imp Fireblast. The combination of the two is unnecessary but this way nobody can call shennanigans. Here's what I got, which is very much in line with what I got before if you ignored the 260ms from Haste.

So here we are doing a 7.5sec Rotation.

A1 4.75
B1 1.187
C1 2.031
T1 7.968 (+468ms)

A2 4.61
B2 1.00
C2 2.218
T2 7.828 (+328ms)

A3 4.75
B3 1.156
C3 1.954
T3 7.86 (+360ms)

A4 4.625
B4 1.11
C4 2.109
T4 7.844 (+344ms)

A5 4.734
B5 0.907
C5 2.187
T5 7.828 (+328ms)

A6 4.64
B6 1.109
C6 2.016
T6 7.765 (+265ms)

A7 4.625
B7 1.235
C7 2.00
T7 7.86 (+360ms)

A8 4.625
B8 1.109
C8 1.984
T8 7.718 (+218ms)


Average Latency 333ms


So average Latency per rotation is 333ms, which is much higher than the 92ms per Fireball average I got on Fireball spam. Any way you slice it, it's Fireblast and the GCD getting in the way that's killing it. From my testing the GCD is NOT ending early and allowing you to start your Fireball on time, it is delaying the next Fireball every time.

Obviously the sample size is still small, but one thing that struck me was the consistency of the numbers, including more identical timings than I'd have ever expected.

edit:

Manly I had the opposite conclusion. The average latency per Fireball being so much lower than my actual average latency tells me there *is* a spell queue. The average latency per Fireball can be account for by latency fluctuations, note that as would be expected from such an artifact, we are seeing negative latency.

I am fairly convinced that for non-instant spells there is a small "grace window", which does act like a queue. For instant spells it's not there, though, because you're waiting on GCD, not a castbar.

 

Rouncer

Well I did cast under the GCD if you look at the Fastest cast for Scorch and Ice Lance.

Thanks for agreeing to test that Manly, I'm really curious what it would show.

As for the weaving aspect, one of the things that makes that testing very unreliable is the human factor.

Since Quartz isn't running a casting bar for the Instant cast spells you are asking a person to synchonize between a bar that they are already familiar with and are used to operating and a clock type motion on their casting bar. I was trying to see if for an instant cast spell if you could cast your Fireball, time the click of the Fireblast and then spam Fireball while the GCD runs. But the testing actually led to other questions that really should be looked at and the mechanics nailed down before looking at what happens at the interaction between 2 separate spell mechanics.

One thing I did notice during my Ice Lance spam is that there is indeed a delay between pressing the button and the spell actually firing, BUT that delay did nothing to increase the cast time mechanics. I think that delay is just normal server latency between client and server and it appears worse then we are used to since the GCD is already running and we are focused on that instead of looking for a new casting bar. Since the GCD starts from your client it is running when the client is told by the server that the spell cast, whereas for a "cast time" spell the new casting bar starts and the spell fires simultaneously on instruction from the server.

Manly, if you wouldn't mind could you also run a test where you Fireblast -> timed cast Fireball -> timed cast Fireball -> Fireblast -> spam cast Fireball (until the cast bar starts) -> timed cast Fireball -> timed cast Fireblast -> spam cast Fireball...repeat. The spamming should be with something like 0.02 keypress intervals on the G15.

Do it on the PTR and with no haste gear and at least 1 point in Improved Fireblast (2 might be better to remove that conditional) and we should be able to see a little better if it a human timing flaw or something intrinsic to the new system.

 

ebbv

I believe this statement is incorrect. The human factor will be there when the Fireblast rotation is actually being used in a raid situation too, so it's an essential part of the equation. The goal here is to preview in a controlled environment what we're likely to see in a raid scenario out of this method of DPS. The figures we get back are actually idealized since there's no distractions, we're just spamming spells on an unmoving target.

In terms of discovering the true underlying behavior of the casting system, then yes the human factor gets in the way, and so does our fluctuating latency. But the real goal, at least to me, was to see if latency affected Fireblast rotation differently from Fireball spamming, and if so was it enough to overcome the modest DPS gain.

 

ebbv

Duplicate post due to Firefox timing out. My apologies.

 

Muphrid

Here's how the new casting mechanics work: whenever you press a button, the client checks that you meet the requirements (enough mana, in range, etc.) against the data it currently has (what you see on screen). These are immediate checks; if they fail, no GCD is invoked, and you get an instant error message.

If, however, you pass the client-side checks, the request is sent to the server, where the server runs many of the same checks (ostensibly to prevent hacking of the client), and the result of these checks (success or failure) is sent back to the client.

In the event of a casting time spell, the casting bar appears only after the server's confirmation is received by the client--this is how Quartz measures instantaneous latency. In the event of an instant, your instant visually fires only after receiving server confirmation; you can confirm this visually by watching the yellow outline on the button--it only disappears after a short amount of time, the GCD was already cycling.

If you fail the server-side checks, the client aborts the GCD, and the server's error message appears.


Now then, since the client-side GCD starts the instant you press the button, it is always a true 1.5 seconds, not affected by latency. For casting time spells, all that is different between 2.3 and 2.2 (or should be) is that the client no longer checks against whether you're in the middle of a cast or not--thus, if you pass all other checks, your request is sent to the server anyway, where a casting check is invoked. Thus, there is no need for a spell queue in this system--rather, the server becomes the master arbiter of whether you're still casting or not (and thus, whether you could start casting a new spell).

 

Rouncer

Thank you for the additional testing.

One thing to keep in mind though is that the results aren't that much better then pure spam in regards to latency. Its not rotation vs a single spell request, its rotation vs 2.5 spell requests.

So that comparison should be 333ms vs 230ms in regards to whether or not it's advantageous to incorporate the rotation. So if one of the proponents of the rotation wouldn't mind incorporating that into their numbers we will truly be able to see if it is worth incorporating on a regular basis.

As for what you specifically are seeing, you are getting 92ms of lag with every spell request and since the rotation is 3 spell requests that works out to 111ms vs 92ms which is certainly within the range of uncertainty due to the small sample size. I'm just not seeing enough of a difference between those 2 values to say that it is blizzard's system that is adding additional time when switching between instant cast and cast timed spells.


Edited to add - very succinctly said Murphid, thank you.

 

◊ manly

Just for reference before this confuses some people. Lower-than-cast-time-fireballs are *normal*. Its a side effect of the local timestamps. Here is a simple display showing the explanation:

0000 - fireball cast client side
0100 - fireball starts server side
...
3100 - fireball ends server side
3101 - new fireball cast begins server side
3400 - fireball end received by client (ie: combat logs)
...
6101 - new fireball completes server side
6201 - new fireball completes client side

In this case, the latency in the first fireball is delayed, causing the next fireball to 'seem' to cast faster than its cast time.

Log on with different model:
1- Create a character of the desired model. Log on/off.
2- At character selection screen, select your actual character; mouseover the new, desired model character, and hold down left click; hit enter and release left click at the same time.
bug Arcane Potency only applies to the first Arcane Missile bolt.

 

ebbv

Saying that it's for 2.5 spells is a bit misleading, because there's no such thing as "half a Fireball" really. What it really comes down to is with Fireblast Rotation 333ms per 7.833ms of DPS time is spent purely on latency. That's 4.25% vs 2.9% (92ms per 392ms) for Fireball spam, or 1.35% more of your DPS time consumed by latency on Fireblast Rotation.

Now that doesn't seem like much but depending on your gear that can totally eclipse the advantage of Fireblast. If you're running no haste and only about 1200 spellpower Raid buffed, then Fireblast is still worth it. But it does lower the ceiling a bit.

You also have to balance it against other factors such as having to be within 26 yds vs. 36 yds, losing DPS because Fireblast may not be up when you have to reposition (and we all know there is a ton of repositioning now) and of course, higher mana consumption for those who sometimes find themselves without a shadowpriest or shaman.

Regarding queue or no queue, it's possible there isn't one of any sort but personally I find that I can reliably hit my next Fireball earlier on my casting bar than I could previously use /stopcasting. Previously I'd wait until I was just into the red zone, and now I can do it a bit before. This is definitely anecdotal and not something I'm going to swear by, but it seems to me that there is a small grace period.

I suppose the way this could be tested is to have a G15 or something pinging requests every 100ms or maybe less, and check the combat logs for when the "Spell failed" messages stop each time.

 

Lhivera

What is the correct way to calculate mean time between procs? The way I've been doing it in the TCoM is definitely not correct (I calculate how many events required for the chance to have procced to exceed 50%).

I seem to recall being told that the correct calculation is simply (Interval between events) / (chance to proc per event). For instance, Ashtongue trinket with 30% crit rate Frostbolts would be 2.5 / (0.3 * 0.5) = 16.67 seconds.

Can anyone clear me up on this? Thanks!

 

Vannik

So, you are saying fireball's timer is 3 seconds + 92ms for casting time, but you are using haste in your first calculations of fireball spam laetncy to make this a very inaccurate statement. The haste would make fireball 2.87ish like you mentioned. To be honest, you should understand this concept if you don't want people to keep bringing it up. If you were correct we wouldn't need to bring it up to invalidate your theory.

 

ebbv

I'm pretty sure haste doesn't reduce or increase latency, ergo why I continued to use the 92ms figure even for full length casts. Please direct your derogatory tone elsewhere, it's not at all helpful.

 

Ilmater

Please don't hate me, but I've done all the TC I care to on mages, I just have a quick question that is probably somewhere in here, but I really don't want to search for:

For frost mages after 2.3, is +dmg still favored over +crit rating?

Also, can someone link to the new 2/47/11 spec?

 

Muphrid

Yeah, it should just be time/chance. This is rather intuitive: you expect it to take 2 coin flips to see a head (or a tails). You expect it to take 6 die rolls to see a 4 (or any other number).

As I'm beginning to discover, a rigorous proof of this is a bit more difficult, but I do believe this is the case.

 

Copernicus

In general, yes.

Arawethion made a useful spreadsheet here - http://elitistjerks.com/f31/t18882-m...i-spreadsheet/ - if you just want something very quick and simple for comparisons. Lhivera's Theorycraft - Theorycraft-o-Matic - is also very useful. It uses a more complex model and tries to get an optomized DPS number. It will also display comparisons for gear.

The values of crit/haste/hit/dmg vary based on their current values. A general formula of hit > dmg >= haste > crit is true, but the actual values constantly change.