WC3
Вообщем суть вопроса такова - критично ли для карты наличие кучи триггеров с одинаковым условием, которые могли бы быть одним триггером, только сделанным через if do else(одно условие, к примеру "A Unit завершает строительство" и много if do else с разными юнитами и действиями) ? Нужно ли их собирать в один, или можно оставить как есть ? Недавно я обращался сюда по поводу странных багов в карте из за триггеров с условием A Unit Enters region, их было около 10 и после создания ещё пары таких триггеров, они стали вызывать баги. После того, как по вашему совету я собрал их в один(через if do else), баг перестал появляться.
Прикрепил пару примеров триггеров, которых можно было бы(но нужно ли?) обьединить. Хотелось бы понять, влияет ли это на работоспособность карты.
Прикрепил пару примеров триггеров, которых можно было бы(но нужно ли?) обьединить. Хотелось бы понять, влияет ли это на работоспособность карты.
Принятый ответ
Или заменяются только те, у которых не написано "Реакция на событие"
Заменяются все глобальные переменные. Например, последний созданный юнит - глобальная переменная. Реакции на событие всегда нативки, но вот что из них перезаписывается, а что нет - не могу сказать, надо тестировать вручную.
GetLocalPlayer:
GetLocalPlayer:
но на практике это не имеет смысла.
Имеет большой смысл, потому что 1 триггер проще дебажить, что 100500. Более того, события могут конфликтовать, так как триггер с удалением юнита может сработать раньше, и для всех других триггеров с таким же событием юнита уже не будет. Что уж говорить про события каста.
GetLocalPlayer:
GetLocalPlayer:
Между тем есть такая вещь как лимит операций, в который ты можешь когда-нибудь упереться если делать все через один триггер.
Скорее лимит операций будет достигнут во время инициализации при 100500 триггеров, чем при 1 триггере с if\then\else. А тут ещё есть Lua, где можно нормально сохранять функции, так что даже if\then\else не нужен. Аналогично, но немного хуже можно сделать и на Jass.
crusader556, делать надо так, как будет удобней. На GUI if\then\else сделан криво, потому удобнее будет делать несколько триггеров. Но тогда надо будет следить за ними, чтобы они не конфликтовали.
`
ОЖИДАНИЕ РЕКЛАМЫ...
Чтобы оставить комментарий, пожалуйста, войдите на сайт.
Ред. GetLocalPlayer
PT153:
Тогда смысла везде ставить Skip remaining actions нет.
А диалоги багнуты чутка, их лучше всего скрывать через EnableUserInterface.
- Есть логическая переменная Skip;
- Есть один диалог, в самом начале которого Skip=Нет, дальше между репликами стоит If Skip=Да Then Skip remaining actions Else // пусто//;
- Есть второй такой же диалог;
- Есть триггер с событием нажатия Esc и действием Skip=Да.
Если начать первый диалог и завершить, потом начать второй, то его будут прерывать реплики первого, словно он не завершался, хотя там же return произошёл, то есть действия должны прекратить выполнение. При этом, если сделать для двух диалогов переменные Skip1 и Skip2, то всё исправно работает.Только с началом второго.