 |
|
 |
|
|
[Вопрос] Юнит получает урон (событие)
|
|
| FatalBlade | Дата: Среда, 28 Сентября 2011, 23:33:29 | Сообщение # 1 |
10 уровень
Группа: Проверенные
Сообщений: 1523
Награды: 0
Репутация: 439
Блокировки:  | У меня есть спелл, который активируется на время. За это время, если героя бьют, то ему не наносится урон, а наоборот, он лечится.
Триггер срабатывает когда юнит заюзал спелл.
Значит есть вот этот отрывок:
Code if ( IsUnitInGroup( u, udg_GOTMGroup[o] ) == false ) then
call TriggerRegisterUnitEvent( gg_trg_GOTM_Damage, u, EVENT_UNIT_DAMAGED )
call GroupAddUnit( udg_GOTMGroup[o], u )
endif
u - локальная переменная (GetTriggerUnit())
udg_GOTMGroup[o] - в данном случае не обойтись без глобальной группы (ИМХО), потому что группа не должна удаляться или чиститься, она постоянно должна пополняться, и естественно не добавлять событие Получает Урон для тех юнитов которые УЖЕ в группе, так как на них это событие уже есть. Сама переменная - это массив групп юнитов, размеров в 1..10, то есть для каждого игрока ячейка (у меня карта 5 на 5).
о - Номер игрока (владельца юнита u)
Мой вопрос: вот я написал call TriggerRegisterUnitEvent( gg_trg_GOTM_Damage,u, EVENT_UNIT_DAMAGED ), то есть в то место где указывается юнит который получает урон, я вписал локальную переменную. А ведь событие то добавляется в другой триггер, то есть там уже локалка не должна работать.
Однако с другой стороны, я ведь добавляю событие в другой триггер, с конкретно указанным юнитом который должен получить урон, и даже если ссылка на него теряется, всё равно Id юнита ведь есть, как и сам юнит. То есть юнит как бы становится конкретным обьектом (Generated Global Variable). И уже в триггере куда добавляется событие, этим юнитом можно манипулировать с помощью ссылки GetTriggerUnit()
Так вот: прав ли я?
З.Ы. Прошу прочитать мой вопрос внимательно
 |
| |
|
|
| Ty3uK | Дата: Четверг, 29 Сентября 2011, 07:56:58 | Сообщение # 2 |
Группа: Ветераны
Сообщений: 6125
Награды: 2
Репутация: 1617
Блокировки: | Мб все-таки проще сохранить в хэш?  и уже с него вытаскивать значение локалки, не? 
|
| |
|
|
| SirNikolas | Дата: Четверг, 29 Сентября 2011, 10:47:58 | Сообщение # 3 |
Группа: Модераторы
Сообщений: 6729
Награды: 1
Репутация: 1867
Блокировки: | Quote (FatalBlade) udg_GOTMGroup[o] - в данном случае не обойтись без глобальной группы (ИМХО) Quote (FatalBlade) А ведь событие-то добавляется в другой триггер, то есть там уже локалка не должна работать. Quote (FatalBlade) Триггер срабатывает, когда юнит заюзал спелл.
|
| |
|
|
| FatalBlade | Дата: Четверг, 29 Сентября 2011, 12:16:12 | Сообщение # 4 |
10 уровень
Группа: Проверенные
Сообщений: 1523
Награды: 0
Репутация: 439
Блокировки: | Моя теория верна Всё работает 
Quote (SirNikolas) Ты прав, глобальная группа нужна, но одна, а не массив.
Да я тоже думал об этом.
Quote (SirNikolas) Нет, надо, когда выбрали этого героя, или при изучении способности. Зачем тебе лишние запуски триггера? BTW, тогда можно и без группы.
А это идея!Добавлено (29 Сентябрь 2011, 12:16:12)
---------------------------------------------
Но мне пришлось сделать массив булеан, типо чтоб проверял активирован ли скилл у данного героя.
|
| |
|
|
| FkoFF | Дата: Четверг, 29 Сентября 2011, 19:30:11 | Сообщение # 5 |
Группа: Заблокированные
Сообщений: 4356
Награды: 1
Репутация: 1413
Блокировки: | Quote (FatalBlade) То есть юнит как бы становится конкретным обьектом (Generated Global Variable)
Бредятинка... Generated Global Variable тут вообще не при чем.
Quote (FatalBlade) Но мне пришлось сделать массив булеан, типо чтоб проверял активирован ли скилл у данного героя.
Допотопные методы... -_-
Хэш таки лучше.
|
| |
|
|
| FatalBlade | Дата: Четверг, 29 Сентября 2011, 19:44:30 | Сообщение # 6 |
10 уровень
Группа: Проверенные
Сообщений: 1523
Награды: 0
Репутация: 439
Блокировки: | Quote (FkoFF) Бредятинка... Generated Global Variable тут вообще не при чем.
Короче этот юнит становится таким же обьектом как и те юниты которых ты расставляешь на карте в ВЕ.
Generated Global Variable - это вот это, если я не ошибаюсь -->> gg_unit_h02F_0082. То есть юнит поставленный не триггерно, а в самом ВЕ.Добавлено (29 Сентябрь 2011, 19:44:30)
---------------------------------------------
Quote (FkoFF)
Хэш таки лучше.
Как в данном случае поможет хэш? Типо с хэшем можно сделать, но как проверять активен ли скилл у героя? Тут нужна переменная
|
| |
|
|
| FkoFF | Дата: Четверг, 29 Сентября 2011, 22:38:29 | Сообщение # 7 |
|
Группа: Заблокированные
Сообщений: 4356
Награды: 1
Репутация: 1413
Блокировки: | Quote (FatalBlade) Как в данном случае поможет хэш? Типо с хэшем можно сделать, но как проверять активен ли скилл у героя? Тут нужна переменная
эээ,, вообщем юниты статично все в триггере, на всех сразу определяется нанесенный урон. А хэш лишь по хэндлу привязывает уровень полученного баффа, вроде того.
и уже в самом триггере примерно такая строчка:
local unit u=GetTriggerUnit()
local integer tuid = GetHandleId(u)
...
if LoadInteger(udg_UnitHTs, tuid, 100) > 0 then
call Effect(u)
endif
...
Конечно подразумевает таймерное удаление записей с хэндла и так далее )
|
| |
|
|
| FatalBlade | Дата: Пятница, 30 Сентября 2011, 14:07:01 | Сообщение # 8 |
10 уровень
Группа: Проверенные
Сообщений: 1523
Награды: 0
Репутация: 439
Блокировки: | Quote (FkoFF) эээ,, вообщем юниты статично все в триггере, на всех сразу определяется нанесенный урон. А хэш лишь по хэндлу привязывает уровень полученного баффа, вроде того.
и уже в самом триггере примерно такая строчка:
local unit u=GetTriggerUnit()
local integer tuid = GetHandleId(u)
...
if LoadInteger(udg_UnitHTs, tuid, 100) > 0 then
call Effect(u)
endif
...
Конечно подразумевает таймерное удаление записей с хэндла и так далее )
Насколько я понял хэш в таком случае не надо очищать? Ведь там будет постоянный HandleId(юнит) который будет принимать значение булеан
|
| |
|
|
| FkoFF | Дата: Пятница, 30 Сентября 2011, 16:16:41 | Сообщение # 9 |
|
Группа: Заблокированные
Сообщений: 4356
Награды: 1
Репутация: 1413
Блокировки: | Quote (FatalBlade) Насколько я понял хэш в таком случае не надо очищать? Ведь там будет постоянный HandleId(юнит) который будет принимать значение булеан
да не булеан а интегер. Подчищать надо в любом случае.
По хэндлу юнита записываются МНОГО значений, на все, вообщем то, спеллы подобного плана...
|
| |
|
|
| lawson | Дата: Пятница, 30 Сентября 2011, 16:47:37 | Сообщение # 10 |
|
Группа: Проверенные
Сообщений: 3482
Награды: 0
Репутация: 974
Блокировки: | FatalBlade, Группа может пополняться и вот так через хеш
call GroupAddUnit(LoadGroupHandle(Hash, GethandleId(id), id, unit)
Nic nie wiem bo mam chuj.
редактирую посты! ВСЕ!
|
| |
|
|
| FatalBlade | Дата: Пятница, 30 Сентября 2011, 16:58:21 | Сообщение # 11 |
10 уровень
Группа: Проверенные
Сообщений: 1523
Награды: 0
Репутация: 439
Блокировки: | Quote (lawson) FatalBlade, Группа может пополняться и вот так через хеш
call GroupAddUnit(LoadGroupHandle(Hash, GethandleId(id), id, unit)
Так яж уже давно без группы сделал)
Добавлено (30 Сентябрь 2011, 16:58:21)
---------------------------------------------
Quote (FkoFF) да не булеан а интегер. Подчищать надо в любом случае.
По хэндлу юнита записываются МНОГО значений, на все, вообщем то, спеллы подобного плана...
Я не понимаю что ты имеешь ввиду но кажется я понял твою идею...
Когда я выбираю героя в таверне, если этот герой является Мясником, то на него добавляется событие Юнит Получает Урон в другой триггер. Тут же, на хэндл этого юнита я сохраняю false.
call SaveBoolean(udg_Hash, GetHandleId(Hero), 0, false)
Когда герой активирует спелл Suffer, который должен считывать урон, под хэндл этого юнита сохраняется true.
call SaveBoolean(udg_Hash, GetHandleId(GetTriggerUnit()), 0, true)
По истечению локального таймера, либо если Мясник умер, либо если он заюзал спелл Unleash, который наносит столько урона, сколько он получил подсчитывая урон скиллом Suffer - под хэндл этого юнита сохраняется false.
call SaveBoolean(udg_Hash, GetHandleId(unit), 0, false)
В триггере с добавленным событием Юнит Получает Урон, проверяется local boolean b = LoadBoolean(udg_Hash, id, 0):
Если b == true, то такие то действия.
Сообщение отредактировал FatalBlade - Пятница, 30 Сентября 2011, 17:08:17 |
| |
|
|
|
|
 |
|
 |
|
|
