SpellEvent

[Anitarf]

Updated. The script now doesn't create a location on widget targetting spell casts.

I haven't quite decided on the user syntax yet, the current script includes two versions, GetAbilityId() and GetSpell.AbilityId(), another possibility would be SpellEvent.AbilityId. I'd like to decide on one of them and delete the rest before this gets approved. Opinions?

[grim001]

Last one.

[Rising_Dusk]

Yeah, scrap the public prefixes. I'd never use this just because of that.

[Anitarf]

Originally Posted by Litany

GetAbilityId, GetAbilityTargetUnit, IsAbilityFinished, etc. Blizzard is inconsistent with Spell and SpellAbility, but that doesn't mean you have to be.

Inconsistent? It seems to me that "Ability" is used when dealing with any ability, including passives, while "Spell" is used when dealing with spell events. Hence UnitAddAbility (can add any ability, not just spells), GetSpellTargetUnit (only works on spell cast) and GetSpellAbilityId (gets a generic ability id on a spell event). That seems perfectly consistent to me.

Consistent use of Ability in the function names also removes the need for the public prefixes, which are incredibly ugly.

Originally Posted by Rising_Dusk

Yeah, scrap the public prefixes. I'd never use this just because of that.

Okay.

So, I've decided to make the UI work either like this: local unit c = SpellEvent.CastingUnit or like this: public function interface Response takes integer abilityId, unit castingUnit, unit targetUnit, destructable targetDest, item targetItem, real targetX, real targetY returns nothing I don't think anyone will like the latter, so I'll just write the former.

[wraithseeker]

Doesn't this do the job although you guys banned that user.

[Anitarf]

Originally Posted by wraithseeker

Doesn't this do the job

No.

Well, based on my testing there is no way for a unit to start casting a new spell without first stopping the casting of the previous spell, so the safety check in the EndCast function is not needed and will be removed in the next version.

Edit:

Originally Posted by Litany

I find combining spell and ability in general to be inconsistent. They're treated as virtual synonyms in WC3, so the distinction here makes no sense. And of course, they actually aren't synonyms, which makes it even worse. Ensnare is not a spell, so why should the word "spell" figure in the event responses?

It may not be consistent with our understanding of the word (which would mean specifically magical abilities) but the word's use within WC3 natives is internally consistant as it is used to refer to activated abilities, as such it is also not synonymous to the word "Ability" which can refer to any ability, not just an activated one.

Edit 2: Well, I just realised I can't make static method operators so I guess I'll need to come up with a different UI.

[Anitarf]

Updated, I managed to get the syntax I wanted although it required some tweaking to maintain proper encapsulation. The user could in theory still call .destroy on the struct since I can't make that method private but the system can survive that, the user would eventually get an error message about trying to destroy a null struct.

I realize now I forgot to add the method operator for TargetLoc, gotta run now so I'll fix that later.

[Anitarf]

Originally Posted by Anitarf

I realize now I forgot to add the method operator for TargetLoc, gotta run now so I'll fix that later.

Okay, I fixed this now, also the usage example was still using the old syntax in one place, fixed that too. This should be it, I think.

[Tyrande_ma3x]

> SpellEvent.CastingUnit
Is there any way this could become TriggerUnit? I think most people don't usually use GetCastingUnit() and it's going to be a bit hard with all those switches between names.

[Anitarf]

Casting unit is more descriptive, though. And what switches between names, all event responses are copies of natives with "GetSpell" replaced with "SpellEvent." (minus those responses that are new), so there's only one switch.

[rain9441]

I use pretty much the same concept for registering for events for abilities. Just want to quickly add that you also have access to the OrderID of the casting unit at some stages (not all) which is very handy in some circumstances.

I dunno, it allows me to say when a unit casts a spell and some conditions exist, create a dummy unit, add the ability to the dummy unit, set the level of the ability to that of the casting unit, and order the dummy unit to (orderid) the target again, or the x/y coords again, or the item again, or "immediately", or at a random unit within 300 of target, etc, etc, etc.

Ability Level may also be useful, as the level when casted may not be the level 1 second later.

Also, any reason the EVENT_PLAYER_UNIT_SPELL_CHANNEL event is unsupported?

Thirdly, why set a global variable to the current spell event when you can pass the spell event to the Response function?

[Anitarf]

Spell level and orderid are useful information, I'll look into including them in the event responses. The level itself might not be as useful since if it's a channeling spell (which is the only case I can think of where you could increase the level before the spell finishes) you will likely create a struct when the channeling starts anyway and you can store the level there, but since it's the kind of event response function that will likely get called anyway there's no loss of performance if it's included.

In my experience, EVENT_PLAYER_UNIT_SPELL_CHANNEL doesn't do anything special, it just seems to run after the cast event for all spells. If there is some significant difference, I might include it.

I use a global variable instead of passing it as a parameter because it simplifies the function interface somewhat ("takes nothing returns nothing" is easier to remember) and you don't have to pass the struct to any functions you call.

[Vexorian]

channel IS useless. Effect is better there.

I use a global variable instead of passing it as a parameter because it simplifies the function interface somewhat ("takes nothing returns nothing" is easier to remember) and you don't have to pass the struct to any functions you call.

ah the sound of losing abstraction over worthless code length saving.

but well, it has been in the submit forum for enough time approved...

[Anitarf]

Alright, I fixed a minor bug that could cause a unit-target spell to keep the TargetDestructable value from a previously cast destructable-target spell.

Also, I did a small tweak to facilitate spell transmutation, check out the second usage example for more information.

[Viikuna-]

Doesnt _CHANNEL trigger before casting time? I have used it to change units casting animation in some cases.

( Dont know if _CAST does the same thing, but I was under impression that _CHANNEL triggers before _CAST )