qzGoon
WarCraft 3

Можно ли реализовать подобное без орб эффектов?

Добавлен 
call UnitDamageTargetBJ( GetEventDamageSource() , GetTriggerUnit(), GetEventDamage()*5, ATTACK_TYPE_HERO, DAMAGE_TYPE_NORMAL )
Такой способ крашит карту, орать не нужно ибо я ковыряю функции.

Буквально вчера такое же разбирал у себя. Краш лечится предусловием. Перед нанесением урона сохранить в Custom Value (UserData) боевой единицы какое-то число, которое бы говорило о нанесении урона, после нанесения урона - убираете. Для триггера, ловящего урон поставить условие, что юниты с таким установленным числом не проходят по событию детекта урона (чтобы триггерный урон не ловился и не получалась рекурсия).
22 авг 2018
1 910
`
ОЖИДАНИЕ РЕКЛАМЫ...

Показан только небольшой набор комментариев вокруг указанного. Перейти к актуальным.
0
Показать
13
0
Показать
Буквально вчера такое же разбирал у себя. Краш лечится предусловием. Перед нанесением урона сохранить в Custom Value (UserData) боевой единицы какое-то число, которое бы говорило о нанесении урона, после нанесения урона - убираете. Для триггера, ловящего урон поставить условие, что юниты с таким установленным числом не проходят по событию детекта урона (чтобы триггерный урон не ловился и не получалась рекурсия).
Принятый ответ
7
Показать
4
7
Показать
Ответ на вопрос "Можно ли реализовать подобное без орб эффектов?" - Можно!
0
Показать
6
0
Показать
Alexander122:
Ответ на вопрос "Можно ли реализовать подобное без орб эффектов?" - Можно!
ЮМОРИСТ
0
Показать
28
0
Показать
Пушистый:
Буквально вчера такое же разбирал у себя. Краш лечится предусловием. Перед нанесением урона сохранить в Custom Value (UserData) боевой единицы какое-то число, которое бы говорило о нанесении урона, после нанесения урона - убираете. Для триггера, ловящего урон поставить условие, что юниты с таким установленным числом не проходят по событию детекта урона (чтобы триггерный урон не ловился и не получалась рекурсия).
Custom Value может использоваться.
Вот нормальное решение.
call DisableTrigger(GetTriggeringTrigger())
call UnitDamageTargetBJ( GetEventDamageSource() , GetTriggerUnit(), GetEventDamage()*5, ATTACK_TYPE_HERO, DAMAGE_TYPE_NORMAL )
call EnableTrigger(GetTriggeringTrigger())
0
Показать
13
0
Показать
PT153, да, потом я начал так блокировать отлов урона, когда анализ записей в хэше не устроил)
0
Показать
29
0
Показать
PT153, можно было и не выключать триггер, а обойтись логической переменной.
if NoDamageReaction  then
else
set  NoDamageReaction = true 
call UnitDamageTarget ( GetEventDamageSource() , GetTriggerUnit(), GetEventDamage()*5, true, false, ATTACK_TYPE_HERO, DAMAGE_TYPE_NORMAL, null )
set  NoDamageReaction = false
endif
0
Показать
28
0
Показать
KingMaximax:
можно было и не выключать триггер, а обойтись логической переменной.
В итоге у тебя сработает триггер, начнётся проверятся условие. Зачем так, если можно просто выключить триггер, это обойдётся в меньше строк кода и без создания переменных.
0
Показать
32
0
Показать
PT153, выключение не быстрое как бы...
0
Показать
28
0
Показать
KingMaximax, а зачем тут else?
if(!NoDamageReaction){
	NoDamageReaction = true;
	UnitDamageTarget ( GetEventDamageSource() , GetTriggerUnit(), GetEventDamage()*5, true, false, ATTACK_TYPE_HERO, DAMAGE_TYPE_NORMAL, null )
	NoDamageReaction = false
}
0
Показать
29
0
Показать
nvc123:
KingMaximax, а зачем тут else?
Как сказал мой один рыжий знакомый, который ломает сайты. if else быстрее чем if not...
Я всегда использую if else принцип... Особенно для проверки "Есть ли юнит в группе".
0
Показать
28
0
Показать
KingMaximax, т.е. ради экономии одного такта ты пишешь быдлокод?
когда даже старые компьютеры совершают более миллиарда тактов в секунду
может тогда ещё будешь писать всё в одну строчку
т.к. лишние пустые строки замедляют работу намного сильнее чем отрицание
Показан только небольшой набор комментариев вокруг указанного. Перейти к актуальным.
Чтобы оставить комментарий, пожалуйста, войдите на сайт.