вы полностью покажите код, скринами или скопируйте с соответствующим форматированием, а не думайте что "это неважно"

ну так Кастер - юнит, и тот кто атакован - юнит! в чем ваша проблема??

потому что это локальная переменная. сами же написали это, и сами удивляетесь?

от чего срабатывает второй триггер? или это функция? как бы это разные вещи

вам написали про юнита, вы продолжаете долбиться в таймер

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

что появляется во втором триггере? какие объекты?

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

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

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

никак это не работает, сами подумать не можете вообще?

Я только не понимаю: 0 - это значение, с которым мы сохраняем кастера? А если кастеров много, они все будут записываться в значение 0?

parentKey - родительский ключ
childKey - младший ключ
ты похоже не понимаешь как работает. хэндл у объектов разный, это просто счетчик объектов. например, создается первый футман ему перечисляют номер 1000 (1000-это условно, просто handle большие значения), спавнится второй футман он имеет номер 1001, создается третий футман 1002, создается стрелок 1003, декор 1004 итд. короче у разных кастеров не мб конфликта тк хэндлы разные
конфликты могут быть в коде, если старший и младший ключи совпадают. например 2 разных триггера, короче 2 абилки. Но имеют одинаковые ключи (первый: handle,0 второй: handle,0. Может произойти так что в одном триггере сохранишь, а в каком-нибудь втором из них перезапишешь данные. надо во втором триггере изменить младший ключ. изменить во втором во так: handle,1 - будет совсем другая ячейка)

А как это именно внутри функции с условием написать?

На гуи есть готовое решение. В разделе Boolean => HaveSavedHandle

И что такое число A?

Ну можно числа загружать из хэша
LoadInteger(Hash,id,0)>0 в разделе integer
LoadReal(Hash,id,0)>0 в разделе real
Кстати есть вот такая готовая функция BJ, не знал что есть

функция

Скопировать в буфер

function HaveSavedValue takes integer key, integer valueType, integer missionKey, hashtable table returns boolean
    if (valueType == bj_HASHTABLE_BOOLEAN) then
        return HaveSavedBoolean(table, missionKey, key)
    elseif (valueType == bj_HASHTABLE_INTEGER) then
        return HaveSavedInteger(table, missionKey, key)
    elseif (valueType == bj_HASHTABLE_REAL) then
        return HaveSavedReal(table, missionKey, key)
    elseif (valueType == bj_HASHTABLE_STRING) then
        return HaveSavedString(table, missionKey, key)
    elseif (valueType == bj_HASHTABLE_HANDLE) then
        return HaveSavedHandle(table, missionKey, key)
    else
        // Unrecognized value type - ignore the request.
        return false
    endif
endfunction

Нет дефолтного "глобального" хеша, сначала создаем глобальную переменную типа hashtable (например назовем ее mytable), делаем InitHashtable, затем SaveUnitHandle(mytable, GetHandleId(caster), 0, target), затем, чтобы по caster достать target - LoadUnitHandle(mytable, GetHandleId(caster), 0)
Соответственно твой второй триггер на событие атаки должен быть всегда включен и должен проверять, что хештаблица что-либо содержит (вместо условия что есть сейчас). + нужно делать RemoveSavedHandle для очистки в самом конце.

вот проверка тема
проверка хэндла

Скопировать в буфер

native HaveSavedHandle takes hashtable table, integer parentKey, integer childKey returns boolean

проверка числа integer или real проверяем условием A>0
обычно изначально в ячейках если ничего не записано, то вернет 0 или null

Да, все так. Второй ключ нужен на случай конфликта первичных ключей, т.е. когда хочется хранить больше данных по одному хендлу.

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

DopaMine:

И желательно переписать с триггеров на Jass, а я не особо шарю, позавчера начал делать.

Учитывая обилие custom script в триггерах, тебе будет проще работать с твоим кодом, если ты его конвертируешь в Jass напрямую.

---

Вообще пользоваться GUI и не переходить на нормальное представление кода есть смысл только если ты вообще не знаешь ничего о программировании и не планируешь узнавать, например, если ты чисто моделлер или ландшафтер.

Я немного представляю. Поэтому и понимаю логику локальных переменных, и понимаю, почему у меня не работает для нескольких кастеров. Но с хэш-таблицами пока не понял, как это: значение кастера всегда 0, но когда мы загружаем кастера по значению 0, таблица понимает, какого кастера я загружаю. Как это? Ключ одинаков для всех кастеров, получается. Я прав?

Нет дефолтного "глобального" хеша, сначала создаем глобальную переменную типа hashtable (например назовем ее mytable), делаем InitHashtable, затем SaveUnitHandle(mytable, GetHandleId(caster), 0, target), затем, чтобы по caster достать target - LoadUnitHandle(mytable, GetHandleId(caster), 0)

DopaMine, что вы хотите сделать? просто зачем вам хэш?
есть статья
просто для начала нужна ссылка на объект хэндл, чтобы получить GetHandleId(<object>). Или как-то записать или как-то по логике вызывается. Я просто напишу примеры для понимания как это работает. Хэндл этот просто помогает хранить/доставать данные, короче работать с ячейками

пример магазина, также можно сделать склад

как пример на jass
триггер 1 - продаем в магазин
событие - юнит закладывает в лавку (у нас 3 вар переменные: продавец и покупатель, предмет item, который продают в магазин)
допустим мы можем сохранить item в хэш-таблицу по ключам GetHandleId(<покупатель>)
также в хэш можно записать разные данные вроде тип, заряды, номер слота и пр

триггер 2 - выкупаем из магазина (аналогично 3 вар переменные, только роли продавца и покупателя меняются местами)
событие - юнит закладывает из лавки
допустим предмет удаляется из магазина, нам нужно из таблицы в данных магазина удалить этот предмет. с помощью хэндла магазина GetHandleId(продавец). С помощью вар переменной item можно достать тип и др данные хранящие в хэндле GetHandleId(продавец)

ваш случай

А триггера два, так как когда юнит жмёт способность, она сработает только если этот юнит атакован, в противном случае - просто идёт кулдаун. Как это сделать в одном триггере - хз.

Не знаю что хотите сделать. Но примерно догадываюсь, но это можно подкорректировать. Можно в атакующем юните хранить boolean b (да/нет), по хэндлу атакующего сохранять. Этот флаг будет говорить находится ли в кулдауне или нет.

Триггер 1 - при атаке загружаем boolean b по хэндлу атакующего и проверяем. Если boolean b вернет истину, то ваши действия.
Триггер 2 - при активации абилки запускаем таймер. Сохраняем в хэше boolean b = true (истина). Таймер длится столько сколько в кулдауне указано. По истечению таймера boolean b = false (ложь). Можно просто очистить хэш.

Нет скринов, указывай ссылки на них, когда загрузишь.