Пишу такую способность на JASS:
При атаке атакующий юнит получает дополнительный урон, который стакается, если юнит атаковал снова в течении 5 секунд. Для этого я запускаю таймер, который через 5 секунд удалит дополнительный урон у юнита. Настакиванье урона я делаю при помощи изменения уровня скилла +урон. Но никак не могу понять: каким образом при повторной атаке сбросить таймер на 0.00. Думаю, мой вопрос банален для прожженных кодеров. Я искал некоторые статьи или похожие вопросы, но ответа не нашел. Подскажите как такое решается или дайте ссылки на похожие вопросы или статьи по теме. Заранее, спасибо.
Код скилла (на всякий случай):
function Trig_Aura_Strenght_Conditions takes nothing returns boolean
    if ( not ( GetUnitAbilityLevelSwapped('S000', GetAttacker()) == 1 ) ) then
        return false
    endif
    if ( not ( GetRandomInt(1, 1) == 1 ) ) then
        return false
    endif
    return true
endfunction

function Aura_Strenght_Lost takes nothing returns nothing
    local timer t = GetExpiredTimer()
    local integer id = GetHandleId(t)
    local unit caster = LoadUnitHandle(udg_Hash,id,47)
    local real time = LoadReal(udg_Hash,id,48)
    
    set time = time + 0.05
    call SaveReal(udg_Hash,id,48,time)
    if time == 5.00 then
        call UnitRemoveAbility(caster,'S001')
        call DestroyTimer(t)
        call FlushChildHashtable(udg_Hash,id)
    endif
    call BJDebugMsg(R2S(time))
endfunction

function Trig_Aura_Strenght_Actions takes nothing returns nothing
    local timer t = CreateTimer()
    local integer id = GetHandleId(t)
    local unit caster = GetAttacker()
    call UnitAddAbility(caster,'S001')
    call SetUnitAbilityLevel(caster,'S001',1)
    call SaveUnitHandle(udg_Hash,id,47,caster)
    call SaveReal(udg_Hash,id,48,0.00)
    call TimerStart(t,0.05,true,function Aura_Strenght_Lost)
    //call AddHeroXP(caster,100,true)
endfunction

//===========================================================================
function InitTrig_Aura_Strenght takes nothing returns nothing
    set gg_trg_Aura_Strenght = CreateTrigger(  )
    call TriggerRegisterAnyUnitEventBJ( gg_trg_Aura_Strenght, EVENT_PLAYER_UNIT_ATTACKED )
    call TriggerAddCondition( gg_trg_Aura_Strenght, Condition( function Trig_Aura_Strenght_Conditions ) )
    call TriggerAddAction( gg_trg_Aura_Strenght, function Trig_Aura_Strenght_Actions )
endfunction

Принятый ответ

8gabriel8, я скинул наработку, которая реализует общее событие «получает урон» в 30 строк, для её использования даже думать как именно она работает не нужно.
`
ОЖИДАНИЕ РЕКЛАМЫ...

Показан только небольшой набор комментариев вокруг указанного. Перейти к актуальным.
0
23
6 лет назад
0
GetAttacked это котоырый юнит получает юрон
GetAttacker это атакующий юнит
0
26
6 лет назад
Отредактирован 8gabriel8
0
PT153, создаёшь группу, в триггере с событием Юнит Атакован делаешь условие, что атакованный не в группе, в действия добавляешь событие Юнит Получает урон с ним в триггер на получение урона.
0
28
6 лет назад
0
создаёшь группу
Но зачем, когда можно просто регистрировать во время входа. 1 добавленное событие проще 1000 срабатываний триггера с проверкой.
Само событие UNIT_ATTACKED сильно нагружает игру
0
26
6 лет назад
Отредактирован 8gabriel8
0
И есть ведь вроде действие, которое возвращает изначальное состояние триггера до добавления в него событий, условий и действий?
Но зачем, когда можно просто регистрировать во время входа
PT153, человек жаловался в своё время, что через минут 10-30 интенсивного спавна с этим добавлением события начинало сильнейше лагать.
0
28
6 лет назад
0

Способ с событием Вся карта и условием отсеивающее ненужных юнитов.
Плюсы.
  • Простой
  • Не нагружает игру
Минусы.
  • Зарегистрированный юнит возможно так и не будет атакован

Способ Extremator.
Плюсы.
  • Регистрирует не всех юнитов.
Минусы.
  • Для верной работы требуется создание доп. объектов.
  • Постоянно срабатывает во время игры.
  • Зарегистрированный юнит возможно так и не будет атакован, так как UNIT_ATTACKED срабатывает при замахе.

сильнейше лагать
Сильнейше лагать будет и от UNIT_ATTACKED, так что такой способ определённо не выход.
8gabriel8:
И есть ведь вроде действие, которое возвращает изначальное состояние триггера до добавления в него событий, условий и действий?
Есть такое, но я не знаю, так ли оно работает, как ты описал.
native ResetTrigger takes trigger whichTrigger returns nothing
0
26
6 лет назад
0
PT153:
Сильнейше лагать будет и от UNIT_ATTACKED
Ни разу не сталкивался, пример есть? С условием, что атакующий какой-то один герой
0
21
6 лет назад
0
Если бы было событие UNIT_ATTACKING, то можно было бы регистрировать на него ТОЛЬКО обладателей нужных нам пассивок, срабатывающих при ИХ атаке и не париться из-за лагов, в этом вся разница
примерно так же например можно - и так, ятп, и делается везде - на пассивку акса при выучивании его пассивки зарегистрировать на UNIT_ATTACKED ТОЛЬКО акса, но там-то как раз ATTACKED, т. е. срабатывает при атаке НА НЕГО
в общем, с пассивками, срабатывающими для атакованных юнитов при атаке НА НИХ проблем нет
а от пассивок, срабатывающих для атакующих при ИХ атаке КОГО УГОДНО ДРУГОГО - есть
потому что в первом случае достаточно регистрировать событие только для одного-единственного обладателя пассивки
а во втором нужно отлавливать всех этих "КОГО УГОДНО ДРУГИХ" (как минимум - ближайших и способных быть атакованными)
0
26
6 лет назад
0
ClotPh:
Если бы было событие UNIT_ATTACKING, то можно было бы регистрировать на него ТОЛЬКО обладателей нужных нам пассивок, срабатывающих при ИХ атаке и не париться из-за лагов, в этом вся разница
В условие ставишь, что у Атакующего есть нужная пассивка и она сработала. Не?
0
28
6 лет назад
Отредактирован PT153
0
Ни разу не сталкивался, пример есть? С условием, что атакующий какой-то один герой
Так это событие будет срабатывать на замах любого юнита, отсеять ненужных можно в фильтре или событии. Факт в том, что срабатывать будет.
У меня лагало, но атакующих юнитов было много. Также в этом триггере была сложная функция. Решил проблему отключения выполнения сложной функции на некоторое время для каждого определённого юнита.
В частности, quq_CCCP меня ругал за то, что я в своей карте использую это событие.

В любом случае, оба способа не гарантируют, что юнит-таки получит урон, но первый способ проще.
8gabriel8:
человек жаловался в своё время, что через минут 10-30 интенсивного спавна с этим добавлением события начинало сильнейше лагать.
Помню-помню такое, но в это слабо верится, потому что кто-то более разбирающийся говорил, что как только юнит удаляется, а все ссылки на его хендл обнулены, то и все зарегистрированные события для него удаляются. Лаги может вызывать много чего, если неразумно использовать.

А вообще тут опять ушли от вопроса и начали холивар об оптимизации)
0
21
6 лет назад
0
8gabriel8, так проверяться-то всё равно будет при любом атакующем, в этом-то и проблема!
серьезно или я или ты не понимаем как события-условия-действия устроены
разумеется, проверка отфильтрует кого надо, это понятно
но до неё проверяться всё равно будут все, событие-то юнит АТАКОВАН, любой юнит...
даже хз как сказать...
вот если бы было - "событие: юнит атакован обладателем пассивки Страшный Топор" - тогда бы нагрузки не было
а оно так:
"событие - юнит атакован
условие - у атаковавшего есть пассивка Страшный Топор"
то есть вначале оно всё равно смотрит ВСЕХ, а потом проверяет пассивку
0
21
6 лет назад
Отредактирован scopterectus
0
потому что кто-то более разбирающийся говорил, что как только юнит удаляется, а все ссылки на его хендл обнулены, то и все зарегистрированные события для него удаляются
Здесь тест говорит о том, что зарегистрированные события удаляется только после того, как будет удалён сам триггер. Пока триггер существует, существуют и все зарегистрированные события на уже несуществующих юнитов.
В тестовой карте создаются события на юнитов, которые сразу же удаляются. При нажатии на ESC данный триггер удаляется.
Загруженные файлы
Показан только небольшой набор комментариев вокруг указанного. Перейти к актуальным.
Чтобы оставить комментарий, пожалуйста, войдите на сайт.