Thread: SpellEvent
View Single Post
Old 04-10-2009, 01:57 PM   #10
Anitarf
Procrastination Incarnate


Development Director
 
Join Date: Feb 2004
Posts: 8,189

Submissions (19)

Anitarf has a brilliant future (903)Anitarf has a brilliant future (903)Anitarf has a brilliant future (903)Anitarf has a brilliant future (903)Anitarf has a brilliant future (903)Anitarf has a brilliant future (903)Anitarf has a brilliant future (903)Anitarf has a brilliant future (903)

2008 Spell olympics - Fire - SilverApproved Map: Old School Alliance TacticsHero Contest #2 - 3rd PlaceSpell making session 2 winner

Default

Quote:
Originally Posted by Vexorian
I don't like the blizz event response-like madness or that it has to save all event responses everytime, even though most of them are not needed or are empty.
Well, unless I require users to specify for every single spell what event responses it is expected to use (which I don't think is very practical), there's no way to avoid this. I could also make global switches for which event responses are used but in that case, as soon as one spell requires the targeted destructable, the system would have to call that event response on all spell events. In either of these two cases, you'd need a bunch of if statements checking whether an event response should be used, so it wouldn't be considerably faster than calling all event response functions indiscriminately every time.

There's also the option of only storing the event responses that don't work on the Finish and EndCast events and for the rest letting the user call the natives as needed, but the problem is that the only event responses that work on those events are GetSpellAbilityId (which the script needs to call anyway) and GetTriggerUnit (which pretty much every spell needs to call), so it's both faster to store those too as well as it standardizes all event responses to the same new format.

As for this format, I think wrapper functions which resemble the original event responses and get inlined anyway are better than direct struct access; I could do something with methods/method operators, where the user functions would take the struct as a parameter and then users would call them, something to the effect of set u = GetSpell.TargetUnit()//optional@ , but that doesn't look particularly different from wrapper functions to me.

Quote:
If the syntax for using event responses will be the ugly blizz-like one, I'd prefer to just use blizz' event responses rather than have to use those new hard to remember event responses that also consume extra time during events, I mean really, at least it would make it easier to port old spells to this.
Well, first of all, do event responses still work when you call a function via .evaluate/.execute? Second, how would reading a global array consume more time than calling an event response? Third, in neither of the previous two points is an issue, what's stopping you from using the original natives anyway?

Well, in any case, I'm open for syntax suggestions, that's why this is here.

Quote:
Not a fan of making it SpellEvent_RegisterEventResponse instead of just RegisterEventResponse, it is a little large, and public stuff are already non-scoped, but oh well.
Well, if the function names are specific enough to be unlikely to cause conflicts then the public keyword isn't needed, but on the other hand if you decide to use the public keyword you can shorten the function name. SpellEvent_RegisterEventResponse can easily be shortened to SpellEvent_RegisterResponse, while RegisterEventResponse alone is kinda too general and would need to be lengthened to RegisterSpellEventResponse anyway, which in the end brings us to about the same length. Now the only question is whether the underscore is too much of an aesthetic problem.


Quote:
Originally Posted by Rising_Dusk
You wouldn't lose backwards compatibility by adding a function call with different parameters, though. There'd be nothing to remove. I guess if you removed the public prefix for those functions, then it might be different.
I'm not really a fan of having two sets of functions that do the same thing. If there were some functional difference that'd be one thing but to have two functions that only differ in style is too much.

Quote:
You also still haven't fixed the spelling of library in the beginning of the script.
Oh, right, fixed now.
__________________
Anitarf is offline   Reply With Quote