Добавлен TechnoViking
Лично я картодел не очень хороший, но один очень умный в этом деле человек посоветовал мне все однотипные по ивенту триггеры загонять (как скот в один хлев) в один многоэтажный триггер с одним ивентом. И ввиду того, что я делаю крупную мили-РПГ карту, мне теперь важна каждая такая мелочь, ибо в совокупности по итогу оно люто скажется, я думаю.
Вопрос вот в чём - юзает юнит спелл, и пошла вся эта шобла этажная искать, а какой же спелл юзнулся. Нашла, сделала, что надо, и пошла дальше, хотя уже вроде как сделала, что нужно, но дальше всё равно поискала (вроде как это так работает, поправьте меня, если я ошибаюсь). А это же лишние силы триггерные. К чему их тратить впустую? И мне вот что сделать захотелось - заставлять триггер сбрасываться после каждой "своей" находки нужного. Я начал пихать в каждую "находку" вот это:
Подскажите, пожалуйста, я дичь делаю, или всё чётко-ровно и так и нужно?
Принятый ответ
Не такой уж и умный, если посоветовал такую глупость.
Оптимизировать надо когда это надо, а не когда это лучше. В твоем случае даже появляется угроза превышения лимита операций, что приведет к прерыванию работы триггера, не говоря уже о невозможности поддержки такой гигантской лестницы условий.
Оптимизировать надо когда это надо, а не когда это лучше. В твоем случае даже появляется угроза превышения лимита операций, что приведет к прерыванию работы триггера, не говоря уже о невозможности поддержки такой гигантской лестницы условий.
Это так называемый оператор возврата из функции return, который завершает работу функции. Тебе это мало о чем скажет, но например такая конструкцияПодскажите, пожалуйста, я дичь делаю, или всё чётко-ровно и так и нужно?
не завершит работу всего триггера, а лишь цикла, вернее, текущей итерации цикла. При этом цикла группы юнитов или группы игроков, но не цикла целочисленных "от A до B", который может быть как внутри триггера, так и внутри цикла группы юнитов/игроков.
В общем, от такого хорошего совета ты сразу влез в океан условностей которые предусмотреть не сумеешь. В итоге такая "оптимизация" лишь породит кучу новых ошибок.
Загруженные файлы
`
ОЖИДАНИЕ РЕКЛАМЫ...
Чтобы оставить комментарий, пожалуйста, войдите на сайт.
Отредактирован GetLocalPlayer
Оптимизировать надо когда это надо, а не когда это лучше. В твоем случае даже появляется угроза превышения лимита операций, что приведет к прерыванию работы триггера, не говоря уже о невозможности поддержки такой гигантской лестницы условий. Это так называемый оператор возврата из функции return, который завершает работу функции. Тебе это мало о чем скажет, но например такая конструкция
Отредактирован PROSHELDOTU
но не скипать действия, как ты не правильно понял, а не плодить кучу однотипных триггеров
типа в одном триггере событие умирает юнит такой-то, то делать то то
а другой триггер с таким же событием, но на другого юнита, например
И я сказал ему, что это можно как бы в одном триггере всё отслеживать и т.д. по аналогии с другими событиями