Добавлен PT153
Заметил, что все методы структур потом конвертируются в УСЛОВИЯ триггеров, а после выполняются с помощью TriggerEvaluate(). Мне стало интересно, почему так? Почему они не конвертируются в действия?
Точнее, некоторые конвертируются и в действия, и в условия.
Точнее, некоторые конвертируются и в действия, и в условия.
//Generated method caller for Arrow.update
function sc__Arrow_update takes integer this returns nothing
set f__arg_this=this
call TriggerEvaluate(st__Tower_update[18])
endfunction
function sa__Arrow_update takes nothing returns boolean
local integer this=f__arg_this
call s__Arrow_reduceCD(this,s__TowerUpdater_period)
call SetItemCharges(s__Arrow_physatt[this], R2I(s__Arrow_getDamage(this)))
return true
endfunction
...
set st__Tower_update[18]=CreateTrigger()
call TriggerAddCondition(st__Tower_update[18],Condition( function sa__Arrow_update))
call TriggerAddAction(st__Tower_update[18], function sa__Arrow_update)
Как последнюю строчку парсер пропустил?
TriggerExecute() в коде нигде нет, тогда зачем TriggerAddAction()?
Действие добавляется, только если метод является перезаписываемым в наследниках структуры (stub method).
TriggerExecute() в коде нигде нет, тогда зачем TriggerAddAction()?
Действие добавляется, только если метод является перезаписываемым в наследниках структуры (stub method).
Принятый ответ
TriggerEvalute наследует поток из которого запущен, а так же проверяет условие триггера, возвращая результат.
Мб. так было проще передавать аргумент. т.к триггер и поток из которого мы запустили триггер один, т.е работают GetTriggUnit\GetExpiredTimer и так далее.
Мб. так было проще передавать аргумент. т.к триггер и поток из которого мы запустили триггер один, т.е работают GetTriggUnit\GetExpiredTimer и так далее.
`
ОЖИДАНИЕ РЕКЛАМЫ...
Чтобы оставить комментарий, пожалуйста, войдите на сайт.
Мб. так было проще передавать аргумент. т.к триггер и поток из которого мы запустили триггер один, т.е работают GetTriggUnit\GetExpiredTimer и так далее.
Отредактирован PT153
И это нормально, что TriggerAddAction берёт функцию, которая что-то возвращает?
Ещё вот что интересно. В TriggerAddCondition() можно просто передавать функцию (то есть без Condition), причём даже функцию, которая возвращает что-то отличное от boolean (вроде). Но тут всё же используется функция Condition(). Зачем?
Хз, мб какой какая то конструкция юзает действия триггеров, или это своего рода массив code, т.к мы не можем обьявить массивом code, а следовательно хранить массив функций тоже нельзя...
Ну тут кондишены и экшены триггера этакий массив, Condtion(function) еще примечателен тем, что он не вызывает утечку типа triggercondition т.к акшин триггера навсегда остаётся висеть в боллекспре, triggeraction же нужно обязательно удалять, иначе будут утечки.
Это в том случаи если триггеры создаются и удаляются динамически.
Не было тогда еще мемхака, а о ретунд баге знали очень мало, а так же что он ненадежен (его пофиксят).
Сейчас вовсе можно без этих методов обойтись и передать инт в функцию, к примеру как тут.