Versiones comparadas

Clave

  • Se ha añadido esta línea.
  • Se ha eliminado esta línea.
  • El formato se ha cambiado.

...

This phase is responsible for handling the "request" from a spell caster - object which has initiated the cast. A request can be made from player client (see SpellHandler.cpp), or from the game objects itself (GameObject::CastSpell, Unit::CastSpell, etc). At this phase gameserver validates and prepares explicit target of the spell being cast. What is Explicit spell target? Ingame example is: your character has a spell, which has effect on an object you choose - by selecting the object with your character. In essence explicit spell target is the target, relatively to which spell selects who's going to be affected by the spell. As mentioned above, for client casts is most often the object you select. Serverside explicit target is selected by first parameter of Unit::CastSpell function. Not all spells require explicit targets though, a simple example is an AOE, no matter what you select ingame, targets around you are affected. Therefore, explicit spell target can be null, and that's natural. In case of many spells explicit target can be also a position on the ground, "blizzard" mage spell for example. What decices whenever spell needs explicit target? As you may have read in How to: Spell system , database decides about most of the spell's behaviour, so is in this case. Spell.dbc's target, implicitTargetA, implicitTargetB decide about that, briefly - flag in target field or implicitTargetX set to one of TARGET_XXX_TARGET (TARGET_UNIT_TARGET for example) target modes mean spell requires an explicit target. The most important consequence of this is that you CANNOT cast anything you want on anything you wish, it's all precisely decided by client database and only thing you can do is to follow those rules. Besides explicit spell target validation and preparation there are also done some premature checks for correctness of cast request - a Spell::CheckCast funcion is called (which uses db data for checks), there are also some checks done in cast request functions unfortunally spread all over the core. On failure, error is sent, otherwise spell is enqueued for execution on next object update, or handled immediately in case of triggered spells. Triggered is a kind of "system" cast, it's not precisely defined what that means exactly as the term is too overused too much to have any specific meaning, but setting the triggered cast flag alters a lot of spell's behaviour and db data interpretation. As an example, spells cast with triggered flag (a parameter of CastSpell()) will ignore item requirements set in dbc,  some caster state requirements and so on. After spell is prepared successfully casting begins, you see castbar ingame. You can follow the code of this phase by searching for Spell:(lengua)repare function occurences in core.

...

The finish phase occurs after all spell targets are processed, it's just a cleanup, just a few relevant event events happen in this phase.