crusader556
WarCraft 3

Нужно ли собирать триггеры с одинаковым условием в один

Добавлен
Вообщем суть вопроса такова - критично ли для карты наличие кучи триггеров с одинаковым условием, которые могли бы быть одним триггером, только сделанным через if do else(одно условие, к примеру "A Unit завершает строительство" и много if do else с разными юнитами и действиями) ? Нужно ли их собирать в один, или можно оставить как есть ? Недавно я обращался сюда по поводу странных багов в карте из за триггеров с условием A Unit Enters region, их было около 10 и после создания ещё пары таких триггеров, они стали вызывать баги. После того, как по вашему совету я собрал их в один(через if do else), баг перестал появляться.
Прикрепил пару примеров триггеров, которых можно было бы(но нужно ли?) обьединить. Хотелось бы понять, влияет ли это на работоспособность карты.

Black Soul:
Или заменяются только те, у которых не написано "Реакция на событие"
Заменяются все глобальные переменные. Например, последний созданный юнит - глобальная переменная. Реакции на событие всегда нативки, но вот что из них перезаписывается, а что нет - не могу сказать, надо тестировать вручную.
GetLocalPlayer:
но на практике это не имеет смысла.
Имеет большой смысл, потому что 1 триггер проще дебажить, что 100500. Более того, события могут конфликтовать, так как триггер с удалением юнита может сработать раньше, и для всех других триггеров с таким же событием юнита уже не будет. Что уж говорить про события каста.
GetLocalPlayer:
Между тем есть такая вещь как лимит операций, в который ты можешь когда-нибудь упереться если делать все через один триггер.
Скорее лимит операций будет достигнут во время инициализации при 100500 триггеров, чем при 1 триггере с if\then\else. А тут ещё есть Lua, где можно нормально сохранять функции, так что даже if\then\else не нужен. Аналогично, но немного хуже можно сделать и на Jass.
crusader556, делать надо так, как будет удобней. На GUI if\then\else сделан криво, потому удобнее будет делать несколько триггеров. Но тогда надо будет следить за ними, чтобы они не конфликтовали.
1 июл 2019
2 099
`
ОЖИДАНИЕ РЕКЛАМЫ...

Показан только небольшой набор комментариев вокруг указанного. Перейти к актуальным.
4
Показать
28
4
Показать
Black Soul:
У тебя на скриншотах ожидание 0.05 секунд. За это время constructed structure может быть заменено на другого юнита. Поменяй на triggering unit, чтобы не возникало багов.
Нет, проблемы не будет.
Загруженные файлы
2
Показать
4
2
Показать
PT153, странно. Я думал, что эти переменные заменяются. Или заменяются только те, у которых не написано "Реакция на событие"?
2
Показать
26
2
Показать
Black Soul, там лучше вручную всё проверять, есть случаи, в которых не будет правильно работать. Из-за этих случаев распространили ложную информацию, что все эти переменные всегда изменяются.
2
Показать
26
2
Показать
уменьшение числа триггеров положительно сказывается на карте
3
Показать
15
3
Показать
Не критично. Конечно же тут появятся специалисты грызущие глотку за каждую сотую долю процента производительности, но на практике это не имеет смысла. Между тем есть такая вещь как лимит операций, в который ты можешь когда-нибудь упереться если делать все через один триггер.
3
Показать
28
3
Показать
Black Soul:
Или заменяются только те, у которых не написано "Реакция на событие"
Заменяются все глобальные переменные. Например, последний созданный юнит - глобальная переменная. Реакции на событие всегда нативки, но вот что из них перезаписывается, а что нет - не могу сказать, надо тестировать вручную.
GetLocalPlayer:
но на практике это не имеет смысла.
Имеет большой смысл, потому что 1 триггер проще дебажить, что 100500. Более того, события могут конфликтовать, так как триггер с удалением юнита может сработать раньше, и для всех других триггеров с таким же событием юнита уже не будет. Что уж говорить про события каста.
GetLocalPlayer:
Между тем есть такая вещь как лимит операций, в который ты можешь когда-нибудь упереться если делать все через один триггер.
Скорее лимит операций будет достигнут во время инициализации при 100500 триггеров, чем при 1 триггере с if\then\else. А тут ещё есть Lua, где можно нормально сохранять функции, так что даже if\then\else не нужен. Аналогично, но немного хуже можно сделать и на Jass.
crusader556, делать надо так, как будет удобней. На GUI if\then\else сделан криво, потому удобнее будет делать несколько триггеров. Но тогда надо будет следить за ними, чтобы они не конфликтовали.
Принятый ответ
2
Показать
26
2
Показать
GetLocalPlayer:
Не критично. Конечно же тут появятся специалисты грызущие глотку за каждую сотую долю процента производительности, но на практике это не имеет смысла. Между тем есть такая вещь как лимит операций, в который ты можешь когда-нибудь упереться если делать все через один триггер.
в лимит операций ты так же упрешься если будешь плодить триггеры бездумно
0
Показать
12
0
Показать
PT153:
crusader556, делать надо так, как будет удобней. На GUI if\then\else сделан криво, потому удобнее будет делать несколько триггеров. Но тогда надо будет следить за ними, чтобы они не конфликтовали.
В каком смысле криво ? Это же по сути тоже самое, что и обычные отдельные триггеры, только собранные в кучку с помощью if\then\else. Так или иначе Jass я не осилю, а Lua будет смысл юзать только в reforged.(да и нет такой возможности щас, карта делается на 1.26а)
Прикрепил скрин триггера, правильно ли я делаю ?(один триггер специально раскрыл, другие скрыты т.к однотипные)
Загруженные файлы
2
Показать
28
2
Показать
crusader556:
В каком смысле криво ?
В Jass.
If something then

elseif something then

elseif something then

else

endif
В GUI можно сделать только так.
If something then

else
    if something then

    else

    endif
endif
crusader556:
Прикрепил скрин триггера, правильно ли я делаю ?
Почти. Убери Do nothing, а в каждый Then добавь в самый конец Skip remaining actions. Или делай ветвление if\then\else, но это некрасиво.
2
Показать
15
2
Показать
PT153:
Скорее лимит операций будет достигнут во время инициализации при 100500 триггеров, чем при 1 триггере с if\then\else.
Ну как же. Это верно если бы все условия для всех триггеров в карте были простые, однострочные, но они могут иметь вложенные конструкции и растягиваться на множество операций, в отличии от предсказуемой инициализации триггеров.
PT153:
Что уж говорить про события каста.
По этому поводу в самой теме хорошо высказались. Использовать подобный код - плохая практика. Все зависимости должны быть предусмотрены на этапе разработки, а не выявлены когда все покатилось как снежный ком.
0
Показать
12
0
Показать
PT153:
Почти. Убери Do nothing, а в каждый Then добавь в самый конец Skip remaining actions. Или делай ветвление if\then\else, но это некрасиво.
То есть в "То - Действия" нужно после всех моих действий там вписывать Skip remaining actions, чтобы оно пропускало "Иначе - действия", т.к там у меня ничего нет. Да ?
Показан только небольшой набор комментариев вокруг указанного. Перейти к актуальным.
Чтобы оставить комментарий, пожалуйста, войдите на сайт.