Jesus4Lyf
Good Idea™
- Reaction score
- 397
Yep.
// - Shouldn't use "wait" actions anywhere in the triggers.
...
static method attackcheck takes nothing returns boolean
return GetAttacker() == Data(filter).caster and Data(filter).ticks > 0
endmethod
...
private function qwe takes nothing returns nothing
local trigger t2 = CreateTrigger()
call TriggerRegisterAnyUnitEventBJ(t2, EVENT_PLAYER_UNIT_ATTACKED)
call TriggerAddCondition(t2, Condition(function Data.attackcheck))
call TriggerAddAction(t2, function Data.stopattack)
endfunction
call TriggerAddAction(GT_RegisterStartsEffectEvent(CreateTrigger(), ID) , function a)
Dynamic triggers, adding/removing events, multiple triggers per spell, functions like a real WC3 event, and it's probably more efficient (haven't benchmarked). Also has events for items and all kinds of things.What advantage does this have over SpellEvent
Because this is meant to simulate a real WC3 event, not some vJass magic. This is much more efficient. I don't know if function interfaces even existed when I released this.Why doesnt this use function interfaces?
Not only is that an unfounded assumption, but I thoroughly believe it to be wrong. I don't think hashtables existed when I released this, either.Why doesnt it use Table to map AbilityIDs to triggers/functions (which would, now that we have hashtables, be the faster way)?
I'm just wondering, what does G stands for in GTrigger
Thats not an advantage.Dynamic triggers
Why would you EVER want to remove an event?adding/removing events
Which is not an advantage.multiple triggers per spell
Meh, dont care much for that.functions like a real WC3 event
I dont care for speed. Its not like this is a system where speed is mission-critical.and it's probably more efficient
Do you use them?Also has events for items and all kinds of things.
Once you realize vJass magic is better (for you, mostly) than a "real WC3 event", this point becomes void.Because this is meant to simulate a real WC3 event, not some vJass magic.
Yeah, because using triggers is SO different from function interfaces.This is much more efficient.
Yes, function interfaces already existed. Else, Anitarf wouldnt have used them in his system, which was released only 9 days after yours.I don't know if function interfaces even existed when I released this.
Yes, i havent done hashtable benchmarks myself, and from what i heard hashtables take about twice the time arrays take (feel free to refer me to better benchmarks). Your system does two arrays accesses PLUS HASHING.Not only is that an unfounded assumption
No, they probably didnt, but that shouldnt stop you from using them NOW.I don't think hashtables existed when I released this, either.
I can: use table and function interfaces.and I can't see any proven way to improve it.
from Troll-Brain:
Then i will probably use it.
"But" (Not your fault) that's a shame that we can't use the Null of the ascii table, we would be allowed to make "easy" mathematical links between stuff in the object editor.
Yup. Well, it did. I don't really know if it still does.global?
Using the object merger, I'm pretty sure it can be achieved.We can't simply press SHIFT and then edit and type a space then press ok?
Make your mind up.I dont care for speed. Its not like this is a system where speed is mission-critical.
...
Yes, i havent done hashtable benchmarks myself, and from what i heard hashtables take about twice the time arrays take (feel free to refer me to better benchmarks). Your system does two arrays accesses PLUS HASHING.
The one thing I do aside from writing efficient code with simple interfaces is I support backwards compatibility. There is no advantage from either table or function interfaces (the system already supports having a one-line spell event registration just like using function interfaces would) so I'm lost as to why you're suggesting this at all.I can: use table and function interfaces.
Why? My mind is already made up. Those two sentences dont contradict each other.Make your mind up.
Except that using function interfaces would clean up the API (as you wouldnt have to return false), and that using Table would simplify internal code, no, theres no other reason than "good style".There is no advantage from either table or function interfaces (the system already supports having a one-line spell event registration just like using function interfaces would) so I'm lost as to why you're suggesting this at all.
Portraying highly opinionated comments as absolute truth leads to flame wars (please don't).using a "proper" API now.
you should be looking at SpellStruct.