Герой с активным спеллом.
Если он добивает юнита этим спеллом, то весь урон, наносимый героем, становится сильнее.
Усиление урона я триггерно сделаю, это не проблема.
Вопрос в другом, как посоветуете реализовать то, от чего отсчитывать?
Можно дать юниту маркерную абилу-пустышку на 1000 уровней (прелоадить маркер где-нибудь на карте) и при убиении этим юнитом тем самым спеллом врага повышать ему лвл этого маркера. Это изи, но тупо, т. к. долго грузится в РО и будет понижать скорость загрузки карты. Ну и плюс лимит 999 повышений, хотя его и хватит в 95% случаев.
Есть другие идеи?

avuremybe, это каким ты боком не получишь индекс от юнита
проще некуда
чтобы получить нужный индекс просто перечисляем весь массив и ищем нужного юнита типо так
globals
int Count
int array SpellUP
unit array UN
endglobals
int i = 0
while(i <= Count){
if UN[i] == Нужный юнит {
SpellUP[i]++
наши действие
}
i++
}
`
ОЖИДАНИЕ РЕКЛАМЫ...
21
avuremybe, ок, понятно, ну вроде там уже ясно все с глобалками, если что отпишу
просто много глобалок мне редактировать тоже не оч удобно + их нужно будет из тестовой карты героя переносить в основную, да, абилы из РО тоже, но там это уже все "автоматически" делается... ну ладно, короче, это все не настолько неприятно, буду с глобалками делать
26
ClotPh, так ведь есть галочка, чтобы глобалки тоже создавались автоматом при копировании триггера.
28
А просто через хэш таблицу сохранять на юнита значение не вариант?
21
16GB, ну а как его потом считывать, если локалка?
Я вот так, например, понимаю: ну, допустим, юнит изучит спелл 1 уровня, я запускаю периодический таймер, записываю в хэш соответствующую юниту локалку с начальным значением в 0, таймер обновляется, локалка перезаписывается.
Хорошо, допустим, как-то записать ее увеличение я могу: например, при добивании юнита спеллом создавать какое-то условие для добившего (да хоть тот же маркер ОДНОуровневый ему дать или убрать, лол), таймер это условие проверяет и, если ок, увеличивает, сохраняет, удаляет/добавляет маркер обратно и дальше уже увеличенную считывает.
А как это значение потом доставать при нанесении урона в другой функции?
Пока склоняюсь к тому, что оптимальный вариант - с тремя глобалками, хотя очень хочется обойтись и без глобалок, и даже без дополнительных способностей...
28
ClotPh,
В смысле локалка
Сохраняешь значение на хэндл юнита, а не таймера.
получение
set dmg = LoadReal(udg_Hash,GetHandleId(c),StringHash("LBMDR"))
сохранение
call SaveReal(udg_Hash,GetHandleId(c),StringHash("LBMDR"),dmg+20.)
Ну героя убившего я думаю ты можешь получить. это переменная c
21
16GB,
"Сохраняешь значение на хэндл юнита, а не таймера"
я так не умею
что курить?
хотя мб разберусь, информация в сообщении уже старт
28
ClotPh,
То что я дал это весь код лол, что не ясно то?
21
/////////////
Ок, уточним
Имеется глобалка udg_Hash
В одной функции
local unit u5 = GetTriggerUnit()
и там же выполняется
call SaveReal(udg_Hash,GetHandleId(u5),StringHash("zwill"),100)
Я могу в абсолютно другой функции, если точно знаю, что в ней локалка u5 будет объявлена как тот же юнит, достать
local real percentbonus = LoadReal(udg_Hash,GetHandleId(u5),StringHash("zwill"))
через хэш-глобалку как связующее звено?
28
Я могу в абсолютно другой функции, если точно знаю, что в ней локалка u5 будет объявлена как тот же юнит, достать
Да
21
16GB, ну что ж, выглядит идеально, спасибо
как придет время - проверю
жаль, перевыбрать лучший ответ уже не могу, хотя 3 глобалки тоже хороши
26
NekoriDes, а глобалки бывают не _udg ? или к чему это?
ClotPh, считывать еще проще, но хэш работает медленнее, чем глобалки.
26
а глобалки бывают не _udg ?
udg_ это специальная приписка для глобалок создаваемых редактором триггеров через список переменных...
13
avuremybe:
NekoriDes, а глобалки бывают не _udg ? или к чему это?
globals {
	int zero = 0
	float unitPosX = 1.1
}
globals
	integer zero = 0
	real unitPosX = 1.1
endglobals
26
Extremator, еще один... вы хоть читайте что происходит
NekoriDes, и ты думаешь, если ты через надстройки пишешь просто название, то оно компилируется без udg_ ?
21
Да че вы про перенос глобалок заоффтопились, это вообще мелочь
Я офк знаю, что есть функция их автосоздания, но хз, действует ли она, если глобалка скопирована как кусок нестандартного кода сверху карты
И там, по-моему, были какие-то свои траблы, как минимум если у глобалки начальное значение должно было быть не нулевое, она автосоздавалась с нулевым (ну это понятно - откуда редактору знать) и не помню, как себя поведут максимальные значения массивов
В любом случае это было бы не так уж трудно - прописать глобалкам то, что надо, в каждой карте
Я сейчас просто отмеряю, прежде чем отрезать, отрезать вообще мб даже не в сентябре буду
И, как показывает практика, не зря, варианты все лучше, вот последний вообще вроде эталон
26
ClotPh, в примере, который я тебе скинул, значение всех переменных дефолтное.
Да и перекопировать даже руками 3 переменные это несколько секунд работы.
21
avuremybe, спасибо большое, но вариант 16Gb мне все-таки кажется лучше
Даже если он снизит производительность, может, очень сильно ошибаюсь, но, по-моему, не смертельно, если таких героев, способностей и хэшей не будет по 100 одновременно в игре (а по 100 ОДНОВРЕМЕННО - не будет), а вот 300 глобалок для 100 потенциальных способностей, например, уже немного неудобно в редакторе переменных смотреть
и, конечно, мои 300 маркеров были бы еще хуже в редакторе объектов, не спорю
26
ClotPh, зачем тебе 100 глобалок? у тебя 3 глобалки для 8092 способностей. Если тебе нужно еще больше способностей, скажи - я тебе добавлю еще одну глобалку.
21
avuremybe, а, вот как, примерно понимаю...
но, по-моему, у 16Gb еще и проще раскурить
ладно, твой вариант просто буду иметь в виду, все равно вся эта тема со всеми вариантами в целом полезная, короче
26
ClotPh, оба варианта работают по одной логике. Разница в том, что обращение к хэшу происходит значительно дольше, чем обращение к глобальной переменной.
Поэтому хэш рекомендуется использовать только в ситуациях где глобальными переменными выкрутится либо не возможно, либо код становится слишком громоздким и работает уже не быстрее обращения к хэшу.
Но в любом случае, юзать хэш - это куда разумнее, чем способности-маркеры, юниты-носители-маркеров итд.
13
avuremybe:
NekoriDes, и ты думаешь, если ты через надстройки пишешь просто название, то оно компилируется без udg_ ?
Это с каких пор он добавляет udg_?
На самом деле только сейчас въехал про что твой вариант. Не заметил цикл сразу и даже посчитал тебя не очень умным. В итоге, не очень умный здесь я.
Тащемта, лучший вариант. Я уже хотел про объекты начать загонять.
26
ClotPh, еще один важный вопрос по поводу оптимизации.
У тебя юниты с этой твоей способностью когда умирают, ты их потом воскрешаешь? Или он просто умер и всё, нет больше ни юнита ни его способности?
20
Базы данных в помощь. Поиск найдет инфу по ним. Хватит изобретать костыли.
21
avuremybe, обычно воскрешаются, есть некая небольшая вероятность, что юнит будет удален (если это клон героя, вызванный кем-то другим), но это редко
Чтобы оставить комментарий, пожалуйста, войдите на сайт.