ebbv

It may be "Standard Practice" but it's still the wrong thing to do. From both a DPS perspective and managing mobs perspective. It's less DPS than 2 Arcane Explosions and makes the mobs likely to squish a Mage.

 

Shatters

or a healer for that sake, anyone on the aggrotabel within melee range.

so, this means you "need" a Logitech G-15 to perform top dps post 2.3?

 

Vessyra

So with the 2.3 changes, new gear available from ZA, Spellhaste, etc, will this affect the gear choices across the trees? I've been waiting for 2.3 to respecc back to fire. Prior to 2.3, I would have probably stayed arcane until out of The Eye, went and got my TLC and stacked crit. I'm looked at some of the numbers people are putting out with the new Meta gem, spell tax repeal, etc. and fire will again be as viable as I'd like, but I'm wondering how that will affect my gear choices? Has anyone noticed a different? I.e Is spellhaste better for Arcane and not as useful for fire, that sort of thing.

 

Docjowles

I have to believe they are going to rework this before 2.3 goes live. They've basically said as much already, see WoW Forums -> Upcoming 2.3 Changes - Concise List.

Having thousands of casters spamming the servers with hundreds of extra packets every second is very obviously a bad idea, and it seems Blizzard has found another approach.

 

Cardynal

Please read previous posts before asking the same question over and over.

 

Blinks

In before Manly.

Curious how they plan to approach this then.

 

Dustwhisper

Interpolation and extrapolation =) Just do it as they do on FPS games it would atleast work for fluidity and remove loss of casts or prolonged waiting for casts though arguably not the best approach.

 

Kythos

I have to agree that the MSD is an accessory to AM.

Not only is it too much of a pain to watch for the proc there are other things going on in a raid situation that are more important and should require your attention.

I feel that the new meta gem is more prominent for 2.3 Fire.
(to sum up some previous posts)

It allows the use of Yellow gems, noble topaz are very useful to stack what you are lacking.

It itself has .6% crit.

and above all, its new and pretty :P.

...Now if only we can get rolling ignites back. : P.

 

Keyne

I have absolutely no idea what you are trying to say here. Please refrain from putting up posts that have no direction and thus wander aimlessly; think about what you want to say before you write.

 

Rouncer

Continuing discussion on the thread linked by Doc.

Slouken's response:

The current solution on this build of the PTR is interesting and should work well if you have a stable internet connection but if your latency fluctuates you are going to lose a lot of casting time. Basically how it works if that whenever you press the casting button it starts a GCD on the client which prevents any casting requests from being sent to the server. If the client receives a "cast complete" message from the server while it is midway through a GCD it resets the GCD.

So basically it functions exactly like a /stopcasting macro but if you miss the window (send a new casting request early) instead of interrupting your previous cast it will force you to wait for the "cast complete" message to arrive from the server before you can start that next cast. Which would work very well on low-latency situations but if you were running around with 500ms of latency then missing the timing will lead to a lot of lost dps. Not as bad as missing /stopcasting and interrupting the previous cast but still significant.

If they stick to the current system the best way to use it will be to set up the G15 to spam and then try to hit the button as close to the red as possible and then hold it down till the next cast starts (that way if you missed you don't have to worry about human reaction times to notice that the next cast didn't start).

What I'm hoping is that they just go with what seems to be implied in the above two posts. Which would basically be a limited spell queuing (200-250ms) system.

 

Plouton

Why do you think so? Say, frost mage with Improved CoC, Piercing Ice and Arctic Winds has 1500 spell damage (quite high, to help AE which has better damage coefficient ).

CoC rank 6 = (429 + 0.1357*spd)*(0.35+1.06*1.05) = 925 dmg, with 200% crit.

Frost Nova, rank 5 = 343 dmg, with 200% crit.

AE rank 8, untalented (deep frost, yes?) = 392+0.2128*spd = 711 dmg, with 50% crit.

With crit chance 25%, Shatter and Winter's chill we has:

FN+CoC = 343*1.25+925*1.77 = 2065 dmg.
2xAE = 711*1.125*2= 1600 dmg.

And even without Improved CoC damage output for FN+CoC is still higher.
Also mobs are usually snared now, so if frost mage is really good, they have some troubles in squishing him.

P.S. All calculations made with spell damage coefficients from Spell damage coefficient - WoWWiki, the Warcraft wiki.

 

Dustwhisper

If you have such a high latency that you will start missing acknowledgement packets before your next cast you are already lagging so much that you are close to unplayable.

 

tedv

Interestingly, this is analogous to the anti-latency code they used in Quake 3. In Q3, there is a sliding window of how far out of sync a client's time can get with the server. Clients could be up to 200 ms ahead or 1000 ms behind, and it worked really well at handling the "chain casting" case (which is called "chain firing"). It also stopped people from applying time speed hacks, since movement was also timestamped. The solution is technically sound.

 

Rouncer

Your comment is very confusing to me.

The server sends out packets saying that the cast has complete when the cast actually has completed but the client is attempting to start the next cast before the client has received those packets in an attempt to remove latency from the picture.

Even with a 25ms connection if you are trying to /stopcast (with macro or under the new system) you are asking the client to send the request for the next spell 25ms before the server has even completed the cast, since you are trying to have the message reach the server the moment it completes the current cast and you have to allow for the travel time to the server from the client.

Whether your latency if 10,000ms or 100ms the same principal holds true and that is why I am so confused about your comment. Mind elaborating on your statement so that it becomes a bit clearer.

Exactly, that is why I really am hoping that Blizzard makes the final step and moves to that system. It has tremendous potential for allieviating all the current issues and without requiring anything special (be it a macro or a G15) from the player to accomplish it.

 

◊ manly

Ok so in other words, they don't want players to spam their fireball key to the server. But what about if instead I wrote a macro with fluff stuff in it (ie: redundant stuff that does nothing) and have that macro cast fireball. I don't see how blizzard could prevent users from spamming a macro to the server. They have to let the client send macros to the server even if you're within the GCD. This could effectively allow players to still spam the servers with fireball.

I'm thinking something like:
/stopcasting [target:noexist] (ie: this does nothing)
/cast fireball (ie: this is what we spam the server with)

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.

 

Rouncer

Except aren't macros also locked off from functioning during GCD, at least the spell cast portion of them.

The current system is the exact same as our current /stopcasting except the difference is that if you are too early instead of interrupting your current cast you are forced to wait your current latency to start the next cast, which is definitely a dps improvement over an interruption under the current system.

The only real issue is that people with very high latencies are still penalized more then anyone else and would still be better off playing Hunter's (provided the castsequence macro isn't broken) or Rogues or any class without a casting bar. Also any unstability in your latency can cause you to send the cast request early thus hurting dps. That system also rewards people for using things like the G15 since then they can try to time the spell perfectly but then have the G15 spam at 0.01ms intervals or something to catch the opening in the GCD if they miss the timing.

A "window of acceptance" would fix all the issues since then there would be no reason to spam at all provided you are inside that 250ms window when you hit the casting button since the server would just store the request and fire the spell requested the moment the previous one ended, basically a queue without the queue. It's pretty much the ideal solution to the issue from both sides of things, still have to be involved to get the spell to cast but you get a window where if you are too early (due to latency inconsistencies or operator error) you won't hurt your dps at all.

Hopefully they will incorporate all the aspects together into the casting system since that would be ideal without any issues that I can think of.

1. GCD on requesting a spell, even if one is already in progress.
2. Client can send a spell request at any time it is not in GCD.
3. If client receives spell completion from server it resets the GCD.
4. Server makes determination if it is eligible to start new cast whenever a request comes in.
5. Server has "window of acceptance" to allow casting commands that come too early to still function.

Can't see any issues at all with that system under any latency conditions.

 

Firefly

delete

 

Vektor

I wonder if they've considered a token-style client side rate limiter for spellcast attempts?

If each attempt to cast a spell before receiving a "complete" message was subject to a rate-limiter such as this, it would help the "people holding down a G15 macro all night" messagespam that's apparently causing problems.

Consider: each attempt to cast a spell before receiving a complete, interrupted, or failed message (ie. while your castbar is still ticking away) consumes a 'token'.

Note: any numbers I supply are purely for the sake of argument :P

You are given a maximum capacity of 10 'tokens', refunded once per 0.1s or so. Each attempt to cast a new spell while a spell is already being cast consumes a token. Each attempt to cast a new spell while the GCD is up consumes a token (to accomodate AE spam and "fastcasting" spells after an instant in general)

This means:

The rate limiter will not affect the speed of a spell which is not "fastcasted" - ie. if you're not already casting something, and your GCD isn't up, there should be no spellcast delay due to the limiter (as it should be - the limiter should never prevent or slow a spell cast under "legit" conditions, client-side)

The rate limiter will likely not significantly affect those who wait until the end of their spellcast to try to start their next spell (it will, however, punish G15 macro spammers as they will deplete their supply of tokens near the beginning of their spellcast)

The rate limiter lets the game very clearly define what is an acceptable level of spellcast spam, and never exceed that rate. Pick a value your servers can handle and that's that.

Consider (assuming a 10 'token' backlog, 0.1s to refund a token):

I'm casting a spell, and being smart, I'm waiting until the end of the spell to use my available 'tokens' to spam my next spell. I start at 0.5s remaining on the cast and plan to use all 10 available tokens - which results in an effective rate of 0.050s between attempts (one cast attempt every 50ms), which likely borders on reasonable - and still gives me a generous half-second "window" in which to cast my spell. If, for some reason, I manage to miss the half-second window, the most my spell can be delayed due to the filter is 0.1s (100ms) - which is still better than most people will achieve with stopcasting macros today.

Consider someone chain-casting 10 fireballs using a 25ms G15 macro with and without the aforementioned rate limiter:

Without limiter
25ms macro spam = 40 tries per second

With limiter
10 fireballs = 30s
Starting token 'stockpile' = 10 tokens
tokens are regained at a rate of one per 0.1s (10 tokens/sec)
30sec * 10 tokens/sec = 300 tokens regained over the course of 10 fireballs
300 tokens regained + 10 token 'stockpile' at the beginning = 310 tokens used
310 tokens / 30s = 10.3 tries per second (down by a factor of 4 from the macro spam without a limiter)

And, because this seems to be what most people will end up doing anyway:
With limiter, macro only spammed during the last 0.3s of a cast
10 fireballs @ 0.3s of macro spam time each = 3s of tokens regained while spamming your cast macro. At 10 tokens per second, this gives 30 tokens regained during the 'macro spam' period over the course of 10 fireballs.

The 10 token 'stockpile' will be fully replenished during the first 1s of every cast, giving the player 10 a token reserve to fire away during the 0.3s macro spam "burst" at the end of every spell. 10 fireballs @ 10 tokens each = 100.

100 tries from the 'stockpile' + 30 tries from regained tokens = 130 tries
130 tokens / 30s = 4.3 tries per second (compare to 40 tries per second without a rate limiter)

---

The actual numbers are, of course, flexible (I just picked easy-to-work-with numbers), but would (at first glance) appear to be effective in rate-limiting macro spam down to a reasonable value without further burderning the game servers (all rate limiting is done client-side, of course) without fooling around with any client-side fake global cooldowns or anything like that.

Of course, allowing a 'grace period' under the current system on the PTR would work about as well. It just really depends if they want to allow game servers to 'fudge' the timing on received spellcasts or not.

 

◊ manly

I am not saying in any way the change is bad. However, you do assume they will use a reasonable latency window (ie: 250ms) whereas I assume a worst case scenario where they would use something more akin to 50-100ms which could be very frustrating.

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.

 

Rouncer

It's a great idea but I think Blizzard is trying to limit the spam not only due to swarming the servers but also to keep the playing field level between people who have something like a G15 and people who don't.

 

Sackobones

To be honest, I don't want to have to buy a particular keyboard to ensure my DPS is competative.

 

Rouncer

Even 100ms wouldn't be bad since it basically just follows the same casting model we are currently working under with stopcasting but then gives you a little leeway to push for more dps and if you miss you aren't hurt too badly.

That said, 100ms wouldn't be bad for us (people working with normal latencies) but it wouldn't be sufficient to deal with the 500-600ms latencies dealt with by others. 250ms would be enough to help them while still keeping everyone involved in the game (which seems to be their aversion to using a queuing system) and without any real exploitability from something like the G15.

 

Vektor

You could always use a keyboard macroing utility such as AutoHotkey (AutoHotkey - Free Mouse and Keyboard Macro Program with Hotkeys and AutoText) to achieve the same result

*DISCLAIMER: I have no idea if using a software macro utility such as AHK is against the wow TOS or not. I have AHK installed and use it for general purpose day-to-day macros, but have never found a need to use it for wow. That having been said, I've also never had any trouble with the wow client as a result of having AHK. It seems to me that the functionality I'm proposing AHK be used for is absolutely no different than what is done with the G15 (which has been explicitly okayed, iirc), so in practice there's nothing ethically wrong with it. Practically, I have no idea how WoW people would view AHK. YMMV.

Merely create a keyboard macro for an existing key that loops, generating key events while the key of your choice is held down: AutoHotkey Tutorial: Macro and Hotkey Creation

This approximates the G15 functionality without purchasing additional hardware, which I feel is fair game insofar as software keyboard macroing goes.

Before recommending anyone actually make widespread use of this, I'd suggest researching whether or not the TOS prohibits AHK.

That all having been said, for the average player, there's probably very little practical difference between using a G15/AHK macro and mashing your spell key a few times, really fast, when the quartz bar goes into the red.

 

ebbv

You're making false assumptions that:

A) None of the Frost Novas have broken from another damge source in the 1.5 seconds before your CoC.

B) You are able to hit every target with your CoC (not impossible but a lot of times not possible.)

In the real world, 2x AE is better most of the time.

Edit:

Actually I wasn't satisfied with this. Your math bothered me and I'm also not the type of person to just "agree to disagree". Also I've never found a good way to fit Improved Cone of Cold into my PvE Deep Frost build, and you said it was still better so I'm doing my math without it. So, here's my results (this is still using the 2 false assumptions above):

1200 damage (far more realistic, IMHO.)
25% crit
1.06 Multiplier from Piercing Ice
1.05 from Arctic Winds
Shatter & Winter's Chill as well

Frost Nova, Base Avg 105, Coefficient 0.13
After +Damage = 261
After Talents Total = 290
After Crit = 362

Cone of Cold, Base Avg 429, Coefficient 0.13
After +Damage = 585
After Talents Total = 651
After Crit = 1035

FN + CoC = 1397


Arcane Explosionm, Base Avg 392, Coefficient 0.21
After +Damage = 644
After Talents Total = 644
After Crit = 724

AE * 2 = 1448

Most importantly, if you are in a situation where you CAN CoC everything:

CoC + AE = 1537





Regarding the current system on the PTR, I've got to think they're going to go to some kind of queue system. Spamming the server the way we're going to have to with this system is just going to be ridiculous. And what is the point really? There's no skill in it, it doesn't make the game more fun.

The obvious solution is allow a 1 spell queue, hitting Esc once would cancel the queue'd spell or if none, cancel the current spell. Are they afraid it makes the GCD meaningless? The GCD is to prevent you from being able to spam instant spells non-stop, it isn't supposed to have any effect on spells that have a cast time or are channeled (this is why casted spells under 1.5 sec have reduced GCD, of course.)

 

Vektor

I recall Blizzard asserting, in no uncertain terms, that they would not be implementing a spell queue.

I agree that these other systems are unwieldy kludges when compared to the elegance of a 1-deep queue, but that's what they've said.