| 07-11-2010, 02:07 AM | #1 |
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- JASS:call OnEvent(Condition(function test), EVENT_CUSTOM) And so I started thinking of a very simple snippet like this- 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 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 |
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 |
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. |
