Caster System and ExecuteFunc

If there is a bug with ExecuteFunc that makes it not function if the distance between the call and the desired function is too large, would it be possible to have alternatives callbacks in the caster system?

For example:

Which executes the given trigger instead of using ExecuteFunc. (I am assuming that executing a function as a trigger and using ExecuteFunc has the same benefits of getting a seperate thread?)

no way. The idea is to avoid having triggers if you are going to use a trigger just register the event. I am not going to change my life style because of stupid bugs by blizzard and the distance is way too big anyways, if you ever get the bug then you have to optimize your script and make it shorter

I have been thinking about something related to this, but since my knowledge of the war3 internals aren't perfect, maybe you can tell me whether I right or wrong.


If ExecuteFunc can time out looking for the function to call, does that not mean ExecuteFunc is a function that requires (at least in larger scripts) a certain amount of computation?

If that is true, would not storing a system that takes code objects instead of strings of function names, and uses triggers for callbacks (as you do in pretty much the rest of the castersystem already) be faster?

I am not asking you to change your lifestyle. In fact, I don't need you to add this. I just wondered why it would not be beneficial to have a bug-free and (unless you explain to me why not) faster alternative. Also, what exactly do you gain by "avoiding triggers" to use and using ExecuteFunc instead?

Anyway, no need to do anything about this for my sake, my script parser can generate different register-functions for my abilities.

Triggers are objects that take memory.
I am not going to fix blizzard's mess again, I am tired of doing that and it is a shame that blizzard did nothing to fix this problem that was reported a good while ago.

ExecuteFunc has the advantage of taking strings . And unlike triggers it won't leak any object after using them.

Triggers leak trigger actions and cleanning them is always a problem.

When you have a lot of triggers with the spell effect trigger all of their conditions will be evaluated each time you cast a spell, instead if you use the events of the caster system it will only evaluate one HaveStoredString , which is for sure faster than 20 GetSpellAbilityId()==value comparissions.