Добавлен PT153
Недавно узнал, что boolexpr очень быстрые и решил немного оптимизировать триггеры, что часто срабатывают. Но у меня появилась пара вопросов.
- Выгодно ли делать проверки if-ами в boolexpr, а в зависимости от результата и сами действия?
- Пусть есть функция foo и триггер Death с событием TriggerRegisterFilterUnitEvent(Death, SomeUnit, EVENT_UNIT_DEATH, function SomeFilter).
function foo takes something returns something
...
call KillUnit(SomeUnit)
...
endfunction
После call KillUnit(SomeUnit) сработает триггер Death. boolexpr SomeFilter унаследует поток foo или создаст свой?
- Зачем нужны следующие нативки и в чём их разница, если как boolexpr можно передавать функцию без аргументов, но с любым возвращающим типом?
native DestroyBoolExpr takes boolexpr e returns nothing
native Filter takes code func returns filterfunc
native DestroyFilter takes filterfunc f returns nothing
native Condition takes code func returns conditionfunc
native DestroyCondition takes conditionfunc c returns nothing
UPD (23.09.2018 15:30): Я использую Condition для конвертации в boolexpr, только когда code является переменной, а не явной ссылкой на функцию, потому что компилятор выдаёт следующую ошибку.
Во всех остальных случаях можно обходится без Condition и Filter, компилируется и работает хорошо.
Принятый ответ
Нет, проверки в болекспрах ифами не делают, а делают And или or ну и Not если необходимо. У болекспра событий свой поток, туда можно передавать аргументы только глобалками, кроме GetFilterUnit() там ниче не робит, это относится только к болекспрам у событий, у кондишенов триггеров и груп все будет работать. Так же советую завести глобалку
globals
unit bj_lastFilterUnit = null
endglobals
function Filter takes nothing reutrns boolean
set bj_lastFilterUnit = GetFilterUnit()
return IsUnitType( bj_lastFilterUnit, UNIT_TYPE_HERO ) and ....
endfunction
Насчет нативок
- удаление болекспра, не требуется т.к они кешируются и не плодятся, частоиспользуемые можно для удобсва заносить в глобалки, просто и удобно.
- Есть два типа болекспр, Filter и Condition, работают абсолютно одинакового, некто не заметил разницы.
`
ОЖИДАНИЕ РЕКЛАМЫ...
Чтобы оставить комментарий, пожалуйста, войдите на сайт.
Отредактирован quq_CCCP
Есть некий триггер:
Drynwhyl, a не про функции а операторы сравнения.
Так же как я уже писал некоторые события требуют болекспры, т.е позволяют отсеивать обьекты, на которые событие срабатывать не должно, это довольно удобно.
К примеру у вас один триггер на геройские абилки, он следит за тем что кто кастанул у него куча проверок и так далее а срабатывает он на всю шелупонь вроде крипов и даммиков которые нам не интересны, отсеиваем их в болекспре и ура.
Так же помните проверки на уровень абилки довольно медленные, лучше их не юзать там где код "крутится" постоянно, старайтесь обходить это проверками на GetUnitTypeId() или пытатся вручать абилку, если у юнита уже есть абилка с таким ид, функция UnitAddAbility вернет false и не добавит абилку, а если нету то вручит и вернет true это не особо то удобно и мало где применимо но может быть полезно если вы уж сильно увлекаетесь оптимизацией...
Отредактирован PT153
Отредактирован nvc123
я когда только начинал юзать джасс не раз сталкивался с тем что условие тупо не выполнялось до конца
поэтому все ресурсоёмкие проверки (например содержащие енумы или большие циклы) приходится выносить в триггерэкшион
выполнять действия в булекспере полный бред
т.е. их стоит использовать только для небольших проверок
Отредактирован PT153