Добавлен Cancel
есть ли функционал на удаление событий указанного триггера?
если нет - то насколько дорогая операция по удалению триггера и созданию нового с добавлением всех действий и новых событий?
Будут ли формироваться утечки, если каждые 20-30 секунд таким образом создавать заново триггер и добавлять в него события на смерть 10-12 воинов (10-12 событий)
если нет - то насколько дорогая операция по удалению триггера и созданию нового с добавлением всех действий и новых событий?
Будут ли формироваться утечки, если каждые 20-30 секунд таким образом создавать заново триггер и добавлять в него события на смерть 10-12 воинов (10-12 событий)
Принятый ответ
Cancel, юзай общие события лучше
а юнитов проверяй в условии
а юнитов проверяй в условии
Чтобы оставить комментарий, пожалуйста, войдите на сайт.
Отредактирован Cancel
Юзал наработку для отсроченного удаления триггеров из доты, чтобы не было никаких проблем со стабильностью.
Cancel, но события еще вешаются на триггер, помимо юнита, поэтому его тоже удаляешь время от времени.
Что сделать то хочешь? Скажи что задумал?
Вообще я сделал по другому - отказался от работы с многочисленными группами юнитов. Посмотрел как работают функции на работу с ними - мне показалось они слишком затратные. Например - чтобы проверить пуста ли группа - цикл зачем-то проходит по каждому юниту из занесёных в группу, а не прерывается на первом встреченном юните.
Так что вместо массивных групп - я делаю массивные счётчики, и работаю с ними обращаясь в массиве через index = GetUnitUserData . При смерти юнитов убавляется счётчик udg_uGroup_enum[index], и когда он возникает нуля - запускаю триггер udg_uGroup_trigUnDead[index] - таким образом на карте постоянно спавнятся группы юнитов и я могу отлавливать события на уничтожения этих групп по факту используя только одно событие.
когда в группе юниты спавнятся - я раздаю им index, идентичный шаблону по которому они спавнятся и наращиваю udg_uGroup_enum[index] чтобы отслеживать количества в группах
а юнитов проверяй в условии