HomeUser Control Panel (unavailable in archive)ForumsTutorialsArt GalleryResourcesMaps

Interesting Idea for Triggers

07-11-2010, 02:07 AM#1
Nestharus
So, I'm doing all of these custom events (evaluate trigger, add, etc) and seeing tons of repeated code and what not. Then I thought, wouldn't it be nice if I could do this-

Collapse JASS:
call OnEvent(Condition(function test), EVENT_CUSTOM)

And so I started thinking of a very simple snippet like this-
Collapse JASS:
library Trigger
    struct Trigger extends array
        private static trigger array triggers
        
        private static integer instanceCount = 0
        private static integer array recycle
        private static integer recycleCount = 0
        
        public static method create takes nothing returns thistype
            if (recycleCount != 0) then
                set recycleCount = recycleCount - 1
                set triggers[recycle[recycleCount]] = CreateTrigger()
                return recycle[recycleCount]
            endif
            set instanceCount = instanceCount + 1
            return instanceCount
        endmethod
        
        public method destroy takes nothing returns nothing
            if (triggers[this] != null) then
                call DestroyTrigger(triggers[this])
                set triggers[this] = null
                set recycle[recycleCount] = this
                set recycleCount = recycleCount + 1
            endif
        endmethod
        
        public method add takes boolexpr c returns nothing
            call TriggerAddCondition(triggers[this], c)
        endmethod
        
        public method fire takes nothing returns nothing
            call TriggerEvaluate(triggers[this])
        endmethod
    endstruct
    
    function OnEvent takes boolexpr c, integer eventId returns nothing
        call Trigger(eventId).add(c)
    endfunction
endlibrary

Obviously, if supporting add/remove, could change it to takes code c returns triggeraction and TriggerExecute.

A library that might be using it would do this
Collapse JASS:
globals
    integer EVENT_CUSTOM
endglobals
    
struct EVENT_CUSTOM_STRUCT extends array
    private static method onInit takes nothing returns nothing
        set EVENT_CUSTOM = Trigger.create()
    endmethod
endscope

Sadly, you can't make it read only : (, but you get the idea.

So, if all libraries with events in them, like custom new unit events or indexing events or spell events, ran through this, the API would be much like JASS.

call OnEvent(condition, EVENT_CUSTOM)

: D

I'd just like to see what people think about this : ). I'm sort of eh because you need the event variables anyways, but = D.
Could actually do like GetEventUnit, GetEventTimer, and etc, with all of the stuff and recursion, but uhm... don't know if that'd be worth it.

That's why this is just an interesting thought at this point ^.^

The reason for destroying/creating would be for specific things like timers, handles, units, and etc.

like
call OnUnitEvent(condition, EVENT_UNIT_DECAY, unit)

or
call OnUnitTypeIdEvent(condition, EVENT_UNIT_DECAY, 'hpea')
07-13-2010, 07:41 AM#2
Tot
Collapse JASS:
        public method destroy takes nothing returns nothing
            if (triggers[this] != null) then
                call DestroyTrigger(triggers[this])
                set triggers[this] = null
                set recycle[recycleCount] = this
                set recycleCount = recycleCount + 1
            endif

really stupid idea to destroy triggers...
07-13-2010, 11:32 AM#3
WaterKnight
Destroying triggers is fine as long as there are no running executions of it anymore.

I am already using a custom event system. Events are created as structs and contain the information "type" (when the events starts), "priority" (in case different events of the same type have to be in a specific order), the actionTrigger (I pass a code argument to the create-function and transform it into a trigger inside, don't know whether you need to hold your boolexpr-object outside). Altough I haven't yet, you may also add sensitive parameters for like if a unit's speed drops below 300, you won't create an extra event type for "speed below 300" but "speed" with the sensitive parameters "below" and "300" or even "Unit changes state" with "speed", "below" and "300".

These events can then be assigned to various (and multiple) objects such like units, items, dialogs, to additional integer-types like unitTypeIds and also custom types (whatever you have of structs).

Each event type furthermore gets its execution code and from there fires the single events that are enlisted in possible subjects (maybe when a unit dies the dying unit could be a possible subject, or the killer, or the unitTypeId of the killer). Static events (subjectless events that always persist) could be useful, too.

Before the events are run you should also fill some event responses through global delivery.

Using events costs performance but you also save some by directly calling certain code parts instead of using if selections. Another thing is, that it's good for the operation limit because these code parts are then independent from others by obtaining an own thread and therefore you will have less undetermined thread lengths.