Poster: Timi at 6/20/2006 10:43:09 AM PDT
Subject: Please make spellcasting events more general. |
| |
It is common in mods to want to detect, and react to, the casting of spells. Spells can be cast in many ways, and there is no one API function that all spellcasting goes through that a developer can hook. The next best option, it seems, would be to listen to events; after all, you can detect when a spell starts with SPELLCAST_START, right?
Only instant spells don't give SPELLCAST_START, and SPELLCAST_STOP won't tell you what spell stopped.
1. Since instant cast spells give only SPELLCAST_STOP, give SPELLCAST_STOP two arguments:
a. The name of the spell.
b. The target of the spell.
2. Either make it so SPELLCAST_STOP doesn't fire on failed spells, provide an event which fires ONLY on successful casts, or provide another argument indicating the kind of stop. Or, at the VERY least, ensure that SPELLCAST_FAILURE or SPELLCAST_INTERRUPT is guaranteed to precede the SPELLCAST_STOP message for the same spell.
Right now, if you want to detect whether a user has cast or is casting a spell, and know the name of the spell and have a guess as to the target, you have to hook:
CastSpell
CastSpellByName
UseAction
TargetUnit
SpellTargetUnit
SpellStopTargeting
... and possibly others. That's just off the top of my head. Because spells may require targeting, you have to store the name of a spell which may never even be cast, then detect that a targeting event has happened which PROBABLY indicates the target for that spell.
Sorting out special cases (mods like CastOptions that replace a target automatically, for instance, or the target of a healing spell) is even harder.
But the application OBVIOUSLY has the answer to these questions available. Why not just put in some arguments for these events, so we can listen to the events and not have to hook five other functions to find out what the events are about?
Not to use hyperbole, but I've thought and thought, and I can't conceive of being asked to design the events and concluding that SPELLCAST_STOP doesn't even need to record what spell just ended, unless you were firing SPELLCAST_START on instant spells anyway.[ post edited by Timi ]
| | | http://forums.worldofwarcraft.com/thread.aspx?fn=wow-interface-customization&t=397357&p=#post397357 | | | Poster: slouken at 6/20/2006 4:25:04 PM PDT
Subject: Re: Please make spellcasting events not suck. |
| |
Q u o t e:
Please stop making sense, until the server is back up I can't debug my addon, and I want forum drama.
...
But really, I see your point. I was thinking of these events, because they are the ONLY spellcasting events, as being a way to detect spellcasting activity.
If they are looked at solely as "how you would implement a casting bar", they make sense.
So, okay. They do what they are supposed to do. However, it seems like it would be VERY easy to extend them (without even breaking compatibility!) to make them useful for a VERY common task which is currently excessively complicated and performance-intensive.
By the way, just to address this frequently asked question, Esamynn is exactly right in how the events were created and their intended use. Extending them would be pretty easy, but it falls into the question of whether it's appropriate for the UI to be reacting to spell casting. Since the designers haven't made any firm decision, and nothing in the default UI requires any extension of the events, we haven't spent any time on it.
Edit: I almost got Esamynn's name right. :)[ post edited by slouken ]
| | | http://forums.worldofwarcraft.com/thread.aspx?fn=wow-interface-customization&t=397357&p=#post397783 |
View all recent official Blue Posts
|
