Отображение Урона\Система атаки

каждый раз когда атакуем юнита к триггеру добавляется событие
и пофиг что это событие уже есть

я не понимаю каким ракообразным это надо, но опубликовал...

и в результате триггер запускается несколько раз
Buulichkaa, не публикуй
пример баганый
простейший дебаг во 2 триггере показывает что с каждой атакой по юниту количество выполнений триггера при получение урона увеличивается на 1
таким образом если юнита атаковали 5 раз то при получение урона триггер запустится 5 раз
и получается совершенно ложный результат
например если во 2 триггере не просто создавать плавающий текст а дамажить юнита то получается многократный урон
+ оператива тратиться зря
вот правильный пример
специально на гуи

У меня руки отпадают при виде этого ресурса ='((( что с миром

Sergant1000, у меня не копится
Buulichkaa, с миром хз, а вот люди деградируют

Sergant1000, если юнит умер то действие не произойдёт ибо некого дамажить
ты какую то ересь несёшь
и вобще действие лишь 1
просто в изначальном примере триггер запускался несколько раз
тут такой лажи нету
советую почитать про выполнение кода в вар3

nvc123, Действия нет, но событие остается, верно?

Timoxxx, события нельзя удалять
и толку от события если юнит привязанный к нему мёртв
так что в моём примере всё ок

nvc123:

Тем не менее - событие остается в памяти. И как быть рпг картам, где каждые 5 минут появляются с полсотни новых юнитов?

nvc123:

А если удалить триггер, к которому привязано событие? Это не гуи, конечно, но все-таки интересно знать.

Timoxxx, тут мнения расходятся
часть тестов показали что события висят в памяти
другая часть что они удаляются
Timoxxx, полсотни новых событий займёт меньше памяти чем 1 триггер с 1 событием
ведь событие это лишь регистрация юнита в системе
а триггер это полноценный объект

Sergant1000, мыслим в правильном направлении
nvc123, выполнение задания [1%] завершено

Sergant1000, он и так оптимален
во всяком случае 1 триггер, который я писал

События привязаны к объектам и очищаются при смерти объекта.

Clamp, я тоже так думаю но гугл даёт кучу мнений(многие из которых написаны нубами гуишниками)

А я располагаю фактами, которые, если вдруг кому захочется, можно раскопать в темах на форуме.
На эту тему Toadcop, J и, по моему, ADOLF провели весьма ёмкое исследование.

Извините за археологию, но думаю, что в примере правильнее проверять есть ли юнит в группе N и если нет, то заносить в группу и добавлять событие. Так не будет множества событий для одного юнита.

Audes, юнит не может дважды войти в игровую зону
так что проверка не имеет смысла

Я считаю, что эти заметки необходимо внести в саму статью:
Clamp:

События привязаны к объектам и очищаются при смерти объекта.

Audes:

Извините за археологию, но думаю, что в примере правильнее проверять есть ли юнит в группе N и если нет, то заносить в группу и добавлять событие. Так не будет множества событий для одного юнита.

nvc123:

Audes, юнит не может дважды войти в игровую зону
так что проверка не имеет смысла

Чтобы полностью развеять сомнения.

vincent_freeman, это статья лишь пример
да ещё и на гуи
если кого то интересует оптимизация то стоит почитать про неё отдельно статьи
а там уже написано что событие не утекает
а по поводу того что юнит не может дважды войти в игровую зону это ещё не подтверждено
хотя и не опровергнуто