|
Originally Posted by Raknor
The error message you get if a spell can't be casted for some reason comes instantly in the next frame, it's not influenced by lag.
...
|
Actually if the client can determine a failure reason, it happens inside the CastSpell or CastSpellByName call (same thing for UseAction), and that isn't the issue. The issue comes about in the couple of hundred of milliseconds after the spell request has been sent to the server. For actions, we can use IsActionCurrent to determine whether the action "request" is currently in the queue, waiting for a response from the server. When we get a SPELLCAST_START/STOP/CHANNEL_START/etc., the IsActionCurrent state either changes immediately (instant spells, channeled spells) or stays current for the duration of the spell (normal cast-time spells, provided we didn't do a SpellStopCasting followed by another action immediately before, which confuses the client) or effect (stealth, etc.). For toggle type actions (channeled spells, stealth, etc.) its important to be able to recognize this IsActionCurrent behavior so that we don't accidentally allow the user to send the same action again and accidentally cancel it. (Yeah I know, thats what the default client does anyway if you double tap or spam you keys at the wrong time, but I'm trying to improve on that
).
We could (for example) simply disallow another CastSpell or CastSpellByName action until we get a server response (of some sort) if we can determine that the spell has gone to the server (e.g., we didn't get a failure generated by the client immediately) since unlike actions, you can't normally have more than one going at a time. But, then that would also prevent being able to use macros such as the common PoM + big damage spell that many mages like to use (since we'd be not allowing the second CastSpellByName call until we'd seen a response from the first call).
Alternatively, we allow both (or multiple) calls to go through, but then when we get the SPELLCAST_... responses back from the server, to which spells did they apply? Thats the tricky part of the whole thing, and you could probably craft some custom solutions for yourself that you understand the limitations of, etc., but making it robust enough for everyone to use would be a lot more work.
Bottom line, long term it'd probably be possible to implement CastSpell and CastSpellByName similar to how the UseAction code works right now in Fastcast, but identifying all the loose ends and corner cases is what makes it tricky, and at this point (for me anyway
) low priority.
Cheers
-- Cirk