• songster

OK, we all know that stopcasting macros are just about the single most important thing casters can do to improve DPS. We also know ('ware cross-thread) that the "average" player wouldn't know one from a hole in the ground.

So this post from Slouken may be of interest:

Bluetracker link: WoW BlueTracker: Casting Latency Trick - Exploit or Legit?

Apparently it's not spell queueing - wonder what other solution they've devised? Some kind of client-side version of the standard macros?

 

• Xei

I prefer having control over my own stopcasting - it adds a new element to raiding as a Mage, seeing as now I actually have to concentrate and not just spam fireball button whilst watching TV.

I also doubt they could make it as efficient as it is now - especially with varying latencies from people at differing distances from the server. From Australia I average around 500ms, no one in the US (majority playerbase) would suffer anywhere near that sort of latency.

"Being a leader is not a position of power. It is a position of service." ~ Barestomper

WTB Oceanic Horde PvE Players

 

Northerner

I did catch that post and it has me interested to say the least. No spell queue makes me sad but we can hope they come up with something functional anyhow.

I don't see a readily implementable solution though unless they kludge in a /trycast spam button or something? I mean, you could just make /stopcasting the default situation but that has a host of other issues for people that are conditioned to spam the button so I cannot see that route being chosen. If you allow the client to be trusted then you are opening up another can of worms again as well.

I just don't know at this point and 2.3 is far enough away that I'm not going to get too excited about it. Latency still is a massive issue though for casters and I'd love for them to put this to bed somehow. I do wonder why they simply skipped over what seems to be the easiest solution though.

 

Mythixl

A possible solution is perhaps a client-side version of the old fastcast mod; simply adjusting the casting bar dynamically based on the latency at the beginning of the cast.

However I foresee a large amount of technical problems with this. If you currently fail to cast a spell because you inadvertently stopped the cast either too early or too close to the divider between the red and blue sections of quartz, that's fine because that's at your discretion. But if the Blizzard fix started making you fail casts because of changing latencies, there would be little you could do about it.

Edit: Northerner, about spamming and stopcasting, if you bind a key to just /stopcasting and leave all your spells as is, you can simply hit a button bound to the macro at the right time and then mash away at whatever spell you wish to cast.

 

Northerner

I can't see that really being useful though Mythixl. I've long since cheerfully slaved macros for all my spells with /stopcasting and the idea of having to hit two keys doesn't appeal to me whatsoever.

I should be clear; the present system is quite workable. Quartz combined with macros (or Fastcast back in the day) gives me a reasonable latency effect with incredibly rare interrupts and quite rare 'bugged casts'. I still lose .1 to .15 on most casts from my own limited testing but such is life. The Holy Grail is a one-deep queue or equivalent system that would eliminate casting latency entirely and allow faster casting spells to be free of the present Casting_Time+Latency penalty affecting them more than is needed. Of course Blizzard would turn around and re-evaluate caster dps as a result but it would level the playing field at least.

 

• Xei

Latency is very dynamic and I really struggle to see a fix Blizzard could implement that would be as successful as people adjusting for it themselves. I don't like losing an element of control over my own casting to be honest.

"Being a leader is not a position of power. It is a position of service." ~ Barestomper

WTB Oceanic Horde PvE Players

 

panny

I imagine that Blizzard will implement some kind of server-side castbar and let them explicitly be 'desynced' from the client castbar, kind of similar to how movement is implemented.

 

Ichal

Thats not something to wish for though, is it? Unless you get a spell queue too.

You can queue up a lot of movement, and if it turns out something was illegal (due to being sheeped for instance), the server will reposition you. No problem.

Assume completely desynced casting:

If you make a cast too early, due to lower latency than at your last cast (client says ready, server is still casting when your next cast request arrives), the server can either tell you that "no, you can't cast now" and make you recast, or it can queue the spell. But Slouken wrote no spell queue.

You could end up in a situation where high latency players would be gambling on how soon after a cast ends (client side) they would dare start the next cast. It would suck extremely bad for healers.

 

stampy

Perhaps it will be implemented as:

If

• The player did not move during casts
• The second cast started within a reasonably small enough delay from the first cast that the delay can be attributed to lag

Then the server credits the delay between casts to the casting time of the current spell.

Fireball 1 starts a 0, casts at 3; fireball 2 starts at 3.15 due to lag, but gets that 0.15 credited back as lag, and goes off at 6.

There is no risk of cancellation, since the start times of the spells don't get fixed, just the end time. It might take a little time to get used to seeing your casting bar take a little jump forward half a second into each spell, but I doubt anyone would mind.

An interesting side effect is that, since the server will have to tell the client mid-cast that the casting time has been advanced, then for the first time ever we will have a perfectly accurate number for reaction time/network lag. Too bad we wont need it

 

stampy

hrm.... thinking about it more, I bet this is at least close to the idea. Then again, I've been told in the past that its far too easy for me to convince myself I'm right

The new mana/energy regen mechanics pro-rate ticks and realigns the tick timer so that regen activites are more predictable, and depend less on precise timing with respect to the timer and lag.

For this, instead of a tick timer, the server estimates when the optimal cast start time would have been; and instead of pro-rating the amount of regen, it pro-rates the cast time. It wouldn't surprise me to find out that someone was modifying the code for the new regen mechanics and realized that with a few tweaks, similar ideas could work to eliminate casting lag.

 

Demi9OD

Wow that would be nasty for caster dps.

 

• Apate

Any chance you might alter the thread title to sufficiently discriminate between How to use /stopcasting to maximize DPS or Latency and You ?

This is good news.

See you, auntie.
"You don't need a machine to make a rainbow. For rainbows are made of happy thoughts, and dreams, and chocolate unicorns, and gumdrops, and licorice sunsets, and fuzzy gumdrop bears, and sugar-coated chocolate gumdrop land."

Originally Posted by DeeNogger I am coming for you Apate.

 

• songster

Re-titled the thread.

Not just caster DPS - hunters will love it too. Don't think it should do much if anything for melee DPS though.

 

Caligula

So it would shorten the cast of the next spell by .15 seconds? That seems highly exploitable to me, especially with someone that has a high latency.

 

Bogeywoman

The only way to solve the problem without lots of craziness would be a server-side 1-deep queue which flushes on movement or interrupt. I wonder why they didn't take that idea into account.

The problem with the idea of catch-up time reimbursement is that people with high lag would suddenly have huge advantages. Consider a guy with 2.5s lag casting a 3s spell. For the first 2.5 seconds of the spell (while the server is unaware of what the client is doing), the guy knows he's casting a spell but nobody else does (hands don't glow, casting bar doesn't move). Then in the last .5 seconds, the message is received, the hands glow for .5s, the casting bar zooms to near the end, and bang the spell lands. So it'd help with PVE, but it would be dangerously exploitable in PVP, especially in the arena, where counteracting casting is a primary concern.

A server-side 1-deep queue would fix the PVE stopcasting problem (because no matter what your lag, the server gives you the option of posting what you intend to do next, and can instantly chain it to go after the current action/global cooldown), and would also not inconvenience PVP.

I think you're right that it's time reimbursement. WTB packet shaping NIC.

 

Nezralix

If the mage class is boring to play, then Blizzard needs to come up with alternative solutions to that. Making a class more challenging to play by making trivial actions be difficult is fundamentally wrong, and I think one of the classic areas where MMO's tend to go wrong. Giving players more things to focus on doesn't work if those things are unintuitive and frustrating by nature. Generally speaking, if some irritating aspect of the game has an obvious "gee, why didn't they just do <blah> so I don't have to do that" workaround, then that aspect isn't adding to the game.

 

Drundia

There are several several ways to solve the problem.

The current issue comes with the fact that when client thinks you are casting it blocks your new casts. Now, if I understand that post properly, client simply won't block casts in such situation any more. It will just send spellcast every time you smash button.

As for casting time reduction, it is actually already there and if you chain spells fast enough (currently only using /stopcasting) subsequent spells may get some time refunded. In particular this phenomenon when used with /stopcasting may eventually confuse client that it will think that you are not casting even if you do and will lead to sending spellcast all the time.

 

◊ Kalman

Yeah, ask hunters how much fun weaving shots is.

http://mmorchive.net

The WoW forums, explained:

 

Copernicus

I guess removing the "That spell is not yet ready" concept would work. Whenever a player hits a button to cast a spell, the message would get sent to the server no matter what- then the server would determine if a spell is still being cast, and if not it would then start a new spell. How it would look client side is anyone's guess. :/

 

Cheeky

How much would this begin flooding the server? People using gaming keyboards to trigger events very fast could generate 100s more messages to the server than are getting through now. Having the Client filter out this stuff while casting saves them bandwidth on the network and the server processors.

I'd love to see this solved. I'm betting raid bosses look really cool, and if I could ever take my eyes off of my autoshot cast bar (to time Steady Shot without clipping) I'd get to see them.

Cheeky of Havoc

 

Zakariya

Well, there are intelligent things you can do in the client. For instance a temporary blocking of "cast spell" messages to the server based on latency.

So, you start casting a 3s spell an you have 500ms latency. The client blocks you from casting another spell for 2.5 seconds (3s - 500ms) with the "Another action is in progress" message unless the client processed a move/interrupt. Once you're out of the 2.5s can't case time, any buttons you mash to cast another spell get sent.

So you'll still have 500ms (in this example) of potential spell-cast spam, but that's not that big a window.

 

Drundia

Server will disconnect you if you send too much traffic. This is how it works nowadays.

 

stampy

Its not actually shortening the cast time, its just making an intelligent decision as to whether the player is standing in one spot chain casting spells, or whether he is moving around or leaving gaps between casts. If he is judged to be chain casting, then it treats the end of the last cast as the start time of the next cast -- instead of the end time of the last cast, plus the latency to inform the client that the spell went off, plus the time for the player to hit the button again after client confirmation, plus the latency to inform the server we want to cast another spell.

To repeat -- the server makes an intelligent estimation as to whether or not a new spell was cast immediately after it received notification of the previous spell going off. If the server estimates that it is a chain cast, then the new spell goes off on the server (casting time) after the last spell went off on the server. No more macros. No extra traffic. No client changes, except being able to accept a message from the server that says "btw -- I'm giving you 123ms back on this cast." Nothing on the client decides when this should happen or if the client even wants it to happen. Client decisions tend to be exploitable.

A queue is entirely unnecessary. An intelligent server doesn't necessarily need a 3 second spell to start casting 3 seconds before it goes off. It just needs to make the judgement of "hey, I should pretend the player started casting this 173ms ago, because I know that his client probably thought it was clear to cast spells then, I know that he pushed the button around then, and I know for SURE that it wont be letting him cast spells faster than the cast time."

Its actually not very exploitable at all. The goal of eliminating the need for /stopcasting is basically to make a player with reasonable latency and button mashing speed be able to cast, for example, 10 3-second spells in 30 seconds; instead of 34 or 35 seconds.

The potential likely exploits would be causing spells to go off faster than their cast time (10 3 seconds spells in 29 seconds), moving while still maintaining full casting speed, being able to shorten the cast time of a spell when it is not a chain cast (running around, doing whatever, then stopping and casting a 2.85s fireball), or being able to make reactive decisions without a reaction delay (popping AM on a clearcast after a fireball, without incurring any penalty for waiting to see if it popped).

The server knows exactly when the last spell went off, and knows how long the current spell takes to cast, so it would be easy to enforce that you could never get extra casting time. This prevents latency exploits from providing a haste-like mechanic; eg, you could never cast more than 10 3-second spells in 30 seconds. This is bullet proof.

The server will know if you tried to move after the last cast, and it will find out before or at the same time it finds out that you want to cast another spell. If you move, you get no lag anticipation. This prevents latency exploits from allowing motion and perfect-speed chain casts at the same time. The only way to get some lag hacks for motion here is for a movement request to arrive at the server after the start casting request, in which case the server should immediately cancel the cast. Also bullet proof.

If you wait more than a fraction of a second after the last cast, your next cast will take (cast time + latency), just like with /stopcasting. This does not send the server a message that says, "hey, I have 2000ms lag, make my fireball go off in one second." This is the server crediting back time wasted in transit when it detects that you are chain casting. Any reasonable delay after a cast is completed by the client will reset the chain casting, and the next spell will have latency effects.

The hole in this implementation is that if a client (likely through a proxy that shapes and modifies WoW communication) could trick the server into thinking there was significantly more lag than there actually was, then the player may be able to open a window of time where they co